From: Linus Walleij linus.walleij@linaro.org
This is the sixth iteration of the controller subsystem, most changes are described in the individual patches, mainly we are now doing away with the patch to the AMBA bus to acquire pinmuxes, instead this is done from the U300 machine core. This way the impacts on the existing drivers and buses are kept to a minimum for the time being.
Further I squashed the patch removing the old pinmux driver from the U300 machine into the patch adding the new driver, because it was not really possible to do a clean cut anyway.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches.
- Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused.
- Create a separate debugfs file to view the pinmux map at runtime.
- Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some fixed-length string.
- add a function to unregister GPIO ranges to mirror the registration function.
- Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation.
U300 driver:
- Adjust the driver to return the group list as an array of strings instead of a unsigned * array.
- Add support for the EMIF0 and EMIF1 pin groups.
- Acquire all muxmaps using pinmux hogs from the core using a subsystem_initcall(). This way we need not change any drivers or buses. We have the correct struct device * pointers anyway so why not do it from there, and it illustrates pretty well what the pinmux core will be able to do once it can access the device tree.
- Use new convenience macros for system mappings.
- Unregister the GPIO range at removal.
Linus Walleij (2): drivers: create a pin control subsystem v7 pinmux: add a driver for the U300 pinmux
Documentation/ABI/testing/sysfs-class-pinmux | 11 + Documentation/pinctrl.txt | 951 +++++++++++++++++++++ MAINTAINERS | 5 + arch/arm/mach-u300/Kconfig | 2 + arch/arm/mach-u300/Makefile | 2 +- arch/arm/mach-u300/core.c | 84 ++- arch/arm/mach-u300/include/mach/syscon.h | 136 --- arch/arm/mach-u300/mmc.c | 16 - arch/arm/mach-u300/padmux.c | 367 -------- arch/arm/mach-u300/padmux.h | 39 - arch/arm/mach-u300/spi.c | 20 - drivers/Kconfig | 4 + drivers/Makefile | 2 + drivers/pinctrl/Kconfig | 36 + drivers/pinctrl/Makefile | 7 + drivers/pinctrl/core.c | 632 ++++++++++++++ drivers/pinctrl/core.h | 73 ++ drivers/pinctrl/pinmux-u300.c | 1008 ++++++++++++++++++++++ drivers/pinctrl/pinmux-u300.h | 141 +++ drivers/pinctrl/pinmux.c | 1178 ++++++++++++++++++++++++++ drivers/pinctrl/pinmux.h | 47 + include/linux/pinctrl/machine.h | 107 +++ include/linux/pinctrl/pinctrl.h | 133 +++ include/linux/pinctrl/pinmux.h | 124 +++ 24 files changed, 4544 insertions(+), 581 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-pinmux create mode 100644 Documentation/pinctrl.txt delete mode 100644 arch/arm/mach-u300/padmux.c delete mode 100644 arch/arm/mach-u300/padmux.h create mode 100644 drivers/pinctrl/Kconfig create mode 100644 drivers/pinctrl/Makefile create mode 100644 drivers/pinctrl/core.c create mode 100644 drivers/pinctrl/core.h create mode 100644 drivers/pinctrl/pinmux-u300.c create mode 100644 drivers/pinctrl/pinmux-u300.h create mode 100644 drivers/pinctrl/pinmux.c create mode 100644 drivers/pinctrl/pinmux.h create mode 100644 include/linux/pinctrl/machine.h create mode 100644 include/linux/pinctrl/pinctrl.h create mode 100644 include/linux/pinctrl/pinmux.h
Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
From: Linus Walleij linus.walleij@linaro.org
This is the sixth iteration of the controller subsystem...
Overall, the changelog sounds like a great move in the right direction. There's just one small thing I'd comment on here:
ChangeLog v6->v7:
- Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren.
I've been viewing the map table as:
input: (device, device's function) output: list of (controller, controller's group, controller's function)
... hence I was surprised to see that you explicitly note that mapping a single device to multiple controllers was disallowed.
That said, I suppose this restriction won't cause any issues for any use-case I'm aware of; the only possibilities might be:
a) Multiple pinmux controllers within the SoC, but perhaps the driver should just aggregate multiple HW modules into a single Linux device anyway?
b) Where the pinmux map wants to affect the pinmux on both ends of some bus, where the two ends are different chips each having obviously separate pinmux controllers.
Then again, if this need ever does arise, we should be able to just relax this restriction without causing any backwards-compatibility issues, so I don't see a specific need to change this now; I just thought I'd mention it so you're aware of what I'm thinking.
I'll go review the code now.
On Tue, Sep 20, 2011 at 10:10 PM, Stephen Warren swarren@nvidia.com wrote:
... hence I was surprised to see that you explicitly note that mapping a single device to multiple controllers was disallowed.
Actually it's easy to fix, I mainly wanted to keep that until we have a solid usecase for it, it's just a few lines of code the day we need it.
Then again, if this need ever does arise, we should be able to just relax this restriction without causing any backwards-compatibility issues, so I don't see a specific need to change this now; I just thought I'd mention it so you're aware of what I'm thinking.
It was actually on my mind, I just wanted to keep down the feature creep to what was absolutely needed for the pin controllers we're facing in arch/arm/* today.
Thanks! Linus Walleij
-
Linus Walleij -
Linus Walleij -
Stephen Warren