Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-11-15 08:31:55 +00:00
Code Issues Packages Projects Releases Wiki Activity
06763c741b
linux/drivers/pinctrl/Kconfig

203 lines
3.7 KiB
Plaintext
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 18:50:54 +00:00
#
# PINCTRL infrastructure and drivers
#
pinctrl: hide subsystem from the populace Machines that have embedded pin controllers need to select them explicitly, so why broadcast their config options to menuconfig. We provide a helpful submenu for those machines that do select it, making it possible to enable debugging for example. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-05 20:28:46 +00:00
config PINCTRL
bool
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 18:50:54 +00:00
if PINCTRL
pinctrl: hide subsystem from the populace Machines that have embedded pin controllers need to select them explicitly, so why broadcast their config options to menuconfig. We provide a helpful submenu for those machines that do select it, making it possible to enable debugging for example. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-05 20:28:46 +00:00
menu "Pin controllers"
depends on PINCTRL
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 18:50:54 +00:00
config PINMUX
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 16:14:33 +00:00
bool "Support pin multiplexing controllers"
config PINCONF
bool "Support pin configuration controllers"
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 18:50:54 +00:00
pinctrl: introduce generic pin config This is a split-off from the earlier patch set which adds generic pin configuration for the pin controllers that want it. Since we may have a system with mixed generic and custom pin controllers, we pass a boolean in the pin controller ops vtable to indicate if it is generic. ChangeLog v1->v5: - Follow parent patch versioning number system. - Document the semantic meaning of return values from pin config get functions, so we can iterate over pins and check their properties from debugfs as part of the generic config code. - Use proper cast functions in the generic debugfs pin config file. - Expand generic config to optionally cover groups too. ChangeLog v5->v6: - Update to match underlying changes. ChangeLog v6->v7: - Drop DRIVE_OFF parameter, use bias high impedance for this - Delete argument for drive modes push-pull, od and os. These are now just state transitions. - Delete slew rate rising/falling due to discussions on on proper semantics - Drop config wakeup, struct irq_chip does this for now, add back if need be. - Set PIN_CONFIG_END to 0x7fff making room for custom config parameters from 0x8000 and up. - Prefix accessor functions with pinconf_
2011-11-24 17:27:15 +00:00
config GENERIC_PINCONF
bool
select PINCONF
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 18:50:54 +00:00
config DEBUG_PINCTRL
bool "Debug PINCTRL calls"
depends on DEBUG_KERNEL
help
Say Y here to add some extra checks and diagnostics to PINCTRL calls.
pinctrl: add bcm2835 driver The BCM2835 GPIO module is a combined GPIO controller, (GPIO) interrupt controller, and pinmux/control device. Original driver by Simon Arlott. Rewrite including GPIO chip device by Chris Boot. Upstreaming changes by Stephen Warren: * Wrote DT binding documentation. * Changed brcm,function to an integer to more directly match the datasheet, and to match brcm,pins being an integer. * Implemented pull-up/down pin config. * Removed read-only DT property and related code. The restriction this implemented are driven by the board, not the GPIO HW block, so don't really make sense of a HW block binding, were in general incomplete (since they could only know about the few pins hard-coded into the Raspberry Pi B board design and not the uncommitted GPIOS), and are better represented simply by not writing incorrect data into pin configuration nodes. * Don't set GPIO_IN function select in gpio_request_enable() to avoid glitches; defer this to gpio_set_direction(). Consequently, removed empty bcm2835_pmx_gpio_request_enable(). * Simplified enabled_irq_map[]; make it explicitly 1 entry per bank. * Lifted use of enabled_irq_map[] outside the per-interrupt loop in IRQ handler, thus fixing an issue where the code was indexing into enabled_irq_map[] by intra-bank GPIO ID, not global GPIO ID. * Removed locking in IRQ handler, since all other code uses spin_lock_irqsave() and so guarantees it doesn't run concurrently with the handler. * Moved duplicated BUILD_BUG_ON()s into probe(). Also check size of bcm2835_gpio_pins[]. * Remove range-checking from bcm2835_pctl_get_groups_count() since we've decided to trust the pinctrl core. * Made bcm2835_pmx_gpio_disable_free() call bcm2835_pinctrl_fsel_set() directly for simplicity. * Fixed body of dt_free_map() to match latest dt_node_to_map(). * Removed GPIO ownership check from bcm2835_pmx_enable() since the pinctrl core owns doing this. * Made irq_chip and pinctrl_gpio_range .name == MODULE_NAME so it's more descriptive. * Simplified remove(); removed call to non-existent pinctrl_remove_gpio_range(), remove early return on error. * Don't force gpiochip's base to 0. Set gpio_range.base to gpiochip's base GPIO number. * Error-handling cleanups in probe(). * Switched to module_platform_driver() rather than open-coding. * Made pin, group, and function names lower-case. * s/broadcom/brcm/ in DT property names. * s/2708/2835/. * Fixed a couple minor checkpatch warnings, and other minor cleanup. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Signed-off-by: Chris Boot <bootc@bootc.net> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-09-28 04:10:11 +00:00
config PINCTRL_BCM2835
bool
select PINMUX
select PINCONF
pinctrl: pinctrl-imx: add imx pinctrl core driver The driver has mux and config support while the gpio is still not supported. For select input setting, the driver will handle it internally and do not need user to take care of it. The pinctrl-imx core driver will parse the dts file and dynamically create the pinmux functions and groups. Each IMX SoC pinctrl driver should register pins with a pin register map including mux register and config register and select input map to core for proper operations. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 12:26:16 +00:00
config PINCTRL_IMX
bool
select PINMUX
select PINCONF
pinctrl: pinctrl-imx: add imx35 pinctrl driver This is mostly cut'n'paste from the imx51 pinctrl driver. The data was generated using sed and awk on arch/arm/plat-mxc/include/mach/iomux-mx35.h. Changes since (implicit) v1 - remove references to file names in binding documentation - remove sed commands from comments in driver - add explicit numbers for pins and functions Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-08-09 16:23:32 +00:00
config PINCTRL_IMX35
bool "IMX35 pinctrl driver"
depends on OF
depends on SOC_IMX35
select PINCTRL_IMX
help
Say Y here to enable the imx35 pinctrl driver
pinctrl: pinctrl-imx: add imx51 pinctrl driver ChangeLog v1->v2: * change PIN_FUNC_ID base in binding doc to 0 from 1. Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-15 07:49:03 +00:00
config PINCTRL_IMX51
bool "IMX51 pinctrl driver"
depends on OF
depends on SOC_IMX51
select PINCTRL_IMX
help
Say Y here to enable the imx51 pinctrl driver
pinctrl: pinctrl-imx: add imx53 pinctrl driver ChangeLog v1->v2: * change PIN_FUNC_ID base in binding doc to 0 from 1. Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-15 07:49:02 +00:00
config PINCTRL_IMX53
bool "IMX53 pinctrl driver"
depends on OF
depends on SOC_IMX53
select PINCTRL_IMX
help
Say Y here to enable the imx53 pinctrl driver
pinctrl: pinctrl-imx: add imx6q pinctrl driver Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 12:26:17 +00:00
config PINCTRL_IMX6Q
bool "IMX6Q pinctrl driver"
depends on OF
depends on SOC_IMX6Q
select PINCTRL_IMX
help
Say Y here to enable the imx6q pinctrl driver
OF: pinctrl: MIPS: lantiq: implement lantiq/xway pinctrl support Implement support for pinctrl on lantiq/xway socs. The IO core found on these socs has the registers for pinctrl, pinconf and gpio mixed up in the same register range. As the gpio_chip handling is only a few lines, the driver also implements the gpio functionality. This obseletes the old gpio driver that was located in the arch/ folder. Signed-off-by: John Crispin <blogic@openwrt.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org
2012-08-28 10:44:59 +00:00
config PINCTRL_LANTIQ
bool
depends on LANTIQ
select PINMUX
select PINCONF
pinctrl: enable pinmux for mmp series Support PXA168/PXA910/MMP2 pinmux. Now only support function switch. Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> [Rebase and fix some whitespace issues] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-04 02:26:33 +00:00
config PINCTRL_PXA3xx
bool
select PINMUX
OF: pinctrl: MIPS: lantiq: adds support for FALCON SoC Implement support for pinctrl on lantiq/falcon socs. The FALCON has 5 banks of up to 32 pins. Signed-off-by: John Crispin <blogic@openwrt.org> Signed-off-by: Thomas Langer <thomas.langer@lantiq.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org
2012-05-19 22:33:56 +00:00
config PINCTRL_FALCON
bool
depends on SOC_FALCON
depends on PINCTRL_LANTIQ
pinctrl: enable pinmux for mmp series Support PXA168/PXA910/MMP2 pinmux. Now only support function switch. Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> [Rebase and fix some whitespace issues] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-04 02:26:33 +00:00
config PINCTRL_MMP2
bool "MMP2 pin controller driver"
depends on ARCH_MMP
select PINCTRL_PXA3xx
select PINCONF
pinctrl: add pinctrl-mxs support Add pinctrl support for Freescale MXS SoCs, i.MX23 and i.MX28. The driver supports device tree probe only. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-28 05:00:50 +00:00
config PINCTRL_MXS
bool
config PINCTRL_IMX23
bool
select PINMUX
select PINCONF
select PINCTRL_MXS
config PINCTRL_IMX28
bool
select PINMUX
select PINCONF
select PINCTRL_MXS
pinctrl/nomadik: basic Nomadik pinctrl interface This adds a scratch pin control interface to the Nomadik pinctrl driver, and defines the pins and groups in the DB8500 ASIC. We define GPIO ranges to cover the pins exposed. The DB8500 has more pins than this but we restrict the driver to the pins that can be controlled from the combined GPIO and pin control hardware to begin with. ChangeLog v1->v2: - Base on the latest pinctrl development from pinctrl-mergebase-20120418 so we can get rid of legacy group count mechanism. Also drop the range checks for group index, this is handled by the core now. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-26 21:57:25 +00:00
config PINCTRL_NOMADIK
bool "Nomadik pin controller driver"
ARM: nomadik: enable PINCTRL_NOMADIK where needed The nomadik gpio code has been converted to pinctrl, but the nomadik platform still expects the old code to be present. Change it to use the new one instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-15 11:24:34 +00:00
depends on ARCH_U8500 || ARCH_NOMADIK
pinctrl/nomadik: implement pin multiplexing Implements basic pinmux for the Nomadik pin controller. The plan is to split the existing singular pin config interface nmk_config_pin(), nmk_config_pins(), that will configure muxing and other settings at the same time, into two interfaces by splitting the code in pinmux and pinctrl and eventually deleting the old interface and its helper functions when all users are gone. nmk_gpio_set_mode() and nmk_gpio_get_mode() are two older interfaces for just configuring muxing/altfunctions that will also be replaced in the end. We take some extra care to handle the glitch-avoidance here, but it is simpler now since there is only one altsetting per pingroup so we know immediately if we need to avoid altfunc C glitches for a certain group. As part of the makeover implement the .request() and .free() calls on the GPIO chips and have them call back into the pinctrl layer to reserve GPIOs. ChangeLog v1->v2: - Rebased on pinctrl-mergebase-20120418 so we get the latest driver infrastructure where function count is done by a fixed value and we can drop a few range checks since this is now handled by the core. - Include a GPIO muxing hunk erroneously part of the pin config patch. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-02 20:56:47 +00:00
select PINMUX
pinctrl/nomadik: implement pin configuration This implements the pin configuration interface for the Nomadik pin controller. As part of the exercise we add a bit in the pin_cfg_t for the Nomadik pinctrl driver that indicates if the pin should be forced into GPIO mode. This is not done to go behind the back of the GPIO subsystem, but to ensure that default modes can be set by hogs on boot and system suspend/resume states. It was used implicitly by the old code defining all config settings and modes in a single config word but we now have a split between pinmux and pinconf leading to the need to have this. We also add a bit for explicitly setting sleepmode of the pin. This was previously handled by custom calls with the _sleep() suffix, but we now have one single interface into the configuration so we replace this with a bit indicating that the pin shall be configured into sleep mode. Some of the configuration can be refactored later to use less custom fields on the pin_cfg_t but we are currently leaving the old function calls in place so we stay compatible. ChangeLog v1->v2: - Drop a hunk changing pinmuxing for GPIO and move it over to the preceding pinmux patch. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-03 13:58:12 +00:00
select PINCONF
pinctrl/nomadik: basic Nomadik pinctrl interface This adds a scratch pin control interface to the Nomadik pinctrl driver, and defines the pins and groups in the DB8500 ASIC. We define GPIO ranges to cover the pins exposed. The DB8500 has more pins than this but we restrict the driver to the pins that can be controlled from the combined GPIO and pin control hardware to begin with. ChangeLog v1->v2: - Base on the latest pinctrl development from pinctrl-mergebase-20120418 so we can get rid of legacy group count mechanism. Also drop the range checks for group index, this is handled by the core now. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-26 21:57:25 +00:00
pinctrl/nomadik: add STn8815 ASIC support This adds support for the STN8815 ASIC for the Nomadik pin controller. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-08-09 22:43:28 +00:00
config PINCTRL_STN8815
bool "STN8815 pin controller driver"
depends on PINCTRL_NOMADIK && ARCH_NOMADIK
pinctrl/nomadik: basic Nomadik pinctrl interface This adds a scratch pin control interface to the Nomadik pinctrl driver, and defines the pins and groups in the DB8500 ASIC. We define GPIO ranges to cover the pins exposed. The DB8500 has more pins than this but we restrict the driver to the pins that can be controlled from the combined GPIO and pin control hardware to begin with. ChangeLog v1->v2: - Base on the latest pinctrl development from pinctrl-mergebase-20120418 so we can get rid of legacy group count mechanism. Also drop the range checks for group index, this is handled by the core now. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-26 21:57:25 +00:00
config PINCTRL_DB8500
bool "DB8500 pin controller driver"
depends on PINCTRL_NOMADIK && ARCH_U8500
pinctrl/nomadik: add ASIC DB8450 pinctrl driver This implements a subdriver for the DB8540 ASIC for the Nomadik pin controller. Signed-off-by: Patrice Chotard <patrice.chotard@stericsson.com> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-07-20 13:45:22 +00:00
config PINCTRL_DB8540
bool "DB8540 pin controller driver"
depends on PINCTRL_NOMADIK && ARCH_U8500
pinctrl: enable pinmux for mmp series Support PXA168/PXA910/MMP2 pinmux. Now only support function switch. Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> [Rebase and fix some whitespace issues] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-04 02:26:33 +00:00
config PINCTRL_PXA168
bool "PXA168 pin controller driver"
depends on ARCH_MMP
select PINCTRL_PXA3xx
select PINCONF
config PINCTRL_PXA910
bool "PXA910 pin controller driver"
depends on ARCH_MMP
select PINCTRL_PXA3xx
select PINCONF
pinctrl: Add one-register-per-pin type device tree based pinctrl driver Add one-register-per-pin type device tree based pinctrl driver. This driver has been tested on omap2+ series of processors, where there is either an 8 or 16-bit padconf register for each pin. Support for other similar pinmux controllers can be added. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-07-10 09:05:46 +00:00
config PINCTRL_SINGLE
tristate "One-register-per-pin type device tree based pinctrl driver"
depends on OF
select PINMUX
select PINCONF
help
This selects the device tree based generic pinctrl driver.
pinctrl: rename U300 and SIRF pin controllers For stringent order, rename the pinmux-* pin controllers to pinctrl-* and also rename the Kconfig symbols and in-kernel users. Cc: Rongjun Ying <Rongjun.Ying@csr.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-18 22:44:26 +00:00
config PINCTRL_SIRF
bool "CSR SiRFprimaII pin controller driver"
pinctrl: add a driver for the CSR SiRFprimaII pinmux This creates a pin controller driver for the SiRFprinaII pin mux portions. Signed-off-by: Rongjun Ying <Rongjun.Ying@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> [Fixup for changed function names and semantics in the v10 patch] Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
2011-10-09 10:11:13 +00:00
depends on ARCH_PRIMA2
select PINMUX
pinctrl: add a driver for NVIDIA Tegra This adds a driver for the Tegra pinmux, and required parameterization data for Tegra20 and Tegra30. The driver is initially added with driver name and device tree compatible value that won't cause this driver to be used. A later change will switch the pinctrl driver to use the correct values, switch the old pinmux driver to be disabled, and update all code that uses the old pinmux APIs to use the new pinctrl APIs. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net> [squashed "fix case of Tegra30's foo_groups[] arrays"] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-01 21:04:47 +00:00
config PINCTRL_TEGRA
bool
config PINCTRL_TEGRA20
bool
select PINMUX
select PINCONF
select PINCTRL_TEGRA
config PINCTRL_TEGRA30
bool
select PINMUX
select PINCONF
select PINCTRL_TEGRA
pinctrl: rename U300 and SIRF pin controllers For stringent order, rename the pinmux-* pin controllers to pinctrl-* and also rename the Kconfig symbols and in-kernel users. Cc: Rongjun Ying <Rongjun.Ying@csr.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-18 22:44:26 +00:00
config PINCTRL_U300
bool "U300 pin controller driver"
pinctrl: add a driver for the U300 pinmux This adds a driver for the U300 pinmux portions of the system controller "SYSCON". It also serves as an example of how to use the pinmux subsystem. This driver also houses the platform data for the only supported platform. This deletes the old U300 driver in arch/arm/mach-u300 and replace it with a driver using the new subsystem. The new driver is considerably fatter than the old one, but it also registers all 467 pins of the system and adds the power and EMIF pin groups and corresponding functions. The idea is to use this driver as a a reference for other implementation so it needs to be as complete and verbose as possible. Reviewed-by: Barry Song <21cnbao@gmail.com> [Fixup for changed function names and semantics in the v10 patch] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:54:38 +00:00
depends on ARCH_U300
select PINMUX
pinctrl: support pinconfig on the U300 This adds pin configuration support for the U300 driver pair, we can now read out the biasing and drive mode in debugfs and configure it using the new configuration API. ChangeLog v1->v2: - Migrate to pin config and generic pin config changes. ChangeLog v2->v3: - Adjust to generic pin config changes in v7 patch set. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-16 20:58:10 +00:00
select GENERIC_PINCONF
pinctrl: hide subsystem from the populace Machines that have embedded pin controllers need to select them explicitly, so why broadcast their config options to menuconfig. We provide a helpful submenu for those machines that do select it, making it possible to enable debugging for example. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-05 20:28:46 +00:00
pinctrl: move the U300 GPIO driver to pinctrl This driver will be converted to a dual GPIO + pinctrl driver since it supports biasing and driving control options. Hopefully it can serve as an example. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-16 08:22:59 +00:00
config PINCTRL_COH901
bool "ST-Ericsson U300 COH 901 335/571 GPIO"
pinctrl: select the proper symbol The Kconfig entry for the COH901 pin controller depended on PINMUX_U300 which is stale, use PINCTRL_U300 as it is called these days. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-06-18 18:07:50 +00:00
depends on GPIOLIB && ARCH_U300 && PINCTRL_U300
pinctrl: move the U300 GPIO driver to pinctrl This driver will be converted to a dual GPIO + pinctrl driver since it supports biasing and driving control options. Hopefully it can serve as an example. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-16 08:22:59 +00:00
help
Say yes here to support GPIO interface on ST-Ericsson U300.
The names of the two IP block variants supported are
COH 901 335 and COH 901 571/3. They contain 3, 5 or 7
ports of 8 GPIO pins each.
pinctrl: add samsung pinctrl and gpiolib driver Add a new device tree enabled pinctrl and gpiolib driver for Samsung SoC's. This driver provides a common and extensible framework for all Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This driver supports only device tree based instantiation and hence can be used only on those Samsung platforms that have device tree enabled. This driver is split into two parts: the pinctrl interface and the gpiolib interface. The pinctrl interface registers pinctrl devices with the pinctrl subsystem and gpiolib interface registers gpio chips with the gpiolib subsystem. The information about the pins, pin groups, pin functions and gpio chips, which are SoC specific, are parsed from device tree node. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-06 21:07:19 +00:00
config PINCTRL_SAMSUNG
bool "Samsung pinctrl driver"
pinctrl: samsung and exynos need to depend on OF && GPIOLIB This patch fixes below build error when !CONFIG_OF_GPIO. CC drivers/pinctrl/pinctrl-samsung.o drivers/pinctrl/pinctrl-samsung.c: In function 'samsung_pinctrl_parse_dt_pins': drivers/pinctrl/pinctrl-samsung.c:557:19: warning: unused variable 'prop' [-Wunused-variable] drivers/pinctrl/pinctrl-samsung.c: In function 'samsung_gpiolib_register': drivers/pinctrl/pinctrl-samsung.c:797:5: error: 'struct gpio_chip' has no member named 'of_node' make[2]: *** [drivers/pinctrl/pinctrl-samsung.o] Error 1 make[1]: *** [drivers/pinctrl] Error 2 make: *** [drivers] Error 2 The samsung pinctrl driver supports only device tree enabled platforms. Thus make PINCTRL_SAMSUNG depend on OF && GPIOLIB. The reason to depend on GPIOLIB is CONFIG_OF_GPIO only available when GPIOLIB is selected. Since PINCTRL_EXYNOS4 select PINCTRL_SAMSUNG, thus also make PINCTRL_EXYNOS4 depend on OF && GPIOLIB. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-06 07:04:30 +00:00
depends on OF && GPIOLIB
pinctrl: add samsung pinctrl and gpiolib driver Add a new device tree enabled pinctrl and gpiolib driver for Samsung SoC's. This driver provides a common and extensible framework for all Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This driver supports only device tree based instantiation and hence can be used only on those Samsung platforms that have device tree enabled. This driver is split into two parts: the pinctrl interface and the gpiolib interface. The pinctrl interface registers pinctrl devices with the pinctrl subsystem and gpiolib interface registers gpio chips with the gpiolib subsystem. The information about the pins, pin groups, pin functions and gpio chips, which are SoC specific, are parsed from device tree node. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-06 21:07:19 +00:00
select PINMUX
select PINCONF
pinctrl: add exynos4210 specific extensions for samsung pinctrl driver Add information about the Exynos4210 pin banks and driver data which is used by the Samsung pinctrl driver. In addition to this, the support for external gpio and wakeup interrupt support is included and hooked up with the Samsung pinctrl driver. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-06 21:07:19 +00:00
config PINCTRL_EXYNOS4
bool "Pinctrl driver data for Exynos4 SoC"
pinctrl: samsung and exynos need to depend on OF && GPIOLIB This patch fixes below build error when !CONFIG_OF_GPIO. CC drivers/pinctrl/pinctrl-samsung.o drivers/pinctrl/pinctrl-samsung.c: In function 'samsung_pinctrl_parse_dt_pins': drivers/pinctrl/pinctrl-samsung.c:557:19: warning: unused variable 'prop' [-Wunused-variable] drivers/pinctrl/pinctrl-samsung.c: In function 'samsung_gpiolib_register': drivers/pinctrl/pinctrl-samsung.c:797:5: error: 'struct gpio_chip' has no member named 'of_node' make[2]: *** [drivers/pinctrl/pinctrl-samsung.o] Error 1 make[1]: *** [drivers/pinctrl] Error 2 make: *** [drivers] Error 2 The samsung pinctrl driver supports only device tree enabled platforms. Thus make PINCTRL_SAMSUNG depend on OF && GPIOLIB. The reason to depend on GPIOLIB is CONFIG_OF_GPIO only available when GPIOLIB is selected. Since PINCTRL_EXYNOS4 select PINCTRL_SAMSUNG, thus also make PINCTRL_EXYNOS4 depend on OF && GPIOLIB. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-06 07:04:30 +00:00
depends on OF && GPIOLIB
pinctrl: add exynos4210 specific extensions for samsung pinctrl driver Add information about the Exynos4210 pin banks and driver data which is used by the Samsung pinctrl driver. In addition to this, the support for external gpio and wakeup interrupt support is included and hooked up with the Samsung pinctrl driver. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-06 21:07:19 +00:00
select PINCTRL_SAMSUNG
pinctrl: mvebu: move to its own directory Like the spear platform, the mvebu platform has multiple files: one core file, and then one file per SoC family. More files will be added later, as support for mach-orion5x and mach-mv78xx0 SoCs is added to pinctrl-mvebu. For those reasons, having a separate subdirectory, drivers/pinctrl/mvebu/ makes sense, and it had already been suggested by Linus Wallej when the driver was originally submitted. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-10-24 21:38:58 +00:00
source "drivers/pinctrl/mvebu/Kconfig"
pinctrl: mvebu: allow plat-orion architectures to use pinctrl-mvebu The mach-kirkwood and mach-dove architectures have not yet been integrated into the mach-mvebu directory, which should ultimately contain the support for all Marvell SoCs from the Engineering Business Unit. However, before this can happen, we need to let mach-kirkwood and mach-dove use the pinctrl-mvebu driver, which supports the kirkwood and dove SoC families. In order to do that, we make this driver available as soon as PLAT_ORION is selected, instead of using ARCH_MVEBU as a condition. In the long term, PLAT_ORION should disappear and be fully replaced by ARCH_MVEBU, but the plan is to make the migration step by step, by first having the existing mach-* directories for Marvell SoCs converge on several infrastructures, including the pinctrl one. Also, like the spear pinctrl driver, we put all pinctrl-mvebu Kconfig options under a if, in order to avoid having certain options (PINCTRL_DOVE, PINCTRL_KIRKWOOD, etc.) selecting an option (PINCTLR_MVEBU) which itself has a dependency (on ARCH_MVEBU). In this a construct, the dependency is in fact ignored due to the selects. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-10-24 21:38:56 +00:00
pinctrl: Add SPEAr pinctrl drivers This adds pinctrl driver for SPEAr platform. It also updates MAINTAINERS file for SPEAr pinctrl drivers. Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
2012-03-28 16:57:07 +00:00
source "drivers/pinctrl/spear/Kconfig"
OF: pinctrl: MIPS: lantiq: implement lantiq/xway pinctrl support Implement support for pinctrl on lantiq/xway socs. The IO core found on these socs has the registers for pinctrl, pinconf and gpio mixed up in the same register range. As the gpio_chip handling is only a few lines, the driver also implements the gpio functionality. This obseletes the old gpio driver that was located in the arch/ folder. Signed-off-by: John Crispin <blogic@openwrt.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org
2012-08-28 10:44:59 +00:00
config PINCTRL_XWAY
bool
depends on SOC_TYPE_XWAY
depends on PINCTRL_LANTIQ
pinctrl: hide subsystem from the populace Machines that have embedded pin controllers need to select them explicitly, so why broadcast their config options to menuconfig. We provide a helpful submenu for those machines that do select it, making it possible to enable debugging for example. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-05 20:28:46 +00:00
endmenu
pinctrl: add a driver for the U300 pinmux This adds a driver for the U300 pinmux portions of the system controller "SYSCON". It also serves as an example of how to use the pinmux subsystem. This driver also houses the platform data for the only supported platform. This deletes the old U300 driver in arch/arm/mach-u300 and replace it with a driver using the new subsystem. The new driver is considerably fatter than the old one, but it also registers all 467 pins of the system and adds the power and EMIF pin groups and corresponding functions. The idea is to use this driver as a a reference for other implementation so it needs to be as complete and verbose as possible. Reviewed-by: Barry Song <21cnbao@gmail.com> [Fixup for changed function names and semantics in the v10 patch] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:54:38 +00: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 18:50:54 +00:00
endif
Reference in New Issue Copy Permalink