AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-25 01:40:53 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
f6b178851c
linux_dsm_epyc7002/drivers/pinctrl/Kconfig

287 lines
5.8 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-03 01:50:54 +07: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-06 03:28:46 +07: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-03 01:50:54 +07: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-06 03:28:46 +07: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-03 01:50:54 +07:00
config PINMUX
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 23:14:33 +07:00
bool "Support pin multiplexing controllers"
config PINCONF
bool "Support pin configuration controllers"
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-03 01:50:54 +07: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-25 00:27:15 +07: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-03 01:50:54 +07:00
config DEBUG_PINCTRL
bool "Debug PINCTRL calls"
depends on DEBUG_KERNEL
help
Say Y here to add some extra checks and diagnostics to PINCTRL calls.
pinctrl: add abx500 pinctrl driver core This adds the AB8500 core driver, which will be utilized by the follow-on drivers for different ABx500 variants. Sselect the driver from the DBX500_SOC, as this chip is powering and clocking that SoC. Cc: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-08 16:41:02 +07:00
config PINCTRL_ABX500
bool "ST-Ericsson ABx500 family Mixed Signal Circuit gpio functions"
depends on AB8500_CORE
select GENERIC_PINCONF
help
Select this to enable the ABx500 family IC GPIO driver
pinctrl/abx500: add AB8500 sub-driver This adds a subdriver for the AB8500 pinctrl portions. As the pin controller (also the ABx500 controllers) is an inherent part of the SoC and will prevent boot if not available, select this from the Ux500 SoC Kconfig. Acked-by: Olof Johansson <olof@lixom.net> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-08 16:59:53 +07:00
config PINCTRL_AB8500
bool "AB8500 pin controller driver"
depends on PINCTRL_ABX500 && ARCH_U8500
pinctrl/abx500: add AB8540 sub-driver Add AB8540 sub driver to the ABx500 family, pins, pin groups and gpio range. As the pin controller (also the ABx500 controllers) is an inherent part of the SoC and will prevent boot if not available, select this from the Ux500 SoC Kconfig. Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Patrice Chotard <patrice.chotard@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-28 20:35:19 +07:00
config PINCTRL_AB8540
bool "AB8540 pin controller driver"
depends on PINCTRL_ABX500 && ARCH_U8500
pinctrl/abx500: add AB9540 sub-driver Add AB9540 sub driver to the ABx500 family, pins, pin groups and gpio range. As the pin controller (also the ABx500 controllers) is an inherent part of the SoC and will prevent boot if not available, select this from the Ux500 SoC Kconfig. Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Patrice Chotard <patrice.chotard@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-28 20:29:35 +07:00
config PINCTRL_AB9540
bool "AB9540 pin controller driver"
depends on PINCTRL_ABX500 && ARCH_U8500
pinctrl/abx500: add AB8505 sub-driver Add AB8505 sub driver to the ABx5x family. As the pin controller (also the ABx500 controllers) is an inherent part of the SoC and will prevent boot if not available, select this from the Ux500 SoC Kconfig. Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Patrice Chotard <patrice.chotard@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-28 20:23:45 +07:00
config PINCTRL_AB8505
bool "AB8505 pin controller driver"
depends on PINCTRL_ABX500 && ARCH_U8500
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 22:35:02 +07:00
config PINCTRL_AT91
bool "AT91 pinctrl driver"
depends on OF
depends on ARCH_AT91
select PINMUX
select PINCONF
help
Say Y here to enable the at91 pinctrl driver
pinctrl: add Intel BayTrail GPIO/pinctrl support Add support for gpio on Intel BayTrail platforms. BayTrail supports 3 banks of gpios called SCORE, NCORE ans SUS with 102, 28 and 44 gpio pins. Supports gpio interrupts and ACPI gpio events Pins may be muxed to alternate function instead of gpio by firmware. This driver does not touch the pin muxing and expect firmare to set pin muxing and pullup/down properties properly. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-06-18 18:33:02 +07:00
config PINCTRL_BAYTRAIL
bool "Intel Baytrail GPIO pin control"
depends on GPIOLIB && ACPI && X86
select IRQ_DOMAIN
help
driver for memory mapped GPIO functionality on Intel Baytrail
platforms. Supports 3 banks with 102, 28 and 44 gpios.
Most pins are usually muxed to some other functionality by firmware,
so only a small amount is available for gpio use.
Requires ACPI device enumeration code to set up a platform device.
pinctrl: add bcm2835 driver The BCM2835 GPIO module is a combined GPIO controller, (GPIO) interrupt controller, and pinmux/control device. Original driver by Simon Arlott. Rewrite including GPIO chip device by Chris Boot. Upstreaming changes by Stephen Warren: * Wrote DT binding documentation. * Changed brcm,function to an integer to more directly match the datasheet, and to match brcm,pins being an integer. * Implemented pull-up/down pin config. * Removed read-only DT property and related code. The restriction this implemented are driven by the board, not the GPIO HW block, so don't really make sense of a HW block binding, were in general incomplete (since they could only know about the few pins hard-coded into the Raspberry Pi B board design and not the uncommitted GPIOS), and are better represented simply by not writing incorrect data into pin configuration nodes. * Don't set GPIO_IN function select in gpio_request_enable() to avoid glitches; defer this to gpio_set_direction(). Consequently, removed empty bcm2835_pmx_gpio_request_enable(). * Simplified enabled_irq_map[]; make it explicitly 1 entry per bank. * Lifted use of enabled_irq_map[] outside the per-interrupt loop in IRQ handler, thus fixing an issue where the code was indexing into enabled_irq_map[] by intra-bank GPIO ID, not global GPIO ID. * Removed locking in IRQ handler, since all other code uses spin_lock_irqsave() and so guarantees it doesn't run concurrently with the handler. * Moved duplicated BUILD_BUG_ON()s into probe(). Also check size of bcm2835_gpio_pins[]. * Remove range-checking from bcm2835_pctl_get_groups_count() since we've decided to trust the pinctrl core. * Made bcm2835_pmx_gpio_disable_free() call bcm2835_pinctrl_fsel_set() directly for simplicity. * Fixed body of dt_free_map() to match latest dt_node_to_map(). * Removed GPIO ownership check from bcm2835_pmx_enable() since the pinctrl core owns doing this. * Made irq_chip and pinctrl_gpio_range .name == MODULE_NAME so it's more descriptive. * Simplified remove(); removed call to non-existent pinctrl_remove_gpio_range(), remove early return on error. * Don't force gpiochip's base to 0. Set gpio_range.base to gpiochip's base GPIO number. * Error-handling cleanups in probe(). * Switched to module_platform_driver() rather than open-coding. * Made pin, group, and function names lower-case. * s/broadcom/brcm/ in DT property names. * s/2708/2835/. * Fixed a couple minor checkpatch warnings, and other minor cleanup. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Signed-off-by: Chris Boot <bootc@bootc.net> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-09-28 11:10:11 +07:00
config PINCTRL_BCM2835
bool
select PINMUX
select PINCONF
pinctrl: pinctrl-imx: add imx pinctrl core driver The driver has mux and config support while the gpio is still not supported. For select input setting, the driver will handle it internally and do not need user to take care of it. The pinctrl-imx core driver will parse the dts file and dynamically create the pinmux functions and groups. Each IMX SoC pinctrl driver should register pins with a pin register map including mux register and config register and select input map to core for proper operations. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 19:26:16 +07:00
config PINCTRL_IMX
bool
select PINMUX
select PINCONF
pinctrl: pinctrl-imx: add imx35 pinctrl driver This is mostly cut'n'paste from the imx51 pinctrl driver. The data was generated using sed and awk on arch/arm/plat-mxc/include/mach/iomux-mx35.h. Changes since (implicit) v1 - remove references to file names in binding documentation - remove sed commands from comments in driver - add explicit numbers for pins and functions Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-08-09 23:23:32 +07:00
config PINCTRL_IMX35
bool "IMX35 pinctrl driver"
depends on OF
depends on SOC_IMX35
select PINCTRL_IMX
help
Say Y here to enable the imx35 pinctrl driver
pinctrl: pinctrl-imx: add imx51 pinctrl driver ChangeLog v1->v2: * change PIN_FUNC_ID base in binding doc to 0 from 1. Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-15 14:49:03 +07:00
config PINCTRL_IMX51
bool "IMX51 pinctrl driver"
depends on OF
depends on SOC_IMX51
select PINCTRL_IMX
help
Say Y here to enable the imx51 pinctrl driver
pinctrl: pinctrl-imx: add imx53 pinctrl driver ChangeLog v1->v2: * change PIN_FUNC_ID base in binding doc to 0 from 1. Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-15 14:49:02 +07:00
config PINCTRL_IMX53
bool "IMX53 pinctrl driver"
depends on OF
depends on SOC_IMX53
select PINCTRL_IMX
help
Say Y here to enable the imx53 pinctrl driver
pinctrl: pinctrl-imx: add imx6q pinctrl driver Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 19:26:17 +07:00
config PINCTRL_IMX6Q
pinctrl: add pinctrl driver for imx6dl The imx6dl is a derivative of imx6q with very limited difference. These two SoCs are so compatible that they can be handled as one platform in software. That said, we will not have target SOC_IMX6DL but just reusing SOC_IMX6Q. That's why the pinctrl-imx6dl driver is added here with symbol PINCTRL_IMX6Q controlling the build of it. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2013-03-21 20:55:41 +07:00
bool "IMX6Q/DL pinctrl driver"
pinctrl: pinctrl-imx: add imx6q pinctrl driver Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 19:26:17 +07:00
depends on OF
depends on SOC_IMX6Q
select PINCTRL_IMX
help
pinctrl: add pinctrl driver for imx6dl The imx6dl is a derivative of imx6q with very limited difference. These two SoCs are so compatible that they can be handled as one platform in software. That said, we will not have target SOC_IMX6DL but just reusing SOC_IMX6Q. That's why the pinctrl-imx6dl driver is added here with symbol PINCTRL_IMX6Q controlling the build of it. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2013-03-21 20:55:41 +07:00
Say Y here to enable the imx6q/dl pinctrl driver
pinctrl: pinctrl-imx: add imx6q pinctrl driver Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 19:26:17 +07:00
pinctrl: add pinctrl driver for imx6sl Add a pinctrl driver for i.MX6 SoloLite based on pinctrl-imx core driver. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2013-03-21 21:10:36 +07:00
config PINCTRL_IMX6SL
bool "IMX6SL pinctrl driver"
depends on OF
depends on SOC_IMX6SL
select PINCTRL_IMX
help
Say Y here to enable the imx6sl pinctrl driver
pinctrl: pinctrl-imx: add imx6q pinctrl driver Acked-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 19:26:17 +07:00
pinctrl: add VF610 pinctrl driver Adds Freescale Vybrid VF610 pin controller driver to IMX common pinctrl driver framework. Signed-off-by: Jingchang Lu <b35083@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-05-28 16:32:08 +07:00
config PINCTRL_VF610
bool "Freescale Vybrid VF610 pinctrl driver"
depends on OF
depends on SOC_VF610
select PINCTRL_IMX
help
Say Y here to enable the Freescale Vybrid VF610 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 17:44:59 +07: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-20 05:33:56 +07:00
config PINCTRL_FALCON
bool
depends on SOC_FALCON
depends on PINCTRL_LANTIQ
pinctrl: add pinctrl-mxs support Add pinctrl support for Freescale MXS SoCs, i.MX23 and i.MX28. The driver supports device tree probe only. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-28 12:00:50 +07:00
config PINCTRL_MXS
bool
pinctrl: mxs: Make PINCTRL_MXS select PINMUX && PINCONF Then we can remove "select PINMUX && PINCONF" from PINCTRL_IMX{23,28}. This simplifies the dependency. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-12 09:01:56 +07:00
select PINMUX
select PINCONF
pinctrl: add pinctrl-mxs support Add pinctrl support for Freescale MXS SoCs, i.MX23 and i.MX28. The driver supports device tree probe only. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-28 12:00:50 +07:00
config PINCTRL_IMX23
bool
select PINCTRL_MXS
config PINCTRL_IMX28
bool
select PINCTRL_MXS
pinctrl/nomadik: basic Nomadik pinctrl interface This adds a scratch pin control interface to the Nomadik pinctrl driver, and defines the pins and groups in the DB8500 ASIC. We define GPIO ranges to cover the pins exposed. The DB8500 has more pins than this but we restrict the driver to the pins that can be controlled from the combined GPIO and pin control hardware to begin with. ChangeLog v1->v2: - Base on the latest pinctrl development from pinctrl-mergebase-20120418 so we can get rid of legacy group count mechanism. Also drop the range checks for group index, this is handled by the core now. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 04:57:25 +07:00
config PINCTRL_NOMADIK
bool "Nomadik pin controller driver"
ARM: nomadik: enable PINCTRL_NOMADIK where needed The nomadik gpio code has been converted to pinctrl, but the nomadik platform still expects the old code to be present. Change it to use the new one instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-15 18:24:34 +07:00
depends on ARCH_U8500 || ARCH_NOMADIK
pinctrl/nomadik: implement pin multiplexing Implements basic pinmux for the Nomadik pin controller. The plan is to split the existing singular pin config interface nmk_config_pin(), nmk_config_pins(), that will configure muxing and other settings at the same time, into two interfaces by splitting the code in pinmux and pinctrl and eventually deleting the old interface and its helper functions when all users are gone. nmk_gpio_set_mode() and nmk_gpio_get_mode() are two older interfaces for just configuring muxing/altfunctions that will also be replaced in the end. We take some extra care to handle the glitch-avoidance here, but it is simpler now since there is only one altsetting per pingroup so we know immediately if we need to avoid altfunc C glitches for a certain group. As part of the makeover implement the .request() and .free() calls on the GPIO chips and have them call back into the pinctrl layer to reserve GPIOs. ChangeLog v1->v2: - Rebased on pinctrl-mergebase-20120418 so we get the latest driver infrastructure where function count is done by a fixed value and we can drop a few range checks since this is now handled by the core. - Include a GPIO muxing hunk erroneously part of the pin config patch. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-03 03:56:47 +07:00
select PINMUX
pinctrl/nomadik: implement pin configuration This implements the pin configuration interface for the Nomadik pin controller. As part of the exercise we add a bit in the pin_cfg_t for the Nomadik pinctrl driver that indicates if the pin should be forced into GPIO mode. This is not done to go behind the back of the GPIO subsystem, but to ensure that default modes can be set by hogs on boot and system suspend/resume states. It was used implicitly by the old code defining all config settings and modes in a single config word but we now have a split between pinmux and pinconf leading to the need to have this. We also add a bit for explicitly setting sleepmode of the pin. This was previously handled by custom calls with the _sleep() suffix, but we now have one single interface into the configuration so we replace this with a bit indicating that the pin shall be configured into sleep mode. Some of the configuration can be refactored later to use less custom fields on the pin_cfg_t but we are currently leaving the old function calls in place so we stay compatible. ChangeLog v1->v2: - Drop a hunk changing pinmuxing for GPIO and move it over to the preceding pinmux patch. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-03 20:58:12 +07:00
select PINCONF
pinctrl/nomadik: basic Nomadik pinctrl interface This adds a scratch pin control interface to the Nomadik pinctrl driver, and defines the pins and groups in the DB8500 ASIC. We define GPIO ranges to cover the pins exposed. The DB8500 has more pins than this but we restrict the driver to the pins that can be controlled from the combined GPIO and pin control hardware to begin with. ChangeLog v1->v2: - Base on the latest pinctrl development from pinctrl-mergebase-20120418 so we can get rid of legacy group count mechanism. Also drop the range checks for group index, this is handled by the core now. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 04:57:25 +07:00
pinctrl/nomadik: add STn8815 ASIC support This adds support for the STN8815 ASIC for the Nomadik pin controller. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-08-10 05:43:28 +07:00
config PINCTRL_STN8815
bool "STN8815 pin controller driver"
depends on PINCTRL_NOMADIK && ARCH_NOMADIK
pinctrl/nomadik: basic Nomadik pinctrl interface This adds a scratch pin control interface to the Nomadik pinctrl driver, and defines the pins and groups in the DB8500 ASIC. We define GPIO ranges to cover the pins exposed. The DB8500 has more pins than this but we restrict the driver to the pins that can be controlled from the combined GPIO and pin control hardware to begin with. ChangeLog v1->v2: - Base on the latest pinctrl development from pinctrl-mergebase-20120418 so we can get rid of legacy group count mechanism. Also drop the range checks for group index, this is handled by the core now. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-04-27 04:57:25 +07:00
config PINCTRL_DB8500
bool "DB8500 pin controller driver"
depends on PINCTRL_NOMADIK && ARCH_U8500
pinctrl/nomadik: add ASIC DB8450 pinctrl driver This implements a subdriver for the DB8540 ASIC for the Nomadik pin controller. Signed-off-by: Patrice Chotard <patrice.chotard@stericsson.com> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-07-20 20:45:22 +07:00
config PINCTRL_DB8540
bool "DB8540 pin controller driver"
depends on PINCTRL_NOMADIK && ARCH_U8500
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-11 03:16:22 +07:00
config PINCTRL_ROCKCHIP
bool
select PINMUX
select GENERIC_PINCONF
select GENERIC_IRQ_CHIP
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 16:05:46 +07: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 18:42:55 +07: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 16:05:46 +07: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-19 05:44:26 +07:00
config PINCTRL_SIRF
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 16:56:30 +07:00
bool "CSR SiRFprimaII/SiRFmarco pin controller driver"
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 17:11:13 +07:00
select PINMUX
ARM: sunxi: Add pinctrl driver for Allwinner SoCs The Allwinner SoCs have an IP module that handle both the muxing and the GPIOs. This IP has 8 banks of 32 bits, with a number of pins actually useful for each of these banks varying from one to another, and depending on the SoC used on the board. This driver only implements the pinctrl part, the gpio part will come eventually. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-19 04:30:34 +07:00
config PINCTRL_SUNXI
bool
select PINMUX
select GENERIC_PINCONF
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 21:05:38 +07:00
config PINCTRL_ST
bool
depends on OF
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-02 04:04:47 +07: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 09:00:22 +07: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-02 04:04:47 +07: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 14:32:37 +07:00
config PINCTRL_TEGRA114
bool
select PINCTRL_TEGRA
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 16:26:27 +07: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 16:26:29 +07: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-19 05:44:26 +07: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-03 01:54:38 +07: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-17 03:58:10 +07: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-06 03:28:46 +07: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 15:22:59 +07: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-19 01:07:50 +07:00
depends on GPIOLIB && ARCH_U300 && PINCTRL_U300
pinctrl: move the U300 GPIO driver to pinctrl This driver will be converted to a dual GPIO + pinctrl driver since it supports biasing and driving control options. Hopefully it can serve as an example. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-16 15:22:59 +07:00
help
Say yes here to support GPIO interface on ST-Ericsson U300.
The names of the two IP block variants supported are
COH 901 335 and COH 901 571/3. They contain 3, 5 or 7
ports of 8 GPIO pins each.
pinctrl: add samsung pinctrl and gpiolib driver Add a new device tree enabled pinctrl and gpiolib driver for Samsung SoC's. This driver provides a common and extensible framework for all Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This driver supports only device tree based instantiation and hence can be used only on those Samsung platforms that have device tree enabled. This driver is split into two parts: the pinctrl interface and the gpiolib interface. The pinctrl interface registers pinctrl devices with the pinctrl subsystem and gpiolib interface registers gpio chips with the gpiolib subsystem. The information about the pins, pin groups, pin functions and gpio chips, which are SoC specific, are parsed from device tree node. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07 04:07:19 +07:00
config PINCTRL_SAMSUNG
pinctrl/samsung: don't allow enabling pinctrl-samsung standalone The main samsung pinctrl module references the specific exynos4210 pinctrl driver, which selects the main driver in Kconfig. Making the main driver a silent "bool" option avoid this potential build error if CONFIG_PINCTRL_SAMSUNG=y && CONFIG_PINCTRL_EXYNOS4=n: drivers/built-in.o:(.rodata+0x4e4): undefined reference to `exynos4210_pin_ctrl' Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Tomasz Figa <t.figa@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Linus Walleij <linus.walleij@linaro.org> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-15 17:58:24 +07:00
bool
pinctrl: add samsung pinctrl and gpiolib driver Add a new device tree enabled pinctrl and gpiolib driver for Samsung SoC's. This driver provides a common and extensible framework for all Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This driver supports only device tree based instantiation and hence can be used only on those Samsung platforms that have device tree enabled. This driver is split into two parts: the pinctrl interface and the gpiolib interface. The pinctrl interface registers pinctrl devices with the pinctrl subsystem and gpiolib interface registers gpio chips with the gpiolib subsystem. The information about the pins, pin groups, pin functions and gpio chips, which are SoC specific, are parsed from device tree node. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07 04:07:19 +07:00
select PINMUX
select PINCONF
pinctrl: exynos: change PINCTRL_EXYNOS option Since pinctrl-exynos can support exynos4 and exynos5 so changed the option name to PINCTRL_EXYNOS for more clarity. Cc: Thomas Abraham <Thomas.abraham@linaro.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-19 02:35:06 +07:00
config PINCTRL_EXYNOS
ARM: EXYNOS: Select PINCTRL_EXYNOS for exynos4/5 at chip level Previously if you had MACH_EXYNOS5_DT but not MACH_EXYNOS4_DT you'd be missing the pincontrol definitions. Move PINCTRL selects to the arch level since we should be enabling the code for all exynos variants. Update the PINCTRL descriptions to indicate that PINCTRL_EXYNOS is not for exynos5440. Also add basic dependencies for the PINCTRL_EXYNOS kernel config. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2013-06-10 16:26:53 +07:00
bool "Pinctrl driver data for Samsung EXYNOS SoCs other than 5440"
depends on OF && GPIOLIB && ARCH_EXYNOS
pinctrl: add exynos4210 specific extensions for samsung pinctrl driver Add information about the Exynos4210 pin banks and driver data which is used by the Samsung pinctrl driver. In addition to this, the support for external gpio and wakeup interrupt support is included and hooked up with the Samsung pinctrl driver. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07 04:07:19 +07:00
select PINCTRL_SAMSUNG
pinctrl: exynos5440: add pinctrl driver for Samsung EXYNOS5440 SoC Add a new pinctrl driver for Samsung EXYNOS5440 SoC. The pin controller module in EXYNOS5440 is different from the pin controller found on other Samsung SoC. Hence, the pin controller driver for EXYNOS5440 SoC is independent of the Samsung pinctrl framework. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-10-10 07:41:12 +07:00
config PINCTRL_EXYNOS5440
bool "Samsung EXYNOS5440 SoC pinctrl driver"
ARM: EXYNOS: Select PINCTRL_EXYNOS for exynos4/5 at chip level Previously if you had MACH_EXYNOS5_DT but not MACH_EXYNOS4_DT you'd be missing the pincontrol definitions. Move PINCTRL selects to the arch level since we should be enabling the code for all exynos variants. Update the PINCTRL descriptions to indicate that PINCTRL_EXYNOS is not for exynos5440. Also add basic dependencies for the PINCTRL_EXYNOS kernel config. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2013-06-10 16:26:53 +07:00
depends on SOC_EXYNOS5440
pinctrl: exynos5440: add pinctrl driver for Samsung EXYNOS5440 SoC Add a new pinctrl driver for Samsung EXYNOS5440 SoC. The pin controller module in EXYNOS5440 is different from the pin controller found on other Samsung SoC. Hence, the pin controller driver for EXYNOS5440 SoC is independent of the Samsung pinctrl framework. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-10-10 07:41:12 +07:00
select PINMUX
select PINCONF
pinctrl: Add pinctrl-s3c24xx driver The s3c24xx pins follow a similar pattern as the other Samsung SoCs and can therefore reuse the already introduced infrastructure. The s3c24xx SoCs have one design oddity in that the first 4 external interrupts do not reside in the eint pending register but in the main interrupt controller instead. We solve this by forwarding the external interrupt from the main controller into the irq domain of the pin bank. The masking/acking of these interrupts is handled in the same way. Furthermore the S3C2412/2413 SoCs contain another oddity in that they keep the same 4 eints in the main interrupt controller and eintpend register and requiring ack operations to happen in both. This is solved by using different compatible properties for the wakeup eint node which set a property accordingly. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2013-05-20 22:56:13 +07:00
config PINCTRL_S3C24XX
bool "Samsung S3C24XX SoC pinctrl driver"
depends on ARCH_S3C24XX
select PINCTRL_SAMSUNG
pinctrl: Add pinctrl-s3c64xx driver This patch adds pinctrl-s3c64xx driver which implements pin control interface for Samsung S3C64xx SoCs. Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-03-19 04:31:55 +07:00
config PINCTRL_S3C64XX
bool "Samsung S3C64XX SoC pinctrl driver"
depends on ARCH_S3C64XX
select PINCTRL_SAMSUNG
pinctrl: mvebu: move to its own directory Like the spear platform, the mvebu platform has multiple files: one core file, and then one file per SoC family. More files will be added later, as support for mach-orion5x and mach-mv78xx0 SoCs is added to pinctrl-mvebu. For those reasons, having a separate subdirectory, drivers/pinctrl/mvebu/ makes sense, and it had already been suggested by Linus Wallej when the driver was originally submitted. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-10-25 04:38:58 +07:00
source "drivers/pinctrl/mvebu/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-16 05:51:19 +07: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 23:57:07 +07:00
source "drivers/pinctrl/spear/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-20 03:32:19 +07: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 23:57:07 +07: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 17:44:59 +07:00
config PINCTRL_XWAY
bool
depends on SOC_TYPE_XWAY
depends on PINCTRL_LANTIQ
pinctrl: hide subsystem from the populace Machines that have embedded pin controllers need to select them explicitly, so why broadcast their config options to menuconfig. We provide a helpful submenu for those machines that do select it, making it possible to enable debugging for example. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-11-06 03:28:46 +07: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-03 01:54:38 +07: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-03 01:50:54 +07:00
endif
Reference in New Issue Copy Permalink