iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
57b676f9c1
linux/drivers/pinctrl/core.c

1145 lines
28 KiB
C
Raw Normal View History

drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/*
* Core driver for the pin control subsystem
*
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
* Copyright (C) 2011-2012 ST-Ericsson SA
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
* Written on behalf of Linaro for ST-Ericsson
* Based on bits of regulator core, gpio core and clk core
*
* Author: Linus Walleij <linus.walleij@linaro.org>
*
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
* Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved.
*
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
* License terms: GNU General Public License (GPL) version 2
*/
#define pr_fmt(fmt) "pinctrl core: " fmt
#include <linux/kernel.h>
pinctrl: EXPORT_SYMBOL needs export.h Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-09-30 08:39:04 +04:00
#include <linux/export.h>
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
#include <linux/init.h>
#include <linux/device.h>
#include <linux/slab.h>
#include <linux/err.h>
#include <linux/list.h>
#include <linux/sysfs.h>
#include <linux/debugfs.h>
#include <linux/seq_file.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/machine.h>
#include "core.h"
#include "pinmux.h"
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
#include "pinconf.h"
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
/**
* struct pinctrl_maps - a list item containing part of the mapping table
* @node: mapping table list node
* @maps: array of mapping table entries
* @num_maps: the number of entries in @maps
*/
struct pinctrl_maps {
struct list_head node;
struct pinctrl_map const *maps;
unsigned num_maps;
};
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
/* Mutex taken by all entry points */
DEFINE_MUTEX(pinctrl_mutex);
/* Global list of pin control devices (struct pinctrl_dev) */
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
static LIST_HEAD(pinctrldev_list);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
/* List of pin controller handles (struct pinctrl) */
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
static LIST_HEAD(pinctrl_list);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
/* List of pinctrl maps (struct pinctrl_maps) */
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
static LIST_HEAD(pinctrl_maps);
#define for_each_maps(_maps_node_, _i_, _map_) \
list_for_each_entry(_maps_node_, &pinctrl_maps, node) \
for (_i_ = 0, _map_ = &_maps_node_->maps[_i_]; \
_i_ < _maps_node_->num_maps; \
i++, _map_ = &_maps_node_->maps[_i_])
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
const char *pinctrl_dev_get_name(struct pinctrl_dev *pctldev)
{
/* We're not allowed to register devices without name */
return pctldev->desc->name;
}
EXPORT_SYMBOL_GPL(pinctrl_dev_get_name);
void *pinctrl_dev_get_drvdata(struct pinctrl_dev *pctldev)
{
return pctldev->driver_data;
}
EXPORT_SYMBOL_GPL(pinctrl_dev_get_drvdata);
/**
pinctrl: delete raw device pointers in pinmux maps After discussion with Mark Brown in an unrelated thread about ADC lookups, it came to my knowledge that the ability to pass a struct device * in the regulator consumers is just a historical artifact, and not really recommended. Since there are no in-kernel users of these pointers, we just kill them right now, before someone starts to use them. Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-01 21:02:47 +04:00
* get_pinctrl_dev_from_devname() - look up pin controller device
* @devname: the name of a device instance, as returned by dev_name()
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
*
* Looks up a pin control device matching a certain device name or pure device
* pointer, the pure device pointer will take precedence.
*/
pinctrl: delete raw device pointers in pinmux maps After discussion with Mark Brown in an unrelated thread about ADC lookups, it came to my knowledge that the ability to pass a struct device * in the regulator consumers is just a historical artifact, and not really recommended. Since there are no in-kernel users of these pointers, we just kill them right now, before someone starts to use them. Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-01 21:02:47 +04:00
struct pinctrl_dev *get_pinctrl_dev_from_devname(const char *devname)
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
{
struct pinctrl_dev *pctldev = NULL;
bool found = false;
pinctrl: delete raw device pointers in pinmux maps After discussion with Mark Brown in an unrelated thread about ADC lookups, it came to my knowledge that the ability to pass a struct device * in the regulator consumers is just a historical artifact, and not really recommended. Since there are no in-kernel users of these pointers, we just kill them right now, before someone starts to use them. Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-01 21:02:47 +04:00
if (!devname)
return NULL;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
list_for_each_entry(pctldev, &pinctrldev_list, node) {
pinctrl: delete raw device pointers in pinmux maps After discussion with Mark Brown in an unrelated thread about ADC lookups, it came to my knowledge that the ability to pass a struct device * in the regulator consumers is just a historical artifact, and not really recommended. Since there are no in-kernel users of these pointers, we just kill them right now, before someone starts to use them. Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-01 21:02:47 +04:00
if (!strcmp(dev_name(pctldev->dev), devname)) {
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/* Matched on device name */
found = true;
break;
}
}
return found ? pctldev : NULL;
}
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
/**
* pin_get_from_name() - look up a pin number from a name
* @pctldev: the pin control device to lookup the pin on
* @name: the name of the pin to look up
*/
int pin_get_from_name(struct pinctrl_dev *pctldev, const char *name)
{
pinctrl: correct a offset while enumerating pins This patch modifies a offset while enumerating pins to support a partial pin space. If we use a pin number for enumerating pins, the pin space always starts with zero base. Indeed, we always check the pin is in the pin space. An extreme example, there is only two pins. One is 0. Another is 1000. We always enumerate whole offsets until 1000. For solving this problem, we use the offset of the pin array instead of the zero-based pin number. Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> [Restored sparse pin space comment] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-03 11:47:50 +04:00
unsigned i, pin;
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
pinctrl: correct a offset while enumerating pins This patch modifies a offset while enumerating pins to support a partial pin space. If we use a pin number for enumerating pins, the pin space always starts with zero base. Indeed, we always check the pin is in the pin space. An extreme example, there is only two pins. One is 0. Another is 1000. We always enumerate whole offsets until 1000. For solving this problem, we use the offset of the pin array instead of the zero-based pin number. Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> [Restored sparse pin space comment] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-03 11:47:50 +04:00
/* The pin number can be retrived from the pin controller descriptor */
for (i = 0; i < pctldev->desc->npins; i++) {
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
struct pin_desc *desc;
pinctrl: correct a offset while enumerating pins This patch modifies a offset while enumerating pins to support a partial pin space. If we use a pin number for enumerating pins, the pin space always starts with zero base. Indeed, we always check the pin is in the pin space. An extreme example, there is only two pins. One is 0. Another is 1000. We always enumerate whole offsets until 1000. For solving this problem, we use the offset of the pin array instead of the zero-based pin number. Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> [Restored sparse pin space comment] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-03 11:47:50 +04:00
pin = pctldev->desc->pins[i].number;
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
desc = pin_desc_get(pctldev, pin);
/* Pin space may be sparse */
if (desc == NULL)
continue;
if (desc->name && !strcmp(name, desc->name))
return pin;
}
return -EINVAL;
}
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/**
* pin_is_valid() - check if pin exists on controller
* @pctldev: the pin control device to check the pin on
* @pin: pin to check, use the local pin controller index number
*
* This tells us whether a certain pin exist on a certain pin controller or
* not. Pin lists may be sparse, so some pins may not exist.
*/
bool pin_is_valid(struct pinctrl_dev *pctldev, int pin)
{
struct pin_desc *pindesc;
if (pin < 0)
return false;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
pindesc = pin_desc_get(pctldev, pin);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
return pindesc != NULL;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
EXPORT_SYMBOL_GPL(pin_is_valid);
/* Deletes a range of pin descriptors */
static void pinctrl_free_pindescs(struct pinctrl_dev *pctldev,
const struct pinctrl_pin_desc *pins,
unsigned num_pins)
{
int i;
for (i = 0; i < num_pins; i++) {
struct pin_desc *pindesc;
pindesc = radix_tree_lookup(&pctldev->pin_desc_tree,
pins[i].number);
if (pindesc != NULL) {
radix_tree_delete(&pctldev->pin_desc_tree,
pins[i].number);
pinctrl: conjure names for unnamed pins If pins with blank names are registered, we assign them names on-the-fly on the form "PINn" where n is the pin number for that pin on the specific controller. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-14 23:33:37 +04:00
if (pindesc->dynamic_name)
kfree(pindesc->name);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
kfree(pindesc);
}
}
static int pinctrl_register_one_pin(struct pinctrl_dev *pctldev,
unsigned number, const char *name)
{
struct pin_desc *pindesc;
pindesc = pin_desc_get(pctldev, number);
if (pindesc != NULL) {
pr_err("pin %d already registered on %s\n", number,
pctldev->desc->name);
return -EINVAL;
}
pindesc = kzalloc(sizeof(*pindesc), GFP_KERNEL);
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
if (pindesc == NULL) {
dev_err(pctldev->dev, "failed to alloc struct pin_desc\n");
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return -ENOMEM;
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
}
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/* Set owner */
pindesc->pctldev = pctldev;
pinctrl: Don't copy pin names when registering them A pin controller's names array is no longer marked __refdata. Hence, we can avoid copying a pin's name into the descriptor when registering it. Instead, just point at the string supplied in the pin array. This both simplifies and speeds up pin controller initialization, but also removes the hard-coded maximum pin name length. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-20 02:19:27 +04:00
/* Copy basic pin info */
pinctrl: restore pin naming Commit ca53c5f1ca5c936777caca46b7c716a40682ce83 ("pinctrl: conjure names for unnamed pins") made pins lose their identity and only get autogenerated names. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-01 21:11:40 +04:00
if (name) {
pinctrl: conjure names for unnamed pins If pins with blank names are registered, we assign them names on-the-fly on the form "PINn" where n is the pin number for that pin on the specific controller. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-14 23:33:37 +04:00
pindesc->name = name;
} else {
pindesc->name = kasprintf(GFP_KERNEL, "PIN%u", number);
if (pindesc->name == NULL)
return -ENOMEM;
pindesc->dynamic_name = true;
}
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
radix_tree_insert(&pctldev->pin_desc_tree, number, pindesc);
pr_debug("registered pin %d (%s) on %s\n",
pinctrl: conjure names for unnamed pins If pins with blank names are registered, we assign them names on-the-fly on the form "PINn" where n is the pin number for that pin on the specific controller. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-14 23:33:37 +04:00
number, pindesc->name, pctldev->desc->name);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return 0;
}
static int pinctrl_register_pins(struct pinctrl_dev *pctldev,
struct pinctrl_pin_desc const *pins,
unsigned num_descs)
{
unsigned i;
int ret = 0;
for (i = 0; i < num_descs; i++) {
ret = pinctrl_register_one_pin(pctldev,
pins[i].number, pins[i].name);
if (ret)
return ret;
}
return 0;
}
/**
* pinctrl_match_gpio_range() - check if a certain GPIO pin is in range
* @pctldev: pin controller device to check
* @gpio: gpio pin to check taken from the global GPIO pin space
*
* Tries to match a GPIO pin number to the ranges handled by a certain pin
* controller, return the range or NULL
*/
static struct pinctrl_gpio_range *
pinctrl_match_gpio_range(struct pinctrl_dev *pctldev, unsigned gpio)
{
struct pinctrl_gpio_range *range = NULL;
/* Loop over the ranges */
list_for_each_entry(range, &pctldev->gpio_ranges, node) {
/* Check if we're in the valid range */
if (gpio >= range->base &&
gpio < range->base + range->npins) {
return range;
}
}
return NULL;
}
/**
* pinctrl_get_device_gpio_range() - find device for GPIO range
* @gpio: the pin to locate the pin controller for
* @outdev: the pin control device if found
* @outrange: the GPIO range if found
*
* Find the pin controller handling a certain GPIO pin from the pinspace of
* the GPIO subsystem, return the device and the matching GPIO range. Returns
* negative if the GPIO range could not be found in any device.
*/
pinctrl: core.c/h cleanups * Make all functions internal to core.c static. Remove any of these from core.h. * Add any missing EXPORT_SYMBOL_GPL(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:47 +04:00
static int pinctrl_get_device_gpio_range(unsigned gpio,
struct pinctrl_dev **outdev,
struct pinctrl_gpio_range **outrange)
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
{
struct pinctrl_dev *pctldev = NULL;
/* Loop over the pin controllers */
list_for_each_entry(pctldev, &pinctrldev_list, node) {
struct pinctrl_gpio_range *range;
range = pinctrl_match_gpio_range(pctldev, gpio);
if (range != NULL) {
*outdev = pctldev;
*outrange = range;
return 0;
}
}
return -EINVAL;
}
/**
* pinctrl_add_gpio_range() - register a GPIO range for a controller
* @pctldev: pin controller device to add the range to
* @range: the GPIO range to add
*
* This adds a range of GPIOs to be handled by a certain pin controller. Call
* this to register handled ranges after registering your pin controller.
*/
void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range)
{
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: use list_add_tail instead of list_add This mostly makes debugfs files print things in the order that they were added or acquired, which just feels a little more consistent. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:42 +04:00
list_add_tail(&range->node, &pctldev->gpio_ranges);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
pinctrl: core.c/h cleanups * Make all functions internal to core.c static. Remove any of these from core.h. * Add any missing EXPORT_SYMBOL_GPL(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:47 +04:00
EXPORT_SYMBOL_GPL(pinctrl_add_gpio_range);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/**
* pinctrl_remove_gpio_range() - remove a range of GPIOs fro a pin controller
* @pctldev: pin controller device to remove the range from
* @range: the GPIO range to remove
*/
void pinctrl_remove_gpio_range(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range)
{
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
list_del(&range->node);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
pinctrl: core.c/h cleanups * Make all functions internal to core.c static. Remove any of these from core.h. * Add any missing EXPORT_SYMBOL_GPL(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:47 +04:00
EXPORT_SYMBOL_GPL(pinctrl_remove_gpio_range);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
pinctrl: move group lookup to core Now also the core needs to look up pin groups so move the lookup function there and expose it in the internal header. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 19:07:16 +04:00
/**
* pinctrl_get_group_selector() - returns the group selector for a group
* @pctldev: the pin controller handling the group
* @pin_group: the pin group to look up
*/
int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
const char *pin_group)
{
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
unsigned group_selector = 0;
while (pctlops->list_groups(pctldev, group_selector) >= 0) {
const char *gname = pctlops->get_group_name(pctldev,
group_selector);
if (!strcmp(gname, pin_group)) {
pinctrl: don't create a device for each pin controller Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-10 03:59:05 +04:00
dev_dbg(pctldev->dev,
pinctrl: move group lookup to core Now also the core needs to look up pin groups so move the lookup function there and expose it in the internal header. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 19:07:16 +04:00
"found group selector %u for %s\n",
group_selector,
pin_group);
return group_selector;
}
group_selector++;
}
pinctrl: don't create a device for each pin controller Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-10 03:59:05 +04:00
dev_err(pctldev->dev, "does not have pin group %s\n",
pinctrl: move group lookup to core Now also the core needs to look up pin groups so move the lookup function there and expose it in the internal header. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 19:07:16 +04:00
pin_group);
return -EINVAL;
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
/**
* pinctrl_request_gpio() - request a single pin to be used in as GPIO
* @gpio: the GPIO pin number from the GPIO subsystem number space
*
* This function should *ONLY* be used from gpiolib-based GPIO drivers,
* as part of their gpio_request() semantics, platforms and individual drivers
* shall *NOT* request GPIO pins to be muxed in.
*/
int pinctrl_request_gpio(unsigned gpio)
{
struct pinctrl_dev *pctldev;
struct pinctrl_gpio_range *range;
int ret;
int pin;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
if (ret) {
mutex_unlock(&pinctrl_mutex);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return -EINVAL;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
/* Convert to the pin controllers number space */
pin = gpio - range->base + range->pin_base;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
ret = pinmux_request_gpio(pctldev, range, pin, gpio);
mutex_unlock(&pinctrl_mutex);
return ret;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
EXPORT_SYMBOL_GPL(pinctrl_request_gpio);
/**
* pinctrl_free_gpio() - free control on a single pin, currently used as GPIO
* @gpio: the GPIO pin number from the GPIO subsystem number space
*
* This function should *ONLY* be used from gpiolib-based GPIO drivers,
* as part of their gpio_free() semantics, platforms and individual drivers
* shall *NOT* request GPIO pins to be muxed out.
*/
void pinctrl_free_gpio(unsigned gpio)
{
struct pinctrl_dev *pctldev;
struct pinctrl_gpio_range *range;
int ret;
int pin;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
if (ret) {
mutex_unlock(&pinctrl_mutex);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
/* Convert to the pin controllers number space */
pin = gpio - range->base + range->pin_base;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
pinmux_free_gpio(pctldev, pin, range);
mutex_unlock(&pinctrl_mutex);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
EXPORT_SYMBOL_GPL(pinctrl_free_gpio);
static int pinctrl_gpio_direction(unsigned gpio, bool input)
{
struct pinctrl_dev *pctldev;
struct pinctrl_gpio_range *range;
int ret;
int pin;
ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
if (ret)
return ret;
/* Convert to the pin controllers number space */
pin = gpio - range->base + range->pin_base;
return pinmux_gpio_direction(pctldev, range, pin, input);
}
/**
* pinctrl_gpio_direction_input() - request a GPIO pin to go into input mode
* @gpio: the GPIO pin number from the GPIO subsystem number space
*
* This function should *ONLY* be used from gpiolib-based GPIO drivers,
* as part of their gpio_direction_input() semantics, platforms and individual
* drivers shall *NOT* touch pin control GPIO calls.
*/
int pinctrl_gpio_direction_input(unsigned gpio)
{
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
int ret;
mutex_lock(&pinctrl_mutex);
ret = pinctrl_gpio_direction(gpio, true);
mutex_unlock(&pinctrl_mutex);
return ret;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_input);
/**
* pinctrl_gpio_direction_output() - request a GPIO pin to go into output mode
* @gpio: the GPIO pin number from the GPIO subsystem number space
*
* This function should *ONLY* be used from gpiolib-based GPIO drivers,
* as part of their gpio_direction_output() semantics, platforms and individual
* drivers shall *NOT* touch pin control GPIO calls.
*/
int pinctrl_gpio_direction_output(unsigned gpio)
{
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
int ret;
mutex_lock(&pinctrl_mutex);
ret = pinctrl_gpio_direction(gpio, false);
mutex_unlock(&pinctrl_mutex);
return ret;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_output);
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
static struct pinctrl *pinctrl_get_locked(struct device *dev, const char *name)
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
{
struct pinctrl_dev *pctldev = NULL;
pinctrl: disallow map table entries with NULL dev_name field Hog entries are mapping table entries with .ctrl_dev_name == .dev_name. All other mapping table entries need .dev_name set so that they will match some pinctrl_get() call. All extant PIN_MAP*() macros set .dev_name. So, there is no reason to allow mapping table entries without .dev_name set. Update the code and documentation to disallow this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:58 +04:00
const char *devname;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
struct pinctrl *p;
unsigned num_maps = 0;
int ret = -ENODEV;
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
struct pinctrl_maps *maps_node;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
int i;
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
struct pinctrl_map const *map;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
pinctrl: assume map table entries can't have a NULL name field pinctrl_register_mappings() already requires that every mapping table entry have a non-NULL name field. Logically, this makes sense too; drivers should always request a specific named state so they know what they're getting. Relying on getting the first mentioned state in the mapping table is error-prone, and a nasty special case to implement, given that a given the mapping table may define multiple states for a device. Remove a small part of the documentation that talked about optionally requesting a specific state; it's mandatory now. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 05:48:33 +04:00
/* We must have both a dev and state name */
if (WARN_ON(!dev || !name))
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return ERR_PTR(-EINVAL);
pinctrl: disallow map table entries with NULL dev_name field Hog entries are mapping table entries with .ctrl_dev_name == .dev_name. All other mapping table entries need .dev_name set so that they will match some pinctrl_get() call. All extant PIN_MAP*() macros set .dev_name. So, there is no reason to allow mapping table entries without .dev_name set. Update the code and documentation to disallow this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:58 +04:00
devname = dev_name(dev);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
dev_dbg(dev, "pinctrl_get() for device %s state %s\n", devname, name);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
/*
* create the state cookie holder struct pinctrl for each
* mapping, this is what consumers will get when requesting
* a pin control handle with pinctrl_get()
*/
pinctrl: allocate sizeof(*p) instead of sizeof(struct foo) This hopefully makes it harder to take the sizeof the wrong type. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:26:00 +04:00
p = kzalloc(sizeof(*p), GFP_KERNEL);
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
if (p == NULL) {
dev_err(dev, "failed to alloc struct pinctrl\n");
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return ERR_PTR(-ENOMEM);
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
pinmux_init_pinctrl_handle(p);
/* Iterate over the pin control maps to locate the right ones */
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
for_each_maps(maps_node, i, map) {
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
/*
* First, try to find the pctldev given in the map
*/
pctldev = get_pinctrl_dev_from_devname(map->ctrl_dev_name);
if (!pctldev) {
pinctrl: error if mapping table's control dev can't be found This is a serious error, and the pin control system will not function correctly if it ends up not programing the mapping table entries into the HW. Instead of just ignoring this, error out. Signed-off-by: Stephen Warren <swarren@nvidia.com> [rebased to fit the applied patch series, cast error to pointer] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:53 +04:00
dev_err(dev, "unknown pinctrl device %s in map entry",
map->ctrl_dev_name);
pinmux_put(p);
kfree(p);
/* Eventually, this should trigger deferred probe */
return ERR_PTR(-ENODEV);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
dev_dbg(dev, "in map, found pctldev %s to handle function %s",
dev_name(pctldev->dev), map->function);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
pinctrl: disallow map table entries with NULL dev_name field Hog entries are mapping table entries with .ctrl_dev_name == .dev_name. All other mapping table entries need .dev_name set so that they will match some pinctrl_get() call. All extant PIN_MAP*() macros set .dev_name. So, there is no reason to allow mapping table entries without .dev_name set. Update the code and documentation to disallow this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:58 +04:00
/* Map must be for this device */
if (strcmp(map->dev_name, devname))
continue;
pinctrl: assume map table entries can't have a NULL name field pinctrl_register_mappings() already requires that every mapping table entry have a non-NULL name field. Logically, this makes sense too; drivers should always request a specific named state so they know what they're getting. Relying on getting the first mentioned state in the mapping table is error-prone, and a nasty special case to implement, given that a given the mapping table may define multiple states for a device. Remove a small part of the documentation that talked about optionally requesting a specific state; it's mandatory now. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 05:48:33 +04:00
/* State name must be the one we're looking for */
if (strcmp(map->name, name))
continue;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
pinctrl: disallow map table entries with NULL dev_name field Hog entries are mapping table entries with .ctrl_dev_name == .dev_name. All other mapping table entries need .dev_name set so that they will match some pinctrl_get() call. All extant PIN_MAP*() macros set .dev_name. So, there is no reason to allow mapping table entries without .dev_name set. Update the code and documentation to disallow this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:58 +04:00
ret = pinmux_apply_muxmap(pctldev, p, dev, devname, map);
if (ret) {
kfree(p);
return ERR_PTR(ret);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
pinctrl: disallow map table entries with NULL dev_name field Hog entries are mapping table entries with .ctrl_dev_name == .dev_name. All other mapping table entries need .dev_name set so that they will match some pinctrl_get() call. All extant PIN_MAP*() macros set .dev_name. So, there is no reason to allow mapping table entries without .dev_name set. Update the code and documentation to disallow this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:58 +04:00
num_maps++;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
pinctrl: downgrade pinctrl_get warning when no maps are found This may be perfectly legitimate. An IP block may get re-used across SoCs. Not all of those SoCs may need pinmux settings for the IP block, e.g. if one SoC dedicates pins to that function but another doesn't. The driver won't know this, and will always attempt to set up the pinmux. The mapping table defines whether any HW programming is actually needed. Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Stephen Warren <swarren@nvidia.com> [rebased to fit the applied patch series] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:51 +04:00
/*
* This may be perfectly legitimate. An IP block may get re-used
* across SoCs. Not all of those SoCs may need pinmux settings for the
* IP block, e.g. if one SoC dedicates pins to that function but
* another doesn't. The driver won't know this, and will always
* attempt to set up the pinmux. The mapping table defines whether any
* HW programming is actually needed.
*/
if (!num_maps)
dev_info(dev, "zero maps found for mapping %s\n", name);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
dev_dbg(dev, "found %u maps for device %s state %s\n",
num_maps, devname, name ? name : "(undefined)");
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
/* Add the pinmux to the global list */
pinctrl: use list_add_tail instead of list_add This mostly makes debugfs files print things in the order that they were added or acquired, which just feels a little more consistent. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:42 +04:00
list_add_tail(&p->node, &pinctrl_list);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return p;
}
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
/**
* pinctrl_get() - retrieves the pin controller handle for a certain device
* @dev: the device to get the pin controller handle for
* @name: an optional specific control mapping name or NULL, the name is only
* needed if you want to have more than one mapping per device, or if you
* need an anonymous pin control (not tied to any specific device)
*/
struct pinctrl *pinctrl_get(struct device *dev, const char *name)
{
struct pinctrl *p;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
p = pinctrl_get_locked(dev, name);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
return p;
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
EXPORT_SYMBOL_GPL(pinctrl_get);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
static void pinctrl_put_locked(struct pinctrl *p)
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
{
if (p == NULL)
return;
if (p->usecount)
pr_warn("releasing pin control handle with active users!\n");
/* Free the groups and all acquired pins */
pinmux_put(p);
/* Remove from list */
list_del(&p->node);
kfree(p);
}
/**
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
* pinctrl_put() - release a previously claimed pin control handle
* @p: a pin control handle previously claimed by pinctrl_get()
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
*/
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
void pinctrl_put(struct pinctrl *p)
{
mutex_lock(&pinctrl_mutex);
pinctrl_put(p);
mutex_unlock(&pinctrl_mutex);
}
EXPORT_SYMBOL_GPL(pinctrl_put);
static int pinctrl_enable_locked(struct pinctrl *p)
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
{
int ret = 0;
if (p == NULL)
return -EINVAL;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
if (p->usecount++ == 0) {
ret = pinmux_enable(p);
if (ret)
p->usecount--;
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return ret;
}
/**
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
* pinctrl_enable() - enable a certain pin controller setting
* @p: the pin control handle to enable, previously claimed by pinctrl_get()
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
*/
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
int pinctrl_enable(struct pinctrl *p)
{
int ret;
mutex_lock(&pinctrl_mutex);
ret = pinctrl_enable_locked(p);
mutex_unlock(&pinctrl_mutex);
return ret;
}
EXPORT_SYMBOL_GPL(pinctrl_enable);
static void pinctrl_disable_locked(struct pinctrl *p)
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
{
if (p == NULL)
return;
if (--p->usecount == 0) {
pinmux_disable(p);
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
}
/**
* pinctrl_disable() - disable a certain pin control setting
* @p: the pin control handle to disable, previously claimed by pinctrl_get()
*/
void pinctrl_disable(struct pinctrl *p)
{
mutex_lock(&pinctrl_mutex);
pinctrl_disable_locked(p);
mutex_unlock(&pinctrl_mutex);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
EXPORT_SYMBOL_GPL(pinctrl_disable);
/**
* pinctrl_register_mappings() - register a set of pin controller mappings
pinctrl: pinctrl_register_mappings() shouldn't be __init It may be common for pinctrl_register_mappings() to be used from __init context, but there's no reason that additional mappings shouldn't be added at a later point, e.g. if loading modules that add pin controllers and their mapping tables. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:41 +04:00
* @maps: the pincontrol mappings table to register. This should probably be
* marked with __initdata so it can be discarded after boot. This
* function will perform a shallow copy for the mapping entries.
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
* @num_maps: the number of maps in the mapping table
*/
pinctrl: pinctrl_register_mappings() shouldn't be __init It may be common for pinctrl_register_mappings() to be used from __init context, but there's no reason that additional mappings shouldn't be added at a later point, e.g. if loading modules that add pin controllers and their mapping tables. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:41 +04:00
int pinctrl_register_mappings(struct pinctrl_map const *maps,
unsigned num_maps)
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
{
int i;
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
struct pinctrl_maps *maps_node;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
pr_debug("add %d pinmux maps\n", num_maps);
/* First sanity check the new mapping */
for (i = 0; i < num_maps; i++) {
if (!maps[i].name) {
pr_err("failed to register map %d: no map name given\n",
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
i);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return -EINVAL;
}
if (!maps[i].ctrl_dev_name) {
pr_err("failed to register map %s (%d): no pin control device given\n",
maps[i].name, i);
return -EINVAL;
}
if (!maps[i].function) {
pr_err("failed to register map %s (%d): no function ID given\n",
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
maps[i].name, i);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return -EINVAL;
}
pinctrl: disallow map table entries with NULL dev_name field Hog entries are mapping table entries with .ctrl_dev_name == .dev_name. All other mapping table entries need .dev_name set so that they will match some pinctrl_get() call. All extant PIN_MAP*() macros set .dev_name. So, there is no reason to allow mapping table entries without .dev_name set. Update the code and documentation to disallow this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:58 +04:00
if (!maps[i].dev_name) {
pr_err("failed to register map %s (%d): no device given\n",
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
maps[i].name, i);
pinctrl: disallow map table entries with NULL dev_name field Hog entries are mapping table entries with .ctrl_dev_name == .dev_name. All other mapping table entries need .dev_name set so that they will match some pinctrl_get() call. All extant PIN_MAP*() macros set .dev_name. So, there is no reason to allow mapping table entries without .dev_name set. Update the code and documentation to disallow this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:58 +04:00
return -EINVAL;
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
maps_node = kzalloc(sizeof(*maps_node), GFP_KERNEL);
if (!maps_node) {
pr_err("failed to alloc struct pinctrl_maps\n");
return -ENOMEM;
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
maps_node->num_maps = num_maps;
maps_node->maps = kmemdup(maps, sizeof(*maps) * num_maps, GFP_KERNEL);
if (!maps_node->maps) {
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
pr_err("failed to duplicate mapping table\n");
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
kfree(maps_node);
return -ENOMEM;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
list_add_tail(&maps_node->node, &pinctrl_maps);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
pinctrl: Store mapping table as a list of chunks Instead of storing a single array of mapping table entries, which requires realloc()ing that array each time it's extended and copying the new data, simply store a list of pointers to the individual chunks. This also removes the need to copy the mapping table at all; a pointer is maintained to the original table, this saving memory. A macro for_each_maps() is introduced to hide the additional complexity of iterating over the map entries. This change will also simplify removing chunks of entries from the mapping table. This isn't important right now, but will be in the future, when mapping table entries are dynamically added when parsing them from the device tree, and removed when drivers no longer need to interact with pinctrl. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:43 +04:00
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return 0;
}
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
#ifdef CONFIG_DEBUG_FS
static int pinctrl_pins_show(struct seq_file *s, void *what)
{
struct pinctrl_dev *pctldev = s->private;
const struct pinctrl_ops *ops = pctldev->desc->pctlops;
pinctrl: correct a offset while enumerating pins This patch modifies a offset while enumerating pins to support a partial pin space. If we use a pin number for enumerating pins, the pin space always starts with zero base. Indeed, we always check the pin is in the pin space. An extreme example, there is only two pins. One is 0. Another is 1000. We always enumerate whole offsets until 1000. For solving this problem, we use the offset of the pin array instead of the zero-based pin number. Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> [Restored sparse pin space comment] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-03 11:47:50 +04:00
unsigned i, pin;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
seq_printf(s, "registered pins: %d\n", pctldev->desc->npins);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: correct a offset while enumerating pins This patch modifies a offset while enumerating pins to support a partial pin space. If we use a pin number for enumerating pins, the pin space always starts with zero base. Indeed, we always check the pin is in the pin space. An extreme example, there is only two pins. One is 0. Another is 1000. We always enumerate whole offsets until 1000. For solving this problem, we use the offset of the pin array instead of the zero-based pin number. Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> [Restored sparse pin space comment] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-03 11:47:50 +04:00
/* The pin number can be retrived from the pin controller descriptor */
for (i = 0; i < pctldev->desc->npins; i++) {
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
struct pin_desc *desc;
pinctrl: correct a offset while enumerating pins This patch modifies a offset while enumerating pins to support a partial pin space. If we use a pin number for enumerating pins, the pin space always starts with zero base. Indeed, we always check the pin is in the pin space. An extreme example, there is only two pins. One is 0. Another is 1000. We always enumerate whole offsets until 1000. For solving this problem, we use the offset of the pin array instead of the zero-based pin number. Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> [Restored sparse pin space comment] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-03 11:47:50 +04:00
pin = pctldev->desc->pins[i].number;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
desc = pin_desc_get(pctldev, pin);
/* Pin space may be sparse */
if (desc == NULL)
continue;
seq_printf(s, "pin %d (%s) ", pin,
desc->name ? desc->name : "unnamed");
/* Driver-specific info per pin */
if (ops->pin_dbg_show)
ops->pin_dbg_show(pctldev, s, pin);
seq_puts(s, "\n");
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return 0;
}
static int pinctrl_groups_show(struct seq_file *s, void *what)
{
struct pinctrl_dev *pctldev = s->private;
const struct pinctrl_ops *ops = pctldev->desc->pctlops;
unsigned selector = 0;
/* No grouping */
if (!ops)
return 0;
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
seq_puts(s, "registered pin groups:\n");
while (ops->list_groups(pctldev, selector) >= 0) {
pinctrl: get_group_pins() const fixes get_group_pins() "returns" a pointer to an array of const objects, through a pointer parameter. Fix the prototype so what's pointed at by the returned pointer is const, rather than the function parameter being const. This also allows the removal of a cast in each of the two current pinmux drivers. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-20 02:19:25 +04:00
const unsigned *pins;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
unsigned num_pins;
const char *gname = ops->get_group_name(pctldev, selector);
int ret;
int i;
ret = ops->get_group_pins(pctldev, selector,
&pins, &num_pins);
if (ret)
seq_printf(s, "%s [ERROR GETTING PINS]\n",
gname);
else {
seq_printf(s, "group: %s, pins = [ ", gname);
for (i = 0; i < num_pins; i++)
seq_printf(s, "%d ", pins[i]);
seq_puts(s, "]\n");
}
selector++;
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return 0;
}
static int pinctrl_gpioranges_show(struct seq_file *s, void *what)
{
struct pinctrl_dev *pctldev = s->private;
struct pinctrl_gpio_range *range = NULL;
seq_puts(s, "GPIO ranges handled:\n");
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/* Loop over the ranges */
list_for_each_entry(range, &pctldev->gpio_ranges, node) {
pinctrl: print pin range in GPIO range debugs Show the mapped pin range corresponding to the GPIO range in debugfs for pin controllers. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-16 12:58:51 +04:00
seq_printf(s, "%u: %s GPIOS [%u - %u] PINS [%u - %u]\n",
range->id, range->name,
range->base, (range->base + range->npins - 1),
range->pin_base,
(range->pin_base + range->npins - 1));
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return 0;
}
static int pinctrl_devices_show(struct seq_file *s, void *what)
{
struct pinctrl_dev *pctldev;
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
seq_puts(s, "name [pinmux] [pinconf]\n");
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
list_for_each_entry(pctldev, &pinctrldev_list, node) {
seq_printf(s, "%s ", pctldev->desc->name);
if (pctldev->desc->pmxops)
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
seq_puts(s, "yes ");
else
seq_puts(s, "no ");
if (pctldev->desc->confops)
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
seq_puts(s, "yes");
else
seq_puts(s, "no");
seq_puts(s, "\n");
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return 0;
}
pinctrl: move pinctrl-maps debugfs file to top-level The debugfs file pinctrl-maps is a system-wide file, not specific to any pin controller, so place it in the top-level directory. Also, move the code implementing the file to keep the order of all the functions matching the order they're created in pinctrl_init_*debugfs(). The only non-obvious change here is no private data is passed to debugfs_create_file() or single_open(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-24 04:04:40 +04:00
static int pinctrl_maps_show(struct seq_file *s, void *what)
{
struct pinctrl_maps *maps_node;
int i;
struct pinctrl_map const *map;
seq_puts(s, "Pinctrl maps:\n");
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: move pinctrl-maps debugfs file to top-level The debugfs file pinctrl-maps is a system-wide file, not specific to any pin controller, so place it in the top-level directory. Also, move the code implementing the file to keep the order of all the functions matching the order they're created in pinctrl_init_*debugfs(). The only non-obvious change here is no private data is passed to debugfs_create_file() or single_open(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-24 04:04:40 +04:00
for_each_maps(maps_node, i, map) {
seq_printf(s, "%s:\n", map->name);
seq_printf(s, " device: %s\n", map->dev_name);
seq_printf(s, " controlling device %s\n", map->ctrl_dev_name);
seq_printf(s, " function: %s\n", map->function);
seq_printf(s, " group: %s\n", map->group ? map->group :
"(default)");
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
pinctrl: move pinctrl-maps debugfs file to top-level The debugfs file pinctrl-maps is a system-wide file, not specific to any pin controller, so place it in the top-level directory. Also, move the code implementing the file to keep the order of all the functions matching the order they're created in pinctrl_init_*debugfs(). The only non-obvious change here is no private data is passed to debugfs_create_file() or single_open(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-24 04:04:40 +04:00
return 0;
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
static int pinctrl_show(struct seq_file *s, void *what)
{
struct pinctrl *p;
seq_puts(s, "Requested pin control handlers their pinmux maps:\n");
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
list_for_each_entry(p, &pinctrl_list, node) {
struct pinctrl_dev *pctldev = p->pctldev;
if (!pctldev) {
seq_puts(s, "NO PIN CONTROLLER DEVICE\n");
continue;
}
seq_printf(s, "device: %s",
pinctrl_dev_get_name(p->pctldev));
pinmux_dbg_show(s, p);
seq_printf(s, " users: %u map-> %s\n",
p->usecount,
p->dev ? dev_name(p->dev) : "(system)");
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
return 0;
}
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
static int pinctrl_pins_open(struct inode *inode, struct file *file)
{
return single_open(file, pinctrl_pins_show, inode->i_private);
}
static int pinctrl_groups_open(struct inode *inode, struct file *file)
{
return single_open(file, pinctrl_groups_show, inode->i_private);
}
static int pinctrl_gpioranges_open(struct inode *inode, struct file *file)
{
return single_open(file, pinctrl_gpioranges_show, inode->i_private);
}
static int pinctrl_devices_open(struct inode *inode, struct file *file)
{
return single_open(file, pinctrl_devices_show, NULL);
}
pinctrl: move pinctrl-maps debugfs file to top-level The debugfs file pinctrl-maps is a system-wide file, not specific to any pin controller, so place it in the top-level directory. Also, move the code implementing the file to keep the order of all the functions matching the order they're created in pinctrl_init_*debugfs(). The only non-obvious change here is no private data is passed to debugfs_create_file() or single_open(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-24 04:04:40 +04:00
static int pinctrl_maps_open(struct inode *inode, struct file *file)
{
return single_open(file, pinctrl_maps_show, NULL);
}
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
static int pinctrl_open(struct inode *inode, struct file *file)
{
return single_open(file, pinctrl_show, NULL);
}
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
static const struct file_operations pinctrl_pins_ops = {
.open = pinctrl_pins_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
static const struct file_operations pinctrl_groups_ops = {
.open = pinctrl_groups_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
static const struct file_operations pinctrl_gpioranges_ops = {
.open = pinctrl_gpioranges_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
pinctrl: move pinctrl-maps debugfs file to top-level The debugfs file pinctrl-maps is a system-wide file, not specific to any pin controller, so place it in the top-level directory. Also, move the code implementing the file to keep the order of all the functions matching the order they're created in pinctrl_init_*debugfs(). The only non-obvious change here is no private data is passed to debugfs_create_file() or single_open(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-24 04:04:40 +04:00
static const struct file_operations pinctrl_devices_ops = {
.open = pinctrl_devices_open,
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
pinctrl: move pinctrl-maps debugfs file to top-level The debugfs file pinctrl-maps is a system-wide file, not specific to any pin controller, so place it in the top-level directory. Also, move the code implementing the file to keep the order of all the functions matching the order they're created in pinctrl_init_*debugfs(). The only non-obvious change here is no private data is passed to debugfs_create_file() or single_open(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-24 04:04:40 +04:00
static const struct file_operations pinctrl_maps_ops = {
.open = pinctrl_maps_open,
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
static const struct file_operations pinctrl_ops = {
.open = pinctrl_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
static struct dentry *debugfs_root;
static void pinctrl_init_device_debugfs(struct pinctrl_dev *pctldev)
{
pinctrl: free debugfs entries when unloading a pinmux driver We were not cleaning up properly after unloading a pinmux driver compiled as module. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-20 20:17:22 +04:00
struct dentry *device_root;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
pinctrl: don't create a device for each pin controller Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-10 03:59:05 +04:00
device_root = debugfs_create_dir(dev_name(pctldev->dev),
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
debugfs_root);
pinctrl: free debugfs entries when unloading a pinmux driver We were not cleaning up properly after unloading a pinmux driver compiled as module. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-20 20:17:22 +04:00
pctldev->device_root = device_root;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
if (IS_ERR(device_root) || !device_root) {
pr_warn("failed to create debugfs directory for %s\n",
pinctrl: don't create a device for each pin controller Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-10 03:59:05 +04:00
dev_name(pctldev->dev));
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return;
}
debugfs_create_file("pins", S_IFREG | S_IRUGO,
device_root, pctldev, &pinctrl_pins_ops);
debugfs_create_file("pingroups", S_IFREG | S_IRUGO,
device_root, pctldev, &pinctrl_groups_ops);
debugfs_create_file("gpio-ranges", S_IFREG | S_IRUGO,
device_root, pctldev, &pinctrl_gpioranges_ops);
pinmux_init_device_debugfs(device_root, pctldev);
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
pinconf_init_device_debugfs(device_root, pctldev);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
pinctrl: free debugfs entries when unloading a pinmux driver We were not cleaning up properly after unloading a pinmux driver compiled as module. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-20 20:17:22 +04:00
static void pinctrl_remove_device_debugfs(struct pinctrl_dev *pctldev)
{
debugfs_remove_recursive(pctldev->device_root);
}
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
static void pinctrl_init_debugfs(void)
{
debugfs_root = debugfs_create_dir("pinctrl", NULL);
if (IS_ERR(debugfs_root) || !debugfs_root) {
pr_warn("failed to create debugfs directory\n");
debugfs_root = NULL;
return;
}
debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
debugfs_root, NULL, &pinctrl_devices_ops);
pinctrl: move pinctrl-maps debugfs file to top-level The debugfs file pinctrl-maps is a system-wide file, not specific to any pin controller, so place it in the top-level directory. Also, move the code implementing the file to keep the order of all the functions matching the order they're created in pinctrl_init_*debugfs(). The only non-obvious change here is no private data is passed to debugfs_create_file() or single_open(). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-24 04:04:40 +04:00
debugfs_create_file("pinctrl-maps", S_IFREG | S_IRUGO,
debugfs_root, NULL, &pinctrl_maps_ops);
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 22:47:48 +04:00
debugfs_create_file("pinctrl-handles", S_IFREG | S_IRUGO,
debugfs_root, NULL, &pinctrl_ops);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
#else /* CONFIG_DEBUG_FS */
static void pinctrl_init_device_debugfs(struct pinctrl_dev *pctldev)
{
}
static void pinctrl_init_debugfs(void)
{
}
pinctrl: free debugfs entries when unloading a pinmux driver We were not cleaning up properly after unloading a pinmux driver compiled as module. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-20 20:17:22 +04:00
static void pinctrl_remove_device_debugfs(struct pinctrl_dev *pctldev)
{
}
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
#endif
/**
* pinctrl_register() - register a pin controller device
* @pctldesc: descriptor for this pin controller
* @dev: parent device for this pin controller
* @driver_data: private pin controller data for this pin controller
*/
struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
struct device *dev, void *driver_data)
{
struct pinctrl_dev *pctldev;
int ret;
if (pctldesc == NULL)
return NULL;
if (pctldesc->name == NULL)
return NULL;
pinctrl: allocate sizeof(*p) instead of sizeof(struct foo) This hopefully makes it harder to take the sizeof the wrong type. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:26:00 +04:00
pctldev = kzalloc(sizeof(*pctldev), GFP_KERNEL);
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
if (pctldev == NULL) {
dev_err(dev, "failed to alloc struct pinctrl_dev\n");
pinctrl: add checks for empty function names This is needed as otherwise we can get the following when dealing with buggy data in a pinmux driver for pinmux_search_function: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at strcmp+0xc/0x34 LR is at pinmux_get+0x350/0x8f4 ... As we need pctldev initialized to call ops->list_functions, let's initialize it before check_ops calls and pass the pctldev to the check_ops functions. Do this for both pinmux and pinconf check_ops functions. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-25 04:28:08 +04:00
return NULL;
pinctrl: use dev_*() instead of pr_*(), add some msgs, minor cleanups e.g. dev_err instead of pr_err prints messages in a slightly more standardized format. Also, add a few more error messages to track down errors. Also, some small cleanups of messages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:25:59 +04:00
}
pinctrl: add checks for empty function names This is needed as otherwise we can get the following when dealing with buggy data in a pinmux driver for pinmux_search_function: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at strcmp+0xc/0x34 LR is at pinmux_get+0x350/0x8f4 ... As we need pctldev initialized to call ops->list_functions, let's initialize it before check_ops calls and pass the pctldev to the check_ops functions. Do this for both pinmux and pinconf check_ops functions. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-25 04:28:08 +04:00
/* Initialize pin control device struct */
pctldev->owner = pctldesc->owner;
pctldev->desc = pctldesc;
pctldev->driver_data = driver_data;
INIT_RADIX_TREE(&pctldev->pin_desc_tree, GFP_KERNEL);
INIT_LIST_HEAD(&pctldev->gpio_ranges);
pctldev->dev = dev;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/* If we're implementing pinmuxing, check the ops for sanity */
if (pctldesc->pmxops) {
pinctrl: add checks for empty function names This is needed as otherwise we can get the following when dealing with buggy data in a pinmux driver for pinmux_search_function: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at strcmp+0xc/0x34 LR is at pinmux_get+0x350/0x8f4 ... As we need pctldev initialized to call ops->list_functions, let's initialize it before check_ops calls and pass the pctldev to the check_ops functions. Do this for both pinmux and pinconf check_ops functions. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-25 04:28:08 +04:00
ret = pinmux_check_ops(pctldev);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
if (ret) {
pr_err("%s pinmux ops lacks necessary functions\n",
pctldesc->name);
pinctrl: add checks for empty function names This is needed as otherwise we can get the following when dealing with buggy data in a pinmux driver for pinmux_search_function: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at strcmp+0xc/0x34 LR is at pinmux_get+0x350/0x8f4 ... As we need pctldev initialized to call ops->list_functions, let's initialize it before check_ops calls and pass the pctldev to the check_ops functions. Do this for both pinmux and pinconf check_ops functions. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-25 04:28:08 +04:00
goto out_err;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
}
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
/* If we're implementing pinconfig, check the ops for sanity */
if (pctldesc->confops) {
pinctrl: add checks for empty function names This is needed as otherwise we can get the following when dealing with buggy data in a pinmux driver for pinmux_search_function: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at strcmp+0xc/0x34 LR is at pinmux_get+0x350/0x8f4 ... As we need pctldev initialized to call ops->list_functions, let's initialize it before check_ops calls and pass the pctldev to the check_ops functions. Do this for both pinmux and pinconf check_ops functions. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-25 04:28:08 +04:00
ret = pinconf_check_ops(pctldev);
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
if (ret) {
pr_err("%s pin config ops lacks necessary functions\n",
pctldesc->name);
pinctrl: add checks for empty function names This is needed as otherwise we can get the following when dealing with buggy data in a pinmux driver for pinmux_search_function: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at strcmp+0xc/0x34 LR is at pinmux_get+0x350/0x8f4 ... As we need pctldev initialized to call ops->list_functions, let's initialize it before check_ops calls and pass the pctldev to the check_ops functions. Do this for both pinmux and pinconf check_ops functions. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-25 04:28:08 +04:00
goto out_err;
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 20:14:33 +04:00
}
}
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/* Register all the pins */
pr_debug("try to register %d pins on %s...\n",
pctldesc->npins, pctldesc->name);
ret = pinctrl_register_pins(pctldev, pctldesc->pins, pctldesc->npins);
if (ret) {
pr_err("error during pin registration\n");
pinctrl_free_pindescs(pctldev, pctldesc->pins,
pctldesc->npins);
pinctrl: don't create a device for each pin controller Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-10 03:59:05 +04:00
goto out_err;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: use list_add_tail instead of list_add This mostly makes debugfs files print things in the order that they were added or acquired, which just feels a little more consistent. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 10:45:42 +04:00
list_add_tail(&pctldev->node, &pinctrldev_list);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
pctldev->p = pinctrl_get_locked(pctldev->dev, PINCTRL_STATE_DEFAULT);
pinctrl: introduce PINCTRL_STATE_DEFAULT, define hogs as that state This provides a single centralized name for the default state. Update PIN_MAP_* macros to use this state name, instead of requiring the user to pass a state name in. With this change, hog entries in the mapping table are defined as those with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same name. This interacts badly with the nested iteration over mapping table entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now attempt to claim each hog mapping table entry multiple times. Replacing the custom hog code with a simple pinctrl_get()/pinctrl_enable(). Update documentation and mapping tables to use this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 05:48:32 +04:00
if (!IS_ERR(pctldev->p))
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
pinctrl_enable_locked(pctldev->p);
mutex_unlock(&pinctrl_mutex);
pinctrl: remove pin and hogs locks from struct pinctrl_dev struct pinctrl_dev's pin_desc_tree_lock and pinctrl_hogs_lock aren't useful; the data they protect is read-only except when registering or unregistering a pinctrl_dev, and at those times, it doesn't make sense to protect one part of the structure independently from the rest. Move pinctrl_init_device_debugfs() to the end of pinctrl_register() so that debugfs can't access the struct pinctrl_dev until it's fully initialized, i.e. after the hogs are set up. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-23 01:26:01 +04:00
pinctrl_init_device_debugfs(pctldev);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return pctldev;
pinctrl: don't create a device for each pin controller Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-10 03:59:05 +04:00
out_err:
kfree(pctldev);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
return NULL;
}
EXPORT_SYMBOL_GPL(pinctrl_register);
/**
* pinctrl_unregister() - unregister pinmux
* @pctldev: pin controller to unregister
*
* Called by pinmux drivers to unregister a pinmux.
*/
void pinctrl_unregister(struct pinctrl_dev *pctldev)
{
if (pctldev == NULL)
return;
pinctrl: free debugfs entries when unloading a pinmux driver We were not cleaning up properly after unloading a pinmux driver compiled as module. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-20 20:17:22 +04:00
pinctrl_remove_device_debugfs(pctldev);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_lock(&pinctrl_mutex);
pinctrl: introduce PINCTRL_STATE_DEFAULT, define hogs as that state This provides a single centralized name for the default state. Update PIN_MAP_* macros to use this state name, instead of requiring the user to pass a state name in. With this change, hog entries in the mapping table are defined as those with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same name. This interacts badly with the nested iteration over mapping table entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now attempt to claim each hog mapping table entry multiple times. Replacing the custom hog code with a simple pinctrl_get()/pinctrl_enable(). Update documentation and mapping tables to use this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 05:48:32 +04:00
if (!IS_ERR(pctldev->p)) {
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
pinctrl_disable_locked(pctldev->p);
pinctrl_put_locked(pctldev->p);
pinctrl: introduce PINCTRL_STATE_DEFAULT, define hogs as that state This provides a single centralized name for the default state. Update PIN_MAP_* macros to use this state name, instead of requiring the user to pass a state name in. With this change, hog entries in the mapping table are defined as those with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same name. This interacts badly with the nested iteration over mapping table entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now attempt to claim each hog mapping table entry multiple times. Replacing the custom hog code with a simple pinctrl_get()/pinctrl_enable(). Update documentation and mapping tables to use this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 05:48:32 +04:00
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
/* TODO: check that no pinmuxes are still active? */
list_del(&pctldev->node);
/* Destroy descriptor tree */
pinctrl_free_pindescs(pctldev, pctldev->desc->pins,
pctldev->desc->npins);
pinctrl: don't create a device for each pin controller Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-10 03:59:05 +04:00
kfree(pctldev);
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-03 00:05:44 +04:00
mutex_unlock(&pinctrl_mutex);
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. 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. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
}
EXPORT_SYMBOL_GPL(pinctrl_unregister);
static int __init pinctrl_init(void)
{
pr_info("initialized pinctrl subsystem\n");
pinctrl_init_debugfs();
return 0;
}
/* init early since many drivers really need to initialized pinmux early */
core_initcall(pinctrl_init);
Reference in New Issue Copy Permalink