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
ddac96118f
linux/drivers/pinctrl/Kconfig

221 lines
4.6 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: hide CONFIG_PINMUX and CONFIG_PINCONF These symbols are supposed to be selected by the drivers actually needing them. The only situation where it would make sense to enable them without a driver selecting them is when an out-of-tree pinctrl driver is used or for compile testing. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-06-03 08:02:36 +00:00
bool "Support pin multiplexing controllers" if COMPILE_TEST
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
config PINCONF
pinctrl: hide CONFIG_PINMUX and CONFIG_PINCONF These symbols are supposed to be selected by the drivers actually needing them. The only situation where it would make sense to enable them without a driver selecting them is when an out-of-tree pinctrl driver is used or for compile testing. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-06-03 08:02:36 +00:00
bool "Support pin configuration controllers" if COMPILE_TEST
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: ADI PIN control driver for the GPIO controller on bf54x and bf60x. The new ADI GPIO2 controller was introduced since the BF548 and BF60x processors. It differs a lot from the old one on BF5xx processors. So, create a pinctrl driver under the pinctrl framework. - Define gpio ports and pin interrupt controllers as individual platform devices. - Register a pinctrl driver for the whole GPIO ports and pin interrupt devices. - Probe pint devices before port devices. Put device instances into the global gpio and pint lists. - Define peripheral, irq and gpio reservation bit masks for each gpio port as runtime resources. - Save and restore gpio port and pint status MMRs in syscore PM functions. - Create the plug-in subdrivers to hold the pinctrl soc data for bf54x and bf60x. Add soc data into struct adi_pinctrl. Initialize the soc data in pin controller probe function. Get the pin groups and functions via the soc data reference. - Call gpiochip_add_pin_range() in gpio device probe function to register range cross reference between gpio device and pin control device. - Get range by pinctrl_find_gpio_range_from_pin(), find gpio_port object by container_of() and find adi_pinctrl by pin control device name. - Handle peripheral and gpio requests in pinctrl operation functions. - Demux gpio IRQs via the irq_domain created by each GPIO port. v2-changes: - Remove unlinke() directive. v3-changes: - Rename struct adi_pmx to adi_pinctrl. - Fix the comments of struct gpio_pint. - Remove unused pin_base in struct gpio_port. - Change pint_assign into bool type. - Add comments about the relationship between pint device and port device to the driver header. - Use BIT macro to shift bit. - Remove all bitmap reservation help functions. Inline reservation functions into the actual code. - Remove gpio and offset mutual reference help functions. - Remove all help functions to find gpio_port and adi_pinctrl structs. Get range by pinctrl_find_gpio_range_from_pin(), find gpio_port object by container_of() and find adi_pinctrl by pin control device name. - Pass bool type usage variable to port_setup help function. - Separate long bit operations into several lines and add comments. - Use debugfs to output all GPIO request information. - Avoid to set drvdata to NULL - Add explanation to function adi_gpio_init_int() - Call gpiochip_add_pin_range() in gpio device probe function to register range cross reference between gpio device and pin control device. - Remove the reference to pin control device from the gpio_port struct. Remove the reference list to gpio device from the adi_pinctrl struct. Replace the global adi_pinctrl list with adi_gpio_port_list. Walk through the gpio list to do power suspend and resume operations. - Remove the global GPIO base from struct adi_pinctrl, define pin base in the platform data for each GPIO port device. - Initialize adi_pinctrl_setup in arch_initcall(). - print the status of triggers, whether it is in GPIO mode, if it is flagged to be used as IRQ, etc in adi_pin_dbg_show(). - Create the plug-in subdrivers to hold the pinctrl soc data for bf54x and bf60x. Add soc data into struct adi_pinctrl. Initialize the soc data in pin controller probe function. Get the pin groups and functions via the soc data reference. v4-changes: - remove useless system_state checking. - replace dev_err with dev_warn in both irq and gpio pin cases. - comment on relationship between irq type and invert operation. - It is not necessary to check the reservation mode of the requested pin in IRQ chip operation. Remove the reservation map. - Use existing gpio/pinctrl subsystem debugfs files. Remove pinctrl-adi2 driver specific debugfs output. - Add linkport group and function information for bf60x. - Separate uart and ctsrts pins into 2 groups. - Separate APAPI and alternative ATAPI pins into 2 groups. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-09-03 08:28:59 +00:00
config PINCTRL_ADI2
bool "ADI pin controller driver"
pinctrl: pinctrl-adi2: Add dependency to arch BLACKFIN in Kconfig. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-09-23 03:57:00 +00:00
depends on BLACKFIN
pinctrl: ADI PIN control driver for the GPIO controller on bf54x and bf60x. The new ADI GPIO2 controller was introduced since the BF548 and BF60x processors. It differs a lot from the old one on BF5xx processors. So, create a pinctrl driver under the pinctrl framework. - Define gpio ports and pin interrupt controllers as individual platform devices. - Register a pinctrl driver for the whole GPIO ports and pin interrupt devices. - Probe pint devices before port devices. Put device instances into the global gpio and pint lists. - Define peripheral, irq and gpio reservation bit masks for each gpio port as runtime resources. - Save and restore gpio port and pint status MMRs in syscore PM functions. - Create the plug-in subdrivers to hold the pinctrl soc data for bf54x and bf60x. Add soc data into struct adi_pinctrl. Initialize the soc data in pin controller probe function. Get the pin groups and functions via the soc data reference. - Call gpiochip_add_pin_range() in gpio device probe function to register range cross reference between gpio device and pin control device. - Get range by pinctrl_find_gpio_range_from_pin(), find gpio_port object by container_of() and find adi_pinctrl by pin control device name. - Handle peripheral and gpio requests in pinctrl operation functions. - Demux gpio IRQs via the irq_domain created by each GPIO port. v2-changes: - Remove unlinke() directive. v3-changes: - Rename struct adi_pmx to adi_pinctrl. - Fix the comments of struct gpio_pint. - Remove unused pin_base in struct gpio_port. - Change pint_assign into bool type. - Add comments about the relationship between pint device and port device to the driver header. - Use BIT macro to shift bit. - Remove all bitmap reservation help functions. Inline reservation functions into the actual code. - Remove gpio and offset mutual reference help functions. - Remove all help functions to find gpio_port and adi_pinctrl structs. Get range by pinctrl_find_gpio_range_from_pin(), find gpio_port object by container_of() and find adi_pinctrl by pin control device name. - Pass bool type usage variable to port_setup help function. - Separate long bit operations into several lines and add comments. - Use debugfs to output all GPIO request information. - Avoid to set drvdata to NULL - Add explanation to function adi_gpio_init_int() - Call gpiochip_add_pin_range() in gpio device probe function to register range cross reference between gpio device and pin control device. - Remove the reference to pin control device from the gpio_port struct. Remove the reference list to gpio device from the adi_pinctrl struct. Replace the global adi_pinctrl list with adi_gpio_port_list. Walk through the gpio list to do power suspend and resume operations. - Remove the global GPIO base from struct adi_pinctrl, define pin base in the platform data for each GPIO port device. - Initialize adi_pinctrl_setup in arch_initcall(). - print the status of triggers, whether it is in GPIO mode, if it is flagged to be used as IRQ, etc in adi_pin_dbg_show(). - Create the plug-in subdrivers to hold the pinctrl soc data for bf54x and bf60x. Add soc data into struct adi_pinctrl. Initialize the soc data in pin controller probe function. Get the pin groups and functions via the soc data reference. v4-changes: - remove useless system_state checking. - replace dev_err with dev_warn in both irq and gpio pin cases. - comment on relationship between irq type and invert operation. - It is not necessary to check the reservation mode of the requested pin in IRQ chip operation. Remove the reservation map. - Use existing gpio/pinctrl subsystem debugfs files. Remove pinctrl-adi2 driver specific debugfs output. - Add linkport group and function information for bf60x. - Separate uart and ctsrts pins into 2 groups. - Separate APAPI and alternative ATAPI pins into 2 groups. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-09-03 08:28:59 +00:00
select PINMUX
select IRQ_DOMAIN
help
This is the pin controller and gpio driver for ADI BF54x, BF60x and
future processors. This option is selected automatically when specific
machine and arch are selected to build.
pincntrl: add support for ams AS3722 pin control driver The AS3722 is a compact system PMU suitable for mobile phones, tablets etc. Add a driver to support accessing the GPIO, pinmux and pin configuration of 8 GPIO pins found on the ams AS3722 through pin control driver and gpiolib. The driver will register itself as the pincontrol driver and gpio driver. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-10-02 15:50:29 +00:00
config PINCTRL_AS3722
bool "Pinctrl and GPIO driver for ams AS3722 PMIC"
depends on MFD_AS3722 && GPIOLIB
select PINMUX
select GENERIC_PINCONF
help
AS3722 device supports the configuration of GPIO pins for different
functionality. This driver supports the pinmux, push-pull and
open drain configuration for the GPIO pins of AS3722 devices. It also
supports the GPIO functionality through gpiolib.
pinctrl: ADI PIN control driver for the GPIO controller on bf54x and bf60x. The new ADI GPIO2 controller was introduced since the BF548 and BF60x processors. It differs a lot from the old one on BF5xx processors. So, create a pinctrl driver under the pinctrl framework. - Define gpio ports and pin interrupt controllers as individual platform devices. - Register a pinctrl driver for the whole GPIO ports and pin interrupt devices. - Probe pint devices before port devices. Put device instances into the global gpio and pint lists. - Define peripheral, irq and gpio reservation bit masks for each gpio port as runtime resources. - Save and restore gpio port and pint status MMRs in syscore PM functions. - Create the plug-in subdrivers to hold the pinctrl soc data for bf54x and bf60x. Add soc data into struct adi_pinctrl. Initialize the soc data in pin controller probe function. Get the pin groups and functions via the soc data reference. - Call gpiochip_add_pin_range() in gpio device probe function to register range cross reference between gpio device and pin control device. - Get range by pinctrl_find_gpio_range_from_pin(), find gpio_port object by container_of() and find adi_pinctrl by pin control device name. - Handle peripheral and gpio requests in pinctrl operation functions. - Demux gpio IRQs via the irq_domain created by each GPIO port. v2-changes: - Remove unlinke() directive. v3-changes: - Rename struct adi_pmx to adi_pinctrl. - Fix the comments of struct gpio_pint. - Remove unused pin_base in struct gpio_port. - Change pint_assign into bool type. - Add comments about the relationship between pint device and port device to the driver header. - Use BIT macro to shift bit. - Remove all bitmap reservation help functions. Inline reservation functions into the actual code. - Remove gpio and offset mutual reference help functions. - Remove all help functions to find gpio_port and adi_pinctrl structs. Get range by pinctrl_find_gpio_range_from_pin(), find gpio_port object by container_of() and find adi_pinctrl by pin control device name. - Pass bool type usage variable to port_setup help function. - Separate long bit operations into several lines and add comments. - Use debugfs to output all GPIO request information. - Avoid to set drvdata to NULL - Add explanation to function adi_gpio_init_int() - Call gpiochip_add_pin_range() in gpio device probe function to register range cross reference between gpio device and pin control device. - Remove the reference to pin control device from the gpio_port struct. Remove the reference list to gpio device from the adi_pinctrl struct. Replace the global adi_pinctrl list with adi_gpio_port_list. Walk through the gpio list to do power suspend and resume operations. - Remove the global GPIO base from struct adi_pinctrl, define pin base in the platform data for each GPIO port device. - Initialize adi_pinctrl_setup in arch_initcall(). - print the status of triggers, whether it is in GPIO mode, if it is flagged to be used as IRQ, etc in adi_pin_dbg_show(). - Create the plug-in subdrivers to hold the pinctrl soc data for bf54x and bf60x. Add soc data into struct adi_pinctrl. Initialize the soc data in pin controller probe function. Get the pin groups and functions via the soc data reference. v4-changes: - remove useless system_state checking. - replace dev_err with dev_warn in both irq and gpio pin cases. - comment on relationship between irq type and invert operation. - It is not necessary to check the reservation mode of the requested pin in IRQ chip operation. Remove the reservation map. - Use existing gpio/pinctrl subsystem debugfs files. Remove pinctrl-adi2 driver specific debugfs output. - Add linkport group and function information for bf60x. - Separate uart and ctsrts pins into 2 groups. - Separate APAPI and alternative ATAPI pins into 2 groups. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-09-03 08:28:59 +00:00
config PINCTRL_BF54x
def_bool y if BF54x
select PINCTRL_ADI2
config PINCTRL_BF60x
def_bool y if BF60x
select PINCTRL_ADI2
ARM: at91: add pinctrl support This is also include the gpio controller as the IP share both. Each soc will have to describe the SoC limitation and pin configuration via DT. This will allow to do not need to touch the C code when adding new SoC if the IP version is supported. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
2012-07-12 15:35:02 +00:00
config PINCTRL_AT91
bool "AT91 pinctrl driver"
depends on OF
depends on ARCH_AT91
select PINMUX
select PINCONF
pinctrl/at91: convert driver to use gpiolib irqchip This converts the AT91 pin control driver to register its chained irq handler and irqchip using the helpers in the gpiolib core. Signed-off-by: Alexander Stein <alexanders83@web.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-04-15 20:09:41 +00:00
select GPIOLIB
select OF_GPIO
select GPIOLIB_IRQCHIP
ARM: at91: add pinctrl support This is also include the gpio controller as the IP share both. Each soc will have to describe the SoC limitation and pin configuration via DT. This will allow to do not need to touch the C code when adding new SoC if the IP version is supported. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
2012-07-12 15:35:02 +00:00
help
Say Y here to enable the at91 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
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: add driver for Amlogic Meson SoCs This is a driver for the pinmux and GPIO controller available in Amlogic Meson SoCs. It currently supports only Meson8, however the common code should be generic enough to work also for other SoCs after having defined the proper set of functions and groups. GPIO interrupts are not supported at the moment due to lack of documentation. Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-17 18:15:14 +00:00
config PINCTRL_MESON
bool
select PINMUX
select PINCONF
select GENERIC_PINCONF
select OF_GPIO
select REGMAP_MMIO
pinctrl: add pinctrl driver for Rockchip SoCs This driver adds support the Cortex-A9 based SoCs from Rockchip, so at least the RK2928, RK3066 (a and b) and RK3188. Earlier Rockchip SoCs seem to use similar mechanics for gpio handling so should be supportable with relative small changes. Pull handling on the rk3188 is currently a stub, due to it being a bit different to the earlier SoCs. Pinmuxing as well as gpio (and interrupt-) handling tested on a rk3066a based machine. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-06-10 20:16:22 +00:00
config PINCTRL_ROCKCHIP
bool
select PINMUX
select GENERIC_PINCONF
select GENERIC_IRQ_CHIP
pinctrl: rockchip: use regmaps instead of raw mappings This allows us to use syscons in the future. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Max Schwarz <max.schwarz@online.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-05-05 11:58:20 +00:00
select MFD_SYSCON
pinctrl: add pinctrl driver for Rockchip SoCs This driver adds support the Cortex-A9 based SoCs from Rockchip, so at least the RK2928, RK3066 (a and b) and RK3188. Earlier Rockchip SoCs seem to use similar mechanics for gpio handling so should be supportable with relative small changes. Pull handling on the rk3188 is currently a stub, due to it being a bit different to the earlier SoCs. Pinmuxing as well as gpio (and interrupt-) handling tested on a rk3066a based machine. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-06-10 20:16:22 +00:00
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
pinctrl: single: support generic pinconf Support the operation of generic pinconf. The supported config arguments are INPUT_SCHMITT, INPUT_SCHMITT_ENABLE, DRIVE_STRENGHT, BIAS_DISABLE, BIAS_PULLUP, BIAS_PULLDOWN, SLEW_RATE. Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-02-17 11:42:55 +00:00
select GENERIC_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
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
pinctrl: sirf: drop marco support marco chip has been dropped, clear its support. Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-11 13:56:41 +00:00
bool "CSR SiRFprimaII pin controller driver"
pinctrl: sirf: enable the driver support new SiRFmarco SoC The driver supports old up SiRFprimaII SoCs, this patch makes it support the new SiRFmarco as well. SiRFmarco, as a SMP SoC, adds new SIRFSOC_GPIO_PAD_EN_CLR registers, to disable GPIO pad, we should write 1 to the corresponding bit in the new CLEAR register instead of writing 0 to SIRFSOC_GPIO_PAD_EN. Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-09-27 09:56:30 +00:00
depends on ARCH_SIRF
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
select PINMUX
pinctrl: sirf: switch driver to use gpiolib irqchip helpers This switches the SiRF pinctrl driver over to using the gpiolib irqchip helpers simplifying some of the code. Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-04-15 06:43:47 +00:00
select GPIOLIB_IRQCHIP
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
pinctrl: st: Add pinctrl and pinconf support. This patch add pinctrl support to ST SoCs. About hardware: ST Set-Top-Box parts have two blocks called PIO and PIO-mux which handle pin configurations. Each multi-function pin is controlled, driven and routed through the PIO multiplexing block. Each pin supports GPIO functionality (ALT0) and multiple alternate functions(ALT1 - ALTx) that directly connect the pin to different hardware blocks. When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and Pull Up (PU) are driven by the related PIO block. Otherwise the PIO multiplexing block configures these parameters and retiming the signal. About driver: This pinctrl driver manages both PIO and PIO-mux block using pinctrl, pinconf, pinmux, gpio subsystems. All the pinctrl related config information can only come from device trees. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-06-20 14:05:38 +00:00
config PINCTRL_ST
bool
depends on OF
select PINMUX
select PINCONF
pinctrl: st: use gpiolib irqchip helpers This lets the gpiolib core handle the irqchip set-up and chained IRQ on the primary (behind the mux) IRQ chip in the st pinctrl driver. Default irq type is set to level low at irqchip add time. The v1 was sent by Linus (https://lkml.org/lkml/2014/4/4/287). Two changes were necessary to make it to work properly on STiH416: 1 - dev reference was not passed to the gpio_chip struct, causing a panic. 2 - gpiochip_irqchip_add passed IRQ_TYPE_NONE as default type, which caused lot of warnings at init time. I choose IRQ_TYPE_LEVEL_LOW as default. Cc: Srinivas Kandagatla <srinivas.kandagatla@gmail.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Maxime COQUELIN <maxime.coquelin@st.com>
2014-04-08 12:45:47 +00:00
select GPIOLIB_IRQCHIP
pinctrl: st: Add pinctrl and pinconf support. This patch add pinctrl support to ST SoCs. About hardware: ST Set-Top-Box parts have two blocks called PIO and PIO-mux which handle pin configurations. Each multi-function pin is controlled, driven and routed through the PIO multiplexing block. Each pin supports GPIO functionality (ALT0) and multiple alternate functions(ALT1 - ALTx) that directly connect the pin to different hardware blocks. When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and Pull Up (PU) are driven by the related PIO block. Otherwise the PIO multiplexing block configures these parameters and retiming the signal. About driver: This pinctrl driver manages both PIO and PIO-mux block using pinctrl, pinconf, pinmux, gpio subsystems. All the pinctrl related config information can only come from device trees. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-06-20 14:05:38 +00:00
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
pinctrl: tegra: Make PINCTRL_TEGRA select PINMUX && PINCONF Then we can remove "select PINMUX && PINCONF" from PINCTRL_TEGRA{20,30}. This simplifies the dependency. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-12 02:00:22 +00:00
select PINMUX
select PINCONF
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_TEGRA20
bool
select PINCTRL_TEGRA
config PINCTRL_TEGRA30
bool
select PINCTRL_TEGRA
pinctrl: tegra114: add pinctrl driver for NVIDIA's Tegra114 SoC This adds a driver for the Tegra114 pinmux, and required parameterization data for Tegra114. The driver uses the common Tegra pincontrol driver utility functions to implement the majority of the driver. This driver is not compatible with the earlier NVIDIA's SoCs, hence add new compatibile as "nvidia,tegra114-pinmux". Originally written by Pritesh. ldewangan: - cleanup the patches, - remove non-require tables. - Use module_platform_driver() for driver registartion. Signed-off-by: Pritesh Raithatha <praithatha@nvidia.com> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-08 07:32:37 +00:00
config PINCTRL_TEGRA114
bool
select PINCTRL_TEGRA
pinctrl: tegra: add pinmux controller driver for Tegra124 This adds a driver for the Tegra124 pinmux, and required parameterization data for Tegra124. The driver uses the common Tegra pincontrol driver utility functions to implement the majority of the driver. This driver is not compatible with the earlier NVIDIA's SoCs, hence add new compatibile as "nvidia,tegra124-pinmux". Originally written by Ashwini Gguhe. Thierry: - Cleanups in patches. ldewangan: - Fix some entries for groups. - Fix MUX enums and group sequence. Signed-off-by: Ashwini Ghuge <aghuge@nvidia.com> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> CC: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-12-10 07:10:56 +00:00
config PINCTRL_TEGRA124
bool
select PINCTRL_TEGRA
pinctrl: tegra: add a driver for Tegra210 Tegra210's pinmux supports a different set of pins/options than earlier SoCs, so requires its own driver (well, table of pin-specific data). Cc: devicetree@vger.kernel.org Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-02-24 21:00:51 +00:00
config PINCTRL_TEGRA210
bool
select PINCTRL_TEGRA
pinctrl: Add NVIDIA Tegra XUSB pad controller support The XUSB pad controller found on NVIDIA Tegra SoCs provides several pads that lanes can be assigned to in order to support a variety of interface options: USB 2.0, USB 3.0, PCIe and SATA. In addition to the pin controller used to assign lanes to pads two PHYs are exposed to allow the bricks for PCIe and SATA to be powered up and down by PCIe and SATA drivers. Tested-by: Mikko Perttunen <mperttunen@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-06-19 11:37:08 +00:00
config PINCTRL_TEGRA_XUSB
def_bool y if ARCH_TEGRA
select GENERIC_PHY
select PINCONF
select PINMUX
pinctrl-tz1090: add TZ1090 pinctrl driver Add a pin control driver for the main pins on the TZ1090 SoC. This doesn't include the low-power pins as they're controlled separately via the Powerdown Controller (PDC) registers. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Rob Landley <rob@landley.net> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-doc@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-06-20 09:26:27 +00:00
config PINCTRL_TZ1090
bool "Toumaz Xenif TZ1090 pin control driver"
depends on SOC_TZ1090
select PINMUX
select GENERIC_PINCONF
pinctrl-tz1090-pdc: add TZ1090 PDC pinctrl driver Add a pin control driver for the TZ1090's low power pins via the powerdown controller SOC_GPIO_CONTROL registers. These pins have individually controlled pull-up, and group controlled schmitt, slew-rate, drive-strength, and power-on-start (pos). The pdc_gpio0 and pdc_gpio1 pins can also be muxed onto the ir_mod_stable_out and ir_mod_power_out functions respectively. If no function is set they remain in GPIO mode. These muxes can be overridden by requesting them as GPIOs. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Rob Landley <rob@landley.net> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-doc@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-06-20 09:26:29 +00:00
config PINCTRL_TZ1090_PDC
bool "Toumaz Xenif TZ1090 PDC pin control driver"
depends on SOC_TZ1090
select PINMUX
select PINCONF
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: coh901: convert driver to use gpiolib irqchip This converts the COH901 pin control driver to register its chained irq handler and irqchip using the helpers in the gpiolib core. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-25 12:37:17 +00:00
select GPIOLIB_IRQCHIP
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: palmas: add pincontrol driver TI Palmas series Power Management IC have multiple pins which can be configured for different functionality. This pins can be configured for different function. Also their properties like pull up/down, open drain enable/disable are configurable. Add support for pincontrol driver Palmas series device like TPS65913, TPS80036. The driver supports to be register from DT only. Changes from V1: - Add generic property for pins and functions in pinconf-generic. - Add APIs to map the DT and subnode. - Move common utils APIs to the pinctrl-utils from this file. - Update the binding document accordingly. Changes from V2: - Add ack by Lee. - Correct the binding docs. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-06 13:12:35 +00:00
config PINCTRL_PALMAS
pinctrl: palmas: Fix device name in Kconfig text The device family is called Palmas so there should be a 's' on the end of the name. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-19 15:07:26 +00:00
bool "Pinctrl driver for the PALMAS Series MFD devices"
pinctrl: palmas: add pincontrol driver TI Palmas series Power Management IC have multiple pins which can be configured for different functionality. This pins can be configured for different function. Also their properties like pull up/down, open drain enable/disable are configurable. Add support for pincontrol driver Palmas series device like TPS65913, TPS80036. The driver supports to be register from DT only. Changes from V1: - Add generic property for pins and functions in pinconf-generic. - Add APIs to map the DT and subnode. - Move common utils APIs to the pinctrl-utils from this file. - Update the binding document accordingly. Changes from V2: - Add ack by Lee. - Correct the binding docs. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-06 13:12:35 +00:00
depends on OF && MFD_PALMAS
pinctrl: palmas: PINCTRL_PALMAS needs to select PINMUX Fix below build error if !PINMUX. CC drivers/pinctrl/pinctrl-palmas.o drivers/pinctrl/pinctrl-palmas.c:741:21: error: variable 'palmas_pinmux_ops' has initializer but incomplete type drivers/pinctrl/pinctrl-palmas.c:742:2: error: unknown field 'get_functions_count' specified in initializer drivers/pinctrl/pinctrl-palmas.c:742:2: warning: excess elements in struct initializer [enabled by default] drivers/pinctrl/pinctrl-palmas.c:742:2: warning: (near initialization for 'palmas_pinmux_ops') [enabled by default] drivers/pinctrl/pinctrl-palmas.c:743:2: error: unknown field 'get_function_name' specified in initializer drivers/pinctrl/pinctrl-palmas.c:743:2: warning: excess elements in struct initializer [enabled by default] drivers/pinctrl/pinctrl-palmas.c:743:2: warning: (near initialization for 'palmas_pinmux_ops') [enabled by default] drivers/pinctrl/pinctrl-palmas.c:744:2: error: unknown field 'get_function_groups' specified in initializer drivers/pinctrl/pinctrl-palmas.c:744:2: warning: excess elements in struct initializer [enabled by default] drivers/pinctrl/pinctrl-palmas.c:744:2: warning: (near initialization for 'palmas_pinmux_ops') [enabled by default] drivers/pinctrl/pinctrl-palmas.c:745:2: error: unknown field 'enable' specified in initializer drivers/pinctrl/pinctrl-palmas.c:745:2: warning: excess elements in struct initializer [enabled by default] drivers/pinctrl/pinctrl-palmas.c:745:2: warning: (near initialization for 'palmas_pinmux_ops') [enabled by default] make[2]: *** [drivers/pinctrl/pinctrl-palmas.o] Error 1 make[1]: *** [drivers/pinctrl] Error 2 make: *** [drivers] Error 2 Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-22 06:30:08 +00:00
select PINMUX
pinctrl: palmas: add pincontrol driver TI Palmas series Power Management IC have multiple pins which can be configured for different functionality. This pins can be configured for different function. Also their properties like pull up/down, open drain enable/disable are configurable. Add support for pincontrol driver Palmas series device like TPS65913, TPS80036. The driver supports to be register from DT only. Changes from V1: - Add generic property for pins and functions in pinconf-generic. - Add APIs to map the DT and subnode. - Move common utils APIs to the pinctrl-utils from this file. - Update the binding document accordingly. Changes from V2: - Add ack by Lee. - Correct the binding docs. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-06 13:12:35 +00:00
select GENERIC_PINCONF
help
Palmas device supports the configuration of pins for different
functionality. This driver supports the pinmux, push-pull and
open drain configuration for the Palmas series devices like
TPS65913, TPS80036 etc.
pinctrl: Add driver for Zynq This adds a pin-control driver for Zynq. Changes since v2: - driver-specific DT properties are passed to the core in two arrays, one for the actual DT parsing one for the debugfs representation. Issue a compiler warning when the number of entries is not the same for both arrays. Changes since v1: - fix EMIO_SD1_CD pin name - add USB to pinmux options changes since RFCv2: - let Zynq select PINCTRL_ZYNQ. Boot hangs when pinctrl information is present in DT but no driver available. - add #defines to get rid of magical constants - add commas at end of initializers - separate changes in mach-zynq in separate patch - add driver specific io-standard DT property - refactored pinconf set function to not require arguments for argument-less properties - squash other patches in - support for IO-standard property - support for low-power mode property - migration to pinconf_generic_dt_node_to_map_all() - use newly created infrastructure to add pass driver-specific DT params to pinconf-generic changes since RFC: - use syscon/regmap to access registers in SLCR space - rebase to 3.18: rename enable -> set_mux - add kernel-doc - support pinconf - supported attributes - pin-bias: pull up, tristate, disable - slew-rate: 0 == slow, 1 == fast; generic pinconf does not display argument Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Tested-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-09 15:43:48 +00:00
config PINCTRL_ZYNQ
bool "Pinctrl driver for Xilinx Zynq"
depends on ARCH_ZYNQ
select PINMUX
select GENERIC_PINCONF
help
This selectes the pinctrl driver for Xilinx Zynq.
pinctrl: bcm: consolidate Broadcom pinctrl drivers Consolidate Broadcom pinctrl drivers into drivers/pinctrl/bcm/* Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-05 00:35:49 +00:00
source "drivers/pinctrl/bcm/Kconfig"
pinctrl: berlin: add the core pinctrl driver for Marvell Berlin SoCs The Marvell Berlin boards have a group based pinmuxing mechanism. This adds the core driver support. We actually do not need any information about the pins here and only have the definition of the groups. Let's take the example of the uart0 pinmuxing on the BG2Q. Balls BK4 and BH6 are muxed to respectively UART0 RX and TX if the group GSM12 is set to mode 0: Group Modes Offset Base Offset LSB Bit Width GSM12 3 sm_base 0x40 0x10 0x2 Ball Group Mode 0 Mode 1 Mode 2 BK4 GSM12 UART0_RX IrDA0_RX GPIO9 BH6 GSM12 UART0_TX IrDA0_TX GPIO10 So in order to configure BK4 -> UART0_TX and BH6 -> UART0_RX, we need to set (sm_base + 0x40 + 0x10) &= ff3fffff. As pin control registers are part of either chip control or system control registers, that deal with a bunch of other functions we rely on a regmap instead of exclusively remapping any resources. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-05-19 17:36:29 +00:00
source "drivers/pinctrl/berlin/Kconfig"
pinctrl: imx/mxs: move freescale drivers to subdir This moves all the Freescale-related drivers (i.MX and MXS) to its own subdirectory to clear the view. Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Anson Huang <b20788@freescale.com> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Denis Carikli <denis@eukrea.com> Cc: Markus Pargmann <mpa@pengutronix.de> Cc: Greg Ungerer <gerg@uclinux.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-03 11:37:38 +00:00
source "drivers/pinctrl/freescale/Kconfig"
pinctrl: Move Intel Baytrail pinctrl driver under intel directory We are going to have more pinctrl drivers for Intel hardware so separate all our pin controller drivers to own directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-10-24 12:16:52 +00:00
source "drivers/pinctrl/intel/Kconfig"
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: nomadik: move all Nomadik drivers to subdir We have a bunch of Nomadik family pin control drivers, so let's move them into their own subdirectory. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-11 12:57:06 +00:00
source "drivers/pinctrl/nomadik/Kconfig"
pinctrl: msm: move all qualcomm drivers to subdir We have four Qualcomm-related pin control drivers, and now there are drivers coming in for the PMICs on these systems, so let's create a qcom subdirectory to hold all the Qualcomm stuff. Acked-by: Ivan T. Ivanov <iivanov@mm-sol.com> Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-09 11:55:12 +00:00
source "drivers/pinctrl/qcom/Kconfig"
pinctrl: samsung: Group all drivers in a sub-dir Group all pin control drivers of Samsung platform together in a sub-directory for easy maintenance. Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-10 12:03:27 +00:00
source "drivers/pinctrl/samsung/Kconfig"
sh-pfc: Move driver from drivers/sh/ to drivers/pinctrl/ Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Paul Mundt <lethal@linux-sh.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2012-12-15 22:51:19 +00:00
source "drivers/pinctrl/sh-pfc/Kconfig"
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"
pinctrl: sunxi: Move the Allwinner pinctrl driver to its own directory This will allow to create numerous files without crippling the main pinctrl directory. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2014-04-18 16:53:02 +00:00
source "drivers/pinctrl/sunxi/Kconfig"
pinctrl: gpio: vt8500: Add pincontrol driver for arch-vt8500 This patch adds support for the GPIO/pinmux controller found on the VIA VT8500 and Wondermedia WM8xxx-series SoCs. Each pin within the controller is capable of operating as a GPIO or as an alternate function. The pins are numbered according to their control bank/bit so that if new pins are added, the existing numbering is maintained. All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and WM8850. Signed-off-by: Tony Prisk <linux@prisktech.co.nz> Reviewed-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2013-02-19 20:32:19 +00:00
source "drivers/pinctrl/vt8500/Kconfig"
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
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: add TB10x pin control driver The pinmux driver of the Abilis Systems TB10x platform based on ARC700 CPUs. Used to control the pinmux and is a prerequisite for the GPIO driver. Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com> Signed-off-by: Pierrick Hascoet <pierrick.hascoet@abilis.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-10-15 13:39:38 +00:00
config PINCTRL_TB10X
bool
depends on ARC_PLAT_TB10X
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