Linus Walleij wrote at Thursday, October 20, 2011 7:44 AM:
On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo shawn.guo@freescale.com wrote:
We should not require device driver to call these APIs directly. There are so many pinctrl subsystem internal details left to its users.
As explained I already have drivers that need to do this. OK they are out-of-tree, but they do exist.
For U5500 we have a SIM card driver which sets pull down resistance and load capacitance in response to information retrieved from the card at runtime. This is not static or internal to pinctrl at all. How should I solve this if pin configuration is not exposed?
I think drivers should operate at a higher level than "set pin X's param Y to value Z".
I imagine the set of states that the SIM card driver needs to set up are defined by the SIM protocol.
So, the driver communicates with the SIM card, find out that it supports Certain clock frequencies or capabilities etc., and then needs to program the SIM card and associated SoC-side HW to operate in the selected mode.
The set of legal modes for the SIM card protocol is presumably pretty small, so the SIM driver might want to request "basic" or "fast" operation (note: I have zero knowledge of SIM cars, so those mode names are bogus).
Similarly, SD/MMC drivers might know about a mode name for each clock frequency (or range) that an SD card is allowed to support by spec.
However, I still think it's a good idea for pinctrl drivers to expose each of their available configuration options with as little veneer or abstraction as possible.
To bridge these two levels of abstraction, I think the pinctrl core needs to be provided with information or an API to map between them.
I imagine this could be implemented as a table rather similar to the existing mux table, or even part of that mux table.
The table would be at least partially board-specific (since a given SD instance might be mux'd onto a different set of pins between two boards, and the values for each param might be determined during board characterization), but for a given HW module (SIM, SD), at least some of the data might be the same across any board that use that function, irrespective of which set of pins is in use or independent of board characterization. So, we might have to think about how the board and SoC code (and/or DT board/SoC bindings) could interact to reduce duplication of common settings, but we should probably defer that discussion.