When configuring pinmux, in addition to modify the cfg file, do I still need to modify the kernel device tree?
Thanks.
The pinmux changes pin assignments. The device tree binds drivers to particular settings (usually related to pin assignments). If you just need a pin assignment to change, then probably not; if a driver interacts with a changed assignment, then yes (it would be rare to change a pin assignment without needing a driver to know about it, but you could be doing testing which doesn’t need this).
If I have not modified the cfg file and just modified the pinctrl in the device tree, will this pin behave as configured in pinctrl?
Thanks.
I couldn’t say…it all depends on what was changed and what uses those changes. The basic steps are to verify pins set as desired, and then verify any device tree changes required for that pin type are valid for the driver which runs the pin. It would be unusual for a pin to have its function changed and to not also have the device tree change, but the reverse of changing a device tree without changing pinmux is common.
Sorry, I still don’t understand the relationship between cfg and pinctrl in the device tree.
Thanks.
I cannot give specifics, only that config is used to set up pin function (more than one function is possible with a pin).
Drivers relate to a function via device tree…the tree must be edited for the combination of driver and function (you wouldn’t need driver parameter set up for a function you don’t use, but if you change a pin function, then you no doubt will want to use the driver associated with the new function…device tree is that glue but in itself does not change a pin’s function).
Perhaps if you have a specific question for a use-case, then someone may be able to give a more specific answer.
I wonder if my following understanding is correct.:
When the device driver does not use the pinctrl to control the pin, the pin will work as configured in cfg file. After the device driver uses the pinctrl to control the pin, this pin will work as configured in the pinctrl.
Thanks.
Every pin which has multiple possible uses will have only one use at any given time. During boot some default will usually be set up. It is possible to alter this on a running system as well. It is rarely the purpose of the driver to make that change…a driver more or less uses what it is given, and something else should do the setup prior to this, e.g., a config setting during flash.
A device tree can set up some details during boot related to pin function, but mostly device tree provides a binding between what is set up and what the driver needs to use that setup. The pin might work in some standard way due to the cfg, but the driver only knows general methods and not how to talk to that pin until device tree gives those details.
I am referring to pinctrl not as the pin’s current state, but instead as a kind of constructor prior to the driver ever running. As an example, setting a pin for the purpose of GPIO used as an interrupt could be a config item, but a driver which understands interrupts won’t know how to talk to that pin until the device tree provides specific details.
The pinmux spreadsheet basically binds a controller to access a pin in a certain way. The driver has no knowledge of this. The device tree gives that knowledge to the driver. Causing a pin to work as GPIO would be a pinmux function. Causing the driver to monitor a specific pin in some way is a device tree function.