Shawn Guo wrote at Sunday, October 23, 2011 2:51 AM: ...
To me, pin_config() and its parameters should be invisible to client drivers. For amba-pl011 example, do you think any of those SoCs will need multiple sets of uart pin configurations to switch for different working modes? If that's case, the individual SoC pinctrl driver should be responsible for mapping particular pin configuration to specific pl011 working mode. Otherwise, the amba-pl011 can simply call pinmux_enable(...) to have both mux and cfg set up.
I agree.
Somebody at the ARM workshop yesterday (and I'm sorry, I forget who; I'm missing too much sleep) pointed out another very good reason:
If there's some IP block that's used in a bunch of SoCs, and each SoC has different sets of params (or values) that can be set, the IP block driver shouldn't know about each SoC, and set those values; instead, the board should be telling the pinmux system exactly what parameters to set, and the IP block driver should simply be telling pinmux "set up the pins".
Now, I suppose that this could also be done by providing all the params and values to the driver through platform data, however:
a) The driver is already calling pinctrl to set up the muxing in an abstract way (mapping table hides the details); I'd like to see pin config work in the same way.
b) If this were implemented through platform data in each driver, then every driver's DT binding and probe code will need to define the format of this data and parse it at probe time. Instead, if this is all in some table handled by the pinctrl system, it's defined once, and parse once, which seems a lot simpler.