davidlt/kernel-ark
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
0e3db173e2
kernel-ark/drivers/pinctrl/core.h

117 lines
3.7 KiB
C
Raw Normal View History

drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
/*
* Core private header for the pin control subsystem
*
* Copyright (C) 2011 ST-Ericsson SA
* Written on behalf of Linaro for ST-Ericsson
*
* Author: Linus Walleij <linus.walleij@linaro.org>
*
* License terms: GNU General Public License (GPL) version 2
*/
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
#include <linux/mutex.h>
#include <linux/radix-tree.h>
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
#include <linux/pinctrl/pinconf.h>
struct pinctrl_gpio_range;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
/**
* struct pinctrl_dev - pin control class device
* @node: node to include this pin controller in the global pin controller list
* @desc: the pin controller descriptor supplied when initializing this pin
* controller
* @pin_desc_tree: each pin descriptor for this pin controller is stored in
* this radix tree
* @gpio_ranges: a list of GPIO ranges that is handled by this pin controller,
* ranges are added to this list at runtime
* @dev: the device entry for this pin controller
* @owner: module providing the pin controller, used for refcounting
* @driver_data: driver data for drivers registering to the pin controller
* subsystem
pinctrl: introduce PINCTRL_STATE_DEFAULT, define hogs as that state This provides a single centralized name for the default state. Update PIN_MAP_* macros to use this state name, instead of requiring the user to pass a state name in. With this change, hog entries in the mapping table are defined as those with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same name. This interacts badly with the nested iteration over mapping table entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now attempt to claim each hog mapping table entry multiple times. Replacing the custom hog code with a simple pinctrl_get()/pinctrl_enable(). Update documentation and mapping tables to use this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 01:48:32 +00:00
* @p: result of pinctrl_get() for this device
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 18:47:48 +00:00
* @device_root: debugfs root for this device
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
*/
struct pinctrl_dev {
struct list_head node;
struct pinctrl_desc *desc;
struct radix_tree_root pin_desc_tree;
struct list_head gpio_ranges;
pinctrl: don't create a device for each pin controller Pin controllers should already be instantiated as a device, so there's no need for the pinctrl core to create a new struct device for each controller. This allows the controller's real name to be used in the mux mapping table, rather than e.g. "pinctrl.0", "pinctrl.1", etc. This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since their sole purpose was to hard-code the .ctrl_dev_name field to be "pinctrl.0". Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-09 23:59:05 +00:00
struct device *dev;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
struct module *owner;
void *driver_data;
pinctrl: introduce PINCTRL_STATE_DEFAULT, define hogs as that state This provides a single centralized name for the default state. Update PIN_MAP_* macros to use this state name, instead of requiring the user to pass a state name in. With this change, hog entries in the mapping table are defined as those with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same name. This interacts badly with the nested iteration over mapping table entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now attempt to claim each hog mapping table entry multiple times. Replacing the custom hog code with a simple pinctrl_get()/pinctrl_enable(). Update documentation and mapping tables to use this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 01:48:32 +00:00
struct pinctrl *p;
pinctrl: free debugfs entries when unloading a pinmux driver We were not cleaning up properly after unloading a pinmux driver compiled as module. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-01-20 16:17:22 +00:00
#ifdef CONFIG_DEBUG_FS
struct dentry *device_root;
#endif
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 18:47:48 +00:00
};
/**
* struct pinctrl - per-device pin control state holder
* @node: global list node
* @dev: the device using this pin control handle
pinctrl: refactor struct pinctrl handling in core.c vs pinmux.c This change separates two aspects of struct pinctrl: a) The data representation of the parsed mapping table, into: 1) The top-level struct pinctrl object, a single entity returned by pinctrl_get(). 2) The parsed version of each mapping table entry, struct pinctrl_setting, of which there is one per mapping table entry. b) The code that handles this; the code for (1) above is in core.c, and the code to parse/execute each entry in (2) above is in pinmux.c, while the iteration over multiple settings is lifted to core.c. This will allow the following future changes: 1) pinctrl_get() API rework, so that struct pinctrl represents all states for the device, and the device can select between them without calling put()/get() again. 2) To support that, a struct pinctrl_state object will be inserted into the data model between the struct pinctrl and struct pinctrl_setting. 3) The mapping table will be extended to allow specification of pin config settings too. To support this, struct pinctrl_setting will be enhanced to store either mux settings or config settings, and functions will be added to pinconf.c to parse/execute pin configuration settings. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:45 +00:00
* @state: the state name passed to pinctrl_get()
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 18:47:48 +00:00
* @usecount: the number of active users of this pin controller setting, used
* to keep track of nested use cases
pinctrl: refactor struct pinctrl handling in core.c vs pinmux.c This change separates two aspects of struct pinctrl: a) The data representation of the parsed mapping table, into: 1) The top-level struct pinctrl object, a single entity returned by pinctrl_get(). 2) The parsed version of each mapping table entry, struct pinctrl_setting, of which there is one per mapping table entry. b) The code that handles this; the code for (1) above is in core.c, and the code to parse/execute each entry in (2) above is in pinmux.c, while the iteration over multiple settings is lifted to core.c. This will allow the following future changes: 1) pinctrl_get() API rework, so that struct pinctrl represents all states for the device, and the device can select between them without calling put()/get() again. 2) To support that, a struct pinctrl_state object will be inserted into the data model between the struct pinctrl and struct pinctrl_setting. 3) The mapping table will be extended to allow specification of pin config settings too. To support this, struct pinctrl_setting will be enhanced to store either mux settings or config settings, and functions will be added to pinconf.c to parse/execute pin configuration settings. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:45 +00:00
* @settings: a list of settings for this device/state
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 18:47:48 +00:00
*/
struct pinctrl {
struct list_head node;
struct device *dev;
pinctrl: refactor struct pinctrl handling in core.c vs pinmux.c This change separates two aspects of struct pinctrl: a) The data representation of the parsed mapping table, into: 1) The top-level struct pinctrl object, a single entity returned by pinctrl_get(). 2) The parsed version of each mapping table entry, struct pinctrl_setting, of which there is one per mapping table entry. b) The code that handles this; the code for (1) above is in core.c, and the code to parse/execute each entry in (2) above is in pinmux.c, while the iteration over multiple settings is lifted to core.c. This will allow the following future changes: 1) pinctrl_get() API rework, so that struct pinctrl represents all states for the device, and the device can select between them without calling put()/get() again. 2) To support that, a struct pinctrl_state object will be inserted into the data model between the struct pinctrl and struct pinctrl_setting. 3) The mapping table will be extended to allow specification of pin config settings too. To support this, struct pinctrl_setting will be enhanced to store either mux settings or config settings, and functions will be added to pinconf.c to parse/execute pin configuration settings. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:45 +00:00
const char *state;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 18:47:48 +00:00
unsigned usecount;
pinctrl: refactor struct pinctrl handling in core.c vs pinmux.c This change separates two aspects of struct pinctrl: a) The data representation of the parsed mapping table, into: 1) The top-level struct pinctrl object, a single entity returned by pinctrl_get(). 2) The parsed version of each mapping table entry, struct pinctrl_setting, of which there is one per mapping table entry. b) The code that handles this; the code for (1) above is in core.c, and the code to parse/execute each entry in (2) above is in pinmux.c, while the iteration over multiple settings is lifted to core.c. This will allow the following future changes: 1) pinctrl_get() API rework, so that struct pinctrl represents all states for the device, and the device can select between them without calling put()/get() again. 2) To support that, a struct pinctrl_state object will be inserted into the data model between the struct pinctrl and struct pinctrl_setting. 3) The mapping table will be extended to allow specification of pin config settings too. To support this, struct pinctrl_setting will be enhanced to store either mux settings or config settings, and functions will be added to pinconf.c to parse/execute pin configuration settings. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:45 +00:00
struct list_head settings;
};
/**
* struct pinctrl_setting - an individual mux setting
* @node: list node for struct pinctrl's @settings field
* @pctldev: pin control device handling to be programmed
* @group_selector: the group selector to program
* @func_selector: the function selector to program
*/
struct pinctrl_setting {
struct list_head node;
pinctrl: factor pin control handles over to the core This moves the per-devices struct pinctrl handles and device map over from the pinmux part of the subsystem to the core pinctrl part. This makes the device handles core infrastructure with the goal of using these handles also for pin configuration, so that device drivers (or boards etc) will need one and only one handle to the pin control core. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-09 18:47:48 +00:00
struct pinctrl_dev *pctldev;
pinctrl: refactor struct pinctrl handling in core.c vs pinmux.c This change separates two aspects of struct pinctrl: a) The data representation of the parsed mapping table, into: 1) The top-level struct pinctrl object, a single entity returned by pinctrl_get(). 2) The parsed version of each mapping table entry, struct pinctrl_setting, of which there is one per mapping table entry. b) The code that handles this; the code for (1) above is in core.c, and the code to parse/execute each entry in (2) above is in pinmux.c, while the iteration over multiple settings is lifted to core.c. This will allow the following future changes: 1) pinctrl_get() API rework, so that struct pinctrl represents all states for the device, and the device can select between them without calling put()/get() again. 2) To support that, a struct pinctrl_state object will be inserted into the data model between the struct pinctrl and struct pinctrl_setting. 3) The mapping table will be extended to allow specification of pin config settings too. To support this, struct pinctrl_setting will be enhanced to store either mux settings or config settings, and functions will be added to pinconf.c to parse/execute pin configuration settings. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:45 +00:00
unsigned group_selector;
unsigned func_selector;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
};
/**
* struct pin_desc - pin descriptor for each physical pin in the arch
* @pctldev: corresponding pin control device
* @name: a name for the pin, e.g. the name of the pin/pad/finger on a
* datasheet or such
pinctrl: conjure names for unnamed pins If pins with blank names are registered, we assign them names on-the-fly on the form "PINn" where n is the pin number for that pin on the specific controller. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-14 19:33:37 +00:00
* @dynamic_name: if the name of this pin was dynamically allocated
pinctrl: add usecount to pins for muxing Multiple mapping table entries could reference the same pin, and hence "own" it. This would be unusual now that pinctrl_get() represents a single state for a client device, but in the future when it represents all known states for a device, this is quite likely. Implement reference counting for pin ownership to handle this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:46 +00:00
* @usecount: If zero, the pin is not claimed, and @owner should be NULL.
* If non-zero, this pin is claimed by @owner. This field is an integer
* rather than a boolean, since pinctrl_get() might process multiple
* mapping table entries that refer to, and hence claim, the same group
* or pin, and each of these will increment the @usecount.
* @owner: The name of the entity owning the pin. Typically, this is the name
* of the device that called pinctrl_get(). Alternatively, it may be the
* name of the GPIO passed to pinctrl_request_gpio().
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
*/
struct pin_desc {
struct pinctrl_dev *pctldev;
pinctrl: Don't copy pin names when registering them A pin controller's names array is no longer marked __refdata. Hence, we can avoid copying a pin's name into the descriptor when registering it. Instead, just point at the string supplied in the pin array. This both simplifies and speeds up pin controller initialization, but also removes the hard-coded maximum pin name length. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 22:19:27 +00:00
const char *name;
pinctrl: conjure names for unnamed pins If pins with blank names are registered, we assign them names on-the-fly on the form "PINn" where n is the pin number for that pin on the specific controller. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-12-14 19:33:37 +00:00
bool dynamic_name;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
/* These fields only added when supporting pinmux drivers */
#ifdef CONFIG_PINMUX
pinctrl: add usecount to pins for muxing Multiple mapping table entries could reference the same pin, and hence "own" it. This would be unusual now that pinctrl_get() represents a single state for a client device, but in the future when it represents all known states for a device, this is quite likely. Implement reference counting for pin ownership to handle this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:46 +00:00
unsigned usecount;
pinctrl: record a pin owner, not mux function, when requesting pins When pins are requested/acquired/got, some device becomes the owner of their mux setting. At this point, it isn't certain which mux function will be selected for the pin, since this may vary between each of the device's states in the pinctrl mapping table. As such, we should record the owning device, not what we think the initial mux setting will be, when requesting pins. This doesn't make a lot of difference right now since pinctrl_get gets only one single device/state combination, but this will make a difference when pinctrl_get gets all states, and pinctrl_select_state can switch between states. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-20 06:45:44 +00:00
const char *owner;
drivers: create a pin control subsystem This creates a subsystem for handling of pin control devices. These are devices that control different aspects of package pins. Currently it handles pinmuxing, i.e. assigning electronic functions to groups of pins on primarily PGA and BGA type of chip packages which are common in embedded systems. The plan is to also handle other I/O pin control aspects such as biasing, driving, input properties such as schmitt-triggering, load capacitance etc within this subsystem, to remove a lot of ARM arch code as well as feature-creepy GPIO drivers which are implementing the same thing over and over again. This is being done to depopulate the arch/arm/* directory of such custom drivers and try to abstract the infrastructure they all need. See the Documentation/pinctrl.txt file that is part of this patch for more details. ChangeLog v1->v2: - Various minor fixes from Joe's and Stephens review comments - Added a pinmux_config() that can invoke custom configuration with arbitrary data passed in or out to/from the pinmux driver ChangeLog v2->v3: - Renamed subsystem folder to "pinctrl" since we will likely want to keep other pin control such as biasing in this subsystem too, so let us keep to something generic even though we're mainly doing pinmux now. - As a consequence, register pins as an abstract entity separate from the pinmux. The muxing functions will claim pins out of the pin pool and make sure they do not collide. Pins can now be named by the pinctrl core. - Converted the pin lookup from a static array into a radix tree, I agreed with Grant Likely to try to avoid any static allocation (which is crap for device tree stuff) so I just rewrote this to be dynamic, just like irq number descriptors. The platform-wide definition of number of pins goes away - this is now just the sum total of the pins registered to the subsystem. - Make sure mappings with only a function name and no device works properly. ChangeLog v3->v4: - Define a number space per controller instead of globally, Stephen and Grant requested the same thing so now maps need to define target controller, and the radix tree of pin descriptors is a property on each pin controller device. - Add a compulsory pinctrl device entry to the pinctrl mapping table. This must match the pinctrl device, like "pinctrl.0" - Split the file core.c in two: core.c and pinmux.c where the latter carry all pinmux stuff, the core is for generic pin control, and use local headers to access functionality between files. It is now possible to implement a "blank" pin controller without pinmux capabilities. This split will make new additions like pindrive.c, pinbias.c etc possible for combined drivers and chunks of functionality which is a GoodThing(TM). - Rewrite the interaction with the GPIO subsystem - the pin controller descriptor now handles this by defining an offset into the GPIO numberspace for its handled pin range. This is used to look up the apropriate pin controller for a GPIO pin. Then that specific GPIO range is matched 1-1 for the target controller instance. - Fixed a number of review comments from Joe Perches. - Broke out a header file pinctrl.h for the core pin handling stuff that will be reused by other stuff than pinmux. - Fixed some erroneous EXPORT() stuff. - Remove mispatched U300 Kconfig and Makefile entries - Fixed a number of review comments from Stephen Warren, not all of them - still WIP. But I think the new mapping that will specify which function goes to which pin mux controller address 50% of your concerns (else beat me up). ChangeLog v4->v5: - Defined a "position" for each function, so the pin controller now tracks a function in a certain position, and the pinmux maps define what position you want the function in. (Feedback from Stephen Warren and Sascha Hauer). - Since we now need to request a combined function+position from the machine mapping table that connect mux settings to drivers, it was extended with a position field and a name field. The name field is now used if you e.g. need to switch between two mux map settings at runtime. - Switched from a class device to using struct bus_type for this subsystem. Verified sysfs functionality: seems to work fine. (Feedback from Arnd Bergmann and Greg Kroah-Hartman) - Define a per pincontroller list of GPIO ranges from the GPIO pin space that can be handled by the pin controller. These can be added one by one at runtime. (Feedback from Barry Song) - Expanded documentation of regulator_[get|enable|disable|put] semantics. - Fixed a number of review comments from Barry Song. (Thanks!) ChangeLog v5->v6: - Create an abstract pin group concept that can sort pins into named and enumerated groups no matter what the use of these groups may be, one possible usecase is a group of pins being muxed in or so. The intention is however to also use these groups for other pin control activities. - Make it compulsory for pinmux functions to associate with at least one group, so the abstract pin group concept is used to define the groups of pins affected by a pinmux function. The pinmux driver interface has been altered so as to enforce a function to list applicable groups per function. - Provide an optional .group entry in the pinmux machine map so the map can select beteween different available groups to be used with a certain function. - Consequent changes all over the place so that e.g. debugfs present reasonable information about the world. - Drop the per-pin mux (*config) function in the pinmux_ops struct - I was afraid that this would start to be used for things totally unrelated to muxing, we can introduce that to the generic struct pinctrl_ops if needed. I want to keep muxing orthogonal to other pin control subjects and not mix these things up. ChangeLog v6->v7: - Make it possible to have several map entries matching the same device, pin controller and function, but using a different group, and alter the semantics so that pinmux_get() will pick all matching map entries, and store the associated groups in a list. The list will then be iterated over at pinmux_enable()/pinmux_disable() and corresponding driver functions called for each defined group. Notice that you're only allowed to map multiple *groups* to the same { device, pin controller, function } triplet, attempts to map the same device to multiple pin controllers will for example fail. This is hopefully the crucial feature requested by Stephen Warren. - Add a pinmux hogging field to the pinmux mapping entries, and enable the pinmux core to hog pinmux map entries. This currently only works for pinmuxes without assigned devices as it looks now, but with device trees we can look up the corresponding struct device * entries when we register the pinmux driver, and have it hog each pinmux map in turn, for a simple approach to non-dynamic pin muxing. This addresses an issue from Grant Likely that the machine should take care of as much of the pinmux setup as possible, not the devices. By supplying a list of hogs, it can now instruct the core to take care of any static mappings. - Switch pinmux group retrieveal function to grab an array of strings representing the groups rather than an array of unsigned and rewrite accordingly. - Alter debugfs to show the grouplist handled by each pinmux. Also add a list of hogs. - Dynamically allocate a struct pinmux at pinmux_get() and free it at pinmux_put(), then add these to the global list of pinmuxes active as we go along. - Go over the list of pinmux maps at pinmux_get() time and repeatedly apply matches. - Retrieve applicable groups per function from the driver as a string array rather than a unsigned array, then lookup the enumerators. - Make the device to pinmux map a singleton - only allow the mapping table to be registered once and even tag the registration function with __init so it surely won't be abused. - Create a separate debugfs file to view the pinmux map at runtime. - Introduce a spin lock to the pin descriptor struct, lock it when modifying pin status entries. Reported by Stijn Devriendt. - Fix up the documentation after review from Stephen Warren. - Let the GPIO ranges give names as const char * instead of some fixed-length string. - add a function to unregister GPIO ranges to mirror the registration function. - Privatized the struct pinctrl_device and removed it from the <linux/pinctrl/pinctrl.h> API, the drivers do not need to know the members of this struct. It is now in the local header "core.h". - Rename the concept of "anonymous" mux maps to "system" muxes and add convenience macros and documentation. ChangeLog v7->v8: - Delete the leftover pinmux_config() function from the <linux/pinctrl/pinmux.h> header. - Fix a race condition found by Stijn Devriendt in pin_request() ChangeLog v8->v9: - Drop the bus_type and the sysfs attributes and all, we're not on the clear about how this should be used for e.g. userspace interfaces so let us save this for the future. - Use the right name in MAINTAINERS, PIN CONTROL rather than PINMUX - Don't kfree() the device state holder, let the .remove() callback handle this. - Fix up numerous kerneldoc headers to have one line for the function description and more verbose documentation below the parameters ChangeLog v9->v10: - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch from Steven Rothwell - fix pinctrl_register error handling, folded in a patch from Axel Lin - Various fixes to documentation text so that it's consistent. - Removed pointless comment from drivers/Kconfig - Removed dependency on SYSFS since we removed the bus in v9. - Renamed hopelessly abbreviated pctldev_* functions to the more verbose pinctrl_dev_* - Drop mutex properly when looking up GPIO ranges - Return NULL instead of ERR_PTR() errors on registration of pin controllers, using cast pointers is fragile. We can live without the detailed error codes for sure. Cc: Stijn Devriendt <highguy@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
#endif
};
pinctrl: delete raw device pointers in pinmux maps After discussion with Mark Brown in an unrelated thread about ADC lookups, it came to my knowledge that the ability to pass a struct device * in the regulator consumers is just a historical artifact, and not really recommended. Since there are no in-kernel users of these pointers, we just kill them right now, before someone starts to use them. Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-01 17:02:47 +00:00
struct pinctrl_dev *get_pinctrl_dev_from_devname(const char *dev_name);
pinctrl: add a pin config interface This add per-pin and per-group pin config interfaces for biasing, driving and other such electronic properties. The details of passed configurations are passed in an opaque unsigned long which may be dereferences to integer types, structs or lists on either side of the configuration interface. ChangeLog v1->v2: - Clear split of terminology: we now have pin controllers, and those may support two interfaces using vtables: pin multiplexing and pin configuration. - Break out pin configuration to its own C file, controllers may implement only config without mux, and vice versa, so keep each sub-functionality of pin controllers separate. Introduce CONFIG_PINCONF in Kconfig. - Implement some core logic around pin configuration in the pinconf.c file. - Remove UNKNOWN config states, these were just surplus baggage. - Remove FLOAT config state - HIGH_IMPEDANCE should be enough for everyone. - PIN_CONFIG_POWER_SOURCE added to handle switching the power supply for the pin logic between different sources - Explicit DISABLE config enums to turn schmitt-trigger, wakeup etc OFF. - Update documentation to reflect all the recent reasoning. ChangeLog v2->v3: - Twist API around to pass around arrays of config tuples instead of (param, value) pairs everywhere. - Explicit drive strength semantics for push/pull and similar drive modes, this shall be the number of drive stages vs nominal load impedance, which should match the actual electronics used in push/pull CMOS or TTY totempoles. - Drop load capacitance configuration - I probably don't know what I'm doing here so leave it out. - Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off. - Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead. - Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off. - Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time on input lines. - Fix a bug when we tried to configure pins for pin controllers without pinconf support. - Initialized debugfs properly so it works. - Initialize the mutex properly and lock around config tampering sections. - Check the return value from get_initial_config() properly. ChangeLog v3->v4: - Export the pin_config_get(), pin_config_set() and pin_config_group() functions. - Drop the entire concept of just getting initial config and keeping track of pin states internally, instead ask the pins what state they are in. Previous idea was plain wrong, if the device cannot keep track of its state, the driver should do it. - Drop the generic configuration layout, it seems this impose too much restriction on some pin controllers, so let them do things the way they want and split off support for generic config as an optional add-on. ChangeLog v4->v5: - Introduce two symmetric driver calls for group configuration, .pin_config_group_[get|set] and corresponding external calls. - Remove generic semantic meanings of return values from config calls, these belong in the generic config patch. Just pass the return value through instead. - Add a debugfs entry "pinconf-groups" to read status from group configuration only, also slam in a per-group debug callback in the pinconf_ops so custom drivers can display something meaningful for their pins. - Fix some dangling newline. - Drop dangling #else clause. - Update documentation to match the above. ChangeLog v5->v6: - Change to using a pin name as parameter for the [get|set]_config() functions, as suggested by Stephen Warren. This is more natural as names will be what a developer has access to in written documentation etc. ChangeLog v6->v7: - Refactor out by-pin and by-name get/set functions, only expose the by-name functions externally, expose the by-pin functions internally. - Show supported pin control functionality in the debugfs pinctrl-devices file. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
int pin_get_from_name(struct pinctrl_dev *pctldev, const char *name);
pinctrl: move group lookup to core Now also the core needs to look up pin groups so move the lookup function there and expose it in the internal header. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 15:07:16 +00:00
int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
const char *pin_group);
pinctrl: remove pin and hogs locks from struct pinctrl_dev struct pinctrl_dev's pin_desc_tree_lock and pinctrl_hogs_lock aren't useful; the data they protect is read-only except when registering or unregistering a pinctrl_dev, and at those times, it doesn't make sense to protect one part of the structure independently from the rest. Move pinctrl_init_device_debugfs() to the end of pinctrl_register() so that debugfs can't access the struct pinctrl_dev until it's fully initialized, i.e. after the hogs are set up. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-02-22 21:26:01 +00:00
static inline struct pin_desc *pin_desc_get(struct pinctrl_dev *pctldev,
unsigned int pin)
{
return radix_tree_lookup(&pctldev->pin_desc_tree, pin);
}
pinctrl: fix and simplify locking There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
extern struct mutex pinctrl_mutex;
Reference in New Issue Copy Permalink