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 driver for the pin control subsystem
|
|
|
|
|
*
|
2012-02-09 18:47:48 +00:00
|
|
|
* Copyright (C) 2011-2012 ST-Ericsson SA
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
* Written on behalf of Linaro for ST-Ericsson
|
|
|
|
|
* Based on bits of regulator core, gpio core and clk core
|
|
|
|
|
*
|
|
|
|
|
* Author: Linus Walleij <linus.walleij@linaro.org>
|
|
|
|
|
*
|
2012-02-20 06:45:43 +00:00
|
|
|
* Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved.
|
|
|
|
|
*
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
* License terms: GNU General Public License (GPL) version 2
|
|
|
|
|
*/
|
|
|
|
|
#define pr_fmt(fmt) "pinctrl core: " fmt
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
2011-09-30 04:39:04 +00:00
|
|
|
#include <linux/export.h>
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/device.h>
|
|
|
|
|
#include <linux/slab.h>
|
|
|
|
|
#include <linux/err.h>
|
|
|
|
|
#include <linux/list.h>
|
|
|
|
|
#include <linux/sysfs.h>
|
|
|
|
|
#include <linux/debugfs.h>
|
|
|
|
|
#include <linux/seq_file.h>
|
2012-04-16 16:51:00 +00:00
|
|
|
#include <linux/pinctrl/consumer.h>
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
#include <linux/pinctrl/pinctrl.h>
|
|
|
|
|
#include <linux/pinctrl/machine.h>
|
|
|
|
|
#include "core.h"
|
2012-03-23 16:29:46 +00:00
|
|
|
#include "devicetree.h"
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
#include "pinmux.h"
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
#include "pinconf.h"
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
2012-02-20 06:45:43 +00:00
|
|
|
/**
|
|
|
|
|
* struct pinctrl_maps - a list item containing part of the mapping table
|
|
|
|
|
* @node: mapping table list node
|
|
|
|
|
* @maps: array of mapping table entries
|
|
|
|
|
* @num_maps: the number of entries in @maps
|
|
|
|
|
*/
|
|
|
|
|
struct pinctrl_maps {
|
|
|
|
|
struct list_head node;
|
|
|
|
|
struct pinctrl_map const *maps;
|
|
|
|
|
unsigned num_maps;
|
|
|
|
|
};
|
|
|
|
|
|
2012-04-26 08:15:50 +00:00
|
|
|
static bool pinctrl_dummy_state;
|
|
|
|
|
|
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
|
|
|
/* Mutex taken by all entry points */
|
|
|
|
|
DEFINE_MUTEX(pinctrl_mutex);
|
|
|
|
|
|
|
|
|
|
/* Global list of pin control devices (struct pinctrl_dev) */
|
2012-03-23 16:29:46 +00:00
|
|
|
LIST_HEAD(pinctrldev_list);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
pinctrl: 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
|
|
|
/* List of pin controller handles (struct pinctrl) */
|
2012-02-09 18:47:48 +00:00
|
|
|
static LIST_HEAD(pinctrl_list);
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
/* List of pinctrl maps (struct pinctrl_maps) */
|
2012-02-20 06:45:43 +00:00
|
|
|
static LIST_HEAD(pinctrl_maps);
|
|
|
|
|
|
|
|
|
|
#define for_each_maps(_maps_node_, _i_, _map_) \
|
|
|
|
|
list_for_each_entry(_maps_node_, &pinctrl_maps, node) \
|
|
|
|
|
for (_i_ = 0, _map_ = &_maps_node_->maps[_i_]; \
|
|
|
|
|
_i_ < _maps_node_->num_maps; \
|
2012-05-22 22:20:17 +00:00
|
|
|
_i_++, _map_ = &_maps_node_->maps[_i_])
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-04-26 08:15:50 +00:00
|
|
|
/**
|
|
|
|
|
* pinctrl_provide_dummies() - indicate if pinctrl provides dummy state support
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is called by platforms without pinctrl driver support
|
|
|
|
|
* but run with some shared drivers using pinctrl APIs.
|
|
|
|
|
* After calling this function, the pinctrl core will return successfully
|
|
|
|
|
* with creating a dummy state for the driver to keep going smoothly.
|
|
|
|
|
*/
|
|
|
|
|
void pinctrl_provide_dummies(void)
|
|
|
|
|
{
|
|
|
|
|
pinctrl_dummy_state = true;
|
|
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
const char *pinctrl_dev_get_name(struct pinctrl_dev *pctldev)
|
|
|
|
|
{
|
|
|
|
|
/* We're not allowed to register devices without name */
|
|
|
|
|
return pctldev->desc->name;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_dev_get_name);
|
|
|
|
|
|
|
|
|
|
void *pinctrl_dev_get_drvdata(struct pinctrl_dev *pctldev)
|
|
|
|
|
{
|
|
|
|
|
return pctldev->driver_data;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_dev_get_drvdata);
|
|
|
|
|
|
|
|
|
|
/**
|
2012-02-01 17:02:47 +00:00
|
|
|
* get_pinctrl_dev_from_devname() - look up pin controller device
|
|
|
|
|
* @devname: the name of a device instance, as returned by dev_name()
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
*
|
|
|
|
|
* Looks up a pin control device matching a certain device name or pure device
|
|
|
|
|
* pointer, the pure device pointer will take precedence.
|
|
|
|
|
*/
|
2012-02-01 17:02:47 +00:00
|
|
|
struct pinctrl_dev *get_pinctrl_dev_from_devname(const char *devname)
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev = NULL;
|
|
|
|
|
bool found = false;
|
|
|
|
|
|
2012-02-01 17:02:47 +00:00
|
|
|
if (!devname)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
list_for_each_entry(pctldev, &pinctrldev_list, node) {
|
2012-02-01 17:02:47 +00:00
|
|
|
if (!strcmp(dev_name(pctldev->dev), devname)) {
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
/* Matched on device name */
|
|
|
|
|
found = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return found ? pctldev : NULL;
|
|
|
|
|
}
|
|
|
|
|
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
/**
|
|
|
|
|
* pin_get_from_name() - look up a pin number from a name
|
|
|
|
|
* @pctldev: the pin control device to lookup the pin on
|
|
|
|
|
* @name: the name of the pin to look up
|
|
|
|
|
*/
|
|
|
|
|
int pin_get_from_name(struct pinctrl_dev *pctldev, const char *name)
|
|
|
|
|
{
|
2012-01-03 07:47:50 +00:00
|
|
|
unsigned i, pin;
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
|
2012-01-03 07:47:50 +00:00
|
|
|
/* The pin number can be retrived from the pin controller descriptor */
|
|
|
|
|
for (i = 0; i < pctldev->desc->npins; i++) {
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
struct pin_desc *desc;
|
|
|
|
|
|
2012-01-03 07:47:50 +00:00
|
|
|
pin = pctldev->desc->pins[i].number;
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
desc = pin_desc_get(pctldev, pin);
|
|
|
|
|
/* Pin space may be sparse */
|
|
|
|
|
if (desc == NULL)
|
|
|
|
|
continue;
|
|
|
|
|
if (desc->name && !strcmp(name, desc->name))
|
|
|
|
|
return pin;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-17 07:00:46 +00:00
|
|
|
/**
|
|
|
|
|
* pin_get_name_from_id() - look up a pin name from a pin id
|
|
|
|
|
* @pctldev: the pin control device to lookup the pin on
|
|
|
|
|
* @name: the name of the pin to look up
|
|
|
|
|
*/
|
|
|
|
|
const char *pin_get_name(struct pinctrl_dev *pctldev, const unsigned pin)
|
|
|
|
|
{
|
|
|
|
|
const struct pin_desc *desc;
|
|
|
|
|
|
|
|
|
|
desc = pin_desc_get(pctldev, pin);
|
|
|
|
|
if (desc == NULL) {
|
|
|
|
|
dev_err(pctldev->dev, "failed to get pin(%d) name\n",
|
|
|
|
|
pin);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return desc->name;
|
|
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
/**
|
|
|
|
|
* pin_is_valid() - check if pin exists on controller
|
|
|
|
|
* @pctldev: the pin control device to check the pin on
|
|
|
|
|
* @pin: pin to check, use the local pin controller index number
|
|
|
|
|
*
|
|
|
|
|
* This tells us whether a certain pin exist on a certain pin controller or
|
|
|
|
|
* not. Pin lists may be sparse, so some pins may not exist.
|
|
|
|
|
*/
|
|
|
|
|
bool pin_is_valid(struct pinctrl_dev *pctldev, int pin)
|
|
|
|
|
{
|
|
|
|
|
struct pin_desc *pindesc;
|
|
|
|
|
|
|
|
|
|
if (pin < 0)
|
|
|
|
|
return false;
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
pindesc = pin_desc_get(pctldev, pin);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_unlock(&pinctrl_mutex);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
return pindesc != NULL;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pin_is_valid);
|
|
|
|
|
|
|
|
|
|
/* Deletes a range of pin descriptors */
|
|
|
|
|
static void pinctrl_free_pindescs(struct pinctrl_dev *pctldev,
|
|
|
|
|
const struct pinctrl_pin_desc *pins,
|
|
|
|
|
unsigned num_pins)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < num_pins; i++) {
|
|
|
|
|
struct pin_desc *pindesc;
|
|
|
|
|
|
|
|
|
|
pindesc = radix_tree_lookup(&pctldev->pin_desc_tree,
|
|
|
|
|
pins[i].number);
|
|
|
|
|
if (pindesc != NULL) {
|
|
|
|
|
radix_tree_delete(&pctldev->pin_desc_tree,
|
|
|
|
|
pins[i].number);
|
2011-12-14 19:33:37 +00:00
|
|
|
if (pindesc->dynamic_name)
|
|
|
|
|
kfree(pindesc->name);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
kfree(pindesc);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pinctrl_register_one_pin(struct pinctrl_dev *pctldev,
|
|
|
|
|
unsigned number, const char *name)
|
|
|
|
|
{
|
|
|
|
|
struct pin_desc *pindesc;
|
|
|
|
|
|
|
|
|
|
pindesc = pin_desc_get(pctldev, number);
|
|
|
|
|
if (pindesc != NULL) {
|
|
|
|
|
pr_err("pin %d already registered on %s\n", number,
|
|
|
|
|
pctldev->desc->name);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pindesc = kzalloc(sizeof(*pindesc), GFP_KERNEL);
|
2012-02-22 21:25:59 +00:00
|
|
|
if (pindesc == NULL) {
|
|
|
|
|
dev_err(pctldev->dev, "failed to alloc struct pin_desc\n");
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
return -ENOMEM;
|
2012-02-22 21:25:59 +00:00
|
|
|
}
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
/* Set owner */
|
|
|
|
|
pindesc->pctldev = pctldev;
|
|
|
|
|
|
2011-10-19 22:19:27 +00:00
|
|
|
/* Copy basic pin info */
|
2012-02-01 17:11:40 +00:00
|
|
|
if (name) {
|
2011-12-14 19:33:37 +00:00
|
|
|
pindesc->name = name;
|
|
|
|
|
} else {
|
|
|
|
|
pindesc->name = kasprintf(GFP_KERNEL, "PIN%u", number);
|
2012-09-25 07:11:40 +00:00
|
|
|
if (pindesc->name == NULL) {
|
|
|
|
|
kfree(pindesc);
|
2011-12-14 19:33:37 +00:00
|
|
|
return -ENOMEM;
|
2012-09-25 07:11:40 +00:00
|
|
|
}
|
2011-12-14 19:33:37 +00:00
|
|
|
pindesc->dynamic_name = true;
|
|
|
|
|
}
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
|
|
|
|
radix_tree_insert(&pctldev->pin_desc_tree, number, pindesc);
|
|
|
|
|
pr_debug("registered pin %d (%s) on %s\n",
|
2011-12-14 19:33:37 +00:00
|
|
|
number, pindesc->name, pctldev->desc->name);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pinctrl_register_pins(struct pinctrl_dev *pctldev,
|
|
|
|
|
struct pinctrl_pin_desc const *pins,
|
|
|
|
|
unsigned num_descs)
|
|
|
|
|
{
|
|
|
|
|
unsigned i;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < num_descs; i++) {
|
|
|
|
|
ret = pinctrl_register_one_pin(pctldev,
|
|
|
|
|
pins[i].number, pins[i].name);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* pinctrl_match_gpio_range() - check if a certain GPIO pin is in range
|
|
|
|
|
* @pctldev: pin controller device to check
|
|
|
|
|
* @gpio: gpio pin to check taken from the global GPIO pin space
|
|
|
|
|
*
|
|
|
|
|
* Tries to match a GPIO pin number to the ranges handled by a certain pin
|
|
|
|
|
* controller, return the range or NULL
|
|
|
|
|
*/
|
|
|
|
|
static struct pinctrl_gpio_range *
|
|
|
|
|
pinctrl_match_gpio_range(struct pinctrl_dev *pctldev, unsigned gpio)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_gpio_range *range = NULL;
|
|
|
|
|
|
|
|
|
|
/* Loop over the ranges */
|
|
|
|
|
list_for_each_entry(range, &pctldev->gpio_ranges, node) {
|
|
|
|
|
/* Check if we're in the valid range */
|
|
|
|
|
if (gpio >= range->base &&
|
|
|
|
|
gpio < range->base + range->npins) {
|
|
|
|
|
return range;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* pinctrl_get_device_gpio_range() - find device for GPIO range
|
|
|
|
|
* @gpio: the pin to locate the pin controller for
|
|
|
|
|
* @outdev: the pin control device if found
|
|
|
|
|
* @outrange: the GPIO range if found
|
|
|
|
|
*
|
|
|
|
|
* Find the pin controller handling a certain GPIO pin from the pinspace of
|
|
|
|
|
* the GPIO subsystem, return the device and the matching GPIO range. Returns
|
2012-04-25 11:38:13 +00:00
|
|
|
* -EPROBE_DEFER if the GPIO range could not be found in any device since it
|
|
|
|
|
* may still have not been registered.
|
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
|
|
|
*/
|
2012-02-20 06:45:47 +00:00
|
|
|
static int pinctrl_get_device_gpio_range(unsigned gpio,
|
|
|
|
|
struct pinctrl_dev **outdev,
|
|
|
|
|
struct pinctrl_gpio_range **outrange)
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev = NULL;
|
|
|
|
|
|
|
|
|
|
/* Loop over the pin controllers */
|
|
|
|
|
list_for_each_entry(pctldev, &pinctrldev_list, node) {
|
|
|
|
|
struct pinctrl_gpio_range *range;
|
|
|
|
|
|
|
|
|
|
range = pinctrl_match_gpio_range(pctldev, gpio);
|
|
|
|
|
if (range != NULL) {
|
|
|
|
|
*outdev = pctldev;
|
|
|
|
|
*outrange = range;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-25 11:38:13 +00:00
|
|
|
return -EPROBE_DEFER;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* pinctrl_add_gpio_range() - register a GPIO range for a controller
|
|
|
|
|
* @pctldev: pin controller device to add the range to
|
|
|
|
|
* @range: the GPIO range to add
|
|
|
|
|
*
|
|
|
|
|
* This adds a range of GPIOs to be handled by a certain pin controller. Call
|
|
|
|
|
* this to register handled ranges after registering your pin controller.
|
|
|
|
|
*/
|
|
|
|
|
void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
|
|
|
|
|
struct pinctrl_gpio_range *range)
|
|
|
|
|
{
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
2012-02-20 06:45:42 +00:00
|
|
|
list_add_tail(&range->node, &pctldev->gpio_ranges);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_unlock(&pinctrl_mutex);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
2012-02-20 06:45:47 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_add_gpio_range);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
2012-05-23 13:22:41 +00:00
|
|
|
void pinctrl_add_gpio_ranges(struct pinctrl_dev *pctldev,
|
|
|
|
|
struct pinctrl_gpio_range *ranges,
|
|
|
|
|
unsigned nranges)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nranges; i++)
|
|
|
|
|
pinctrl_add_gpio_range(pctldev, &ranges[i]);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_add_gpio_ranges);
|
|
|
|
|
|
2012-11-20 13:03:37 +00:00
|
|
|
struct pinctrl_dev *pinctrl_find_and_add_gpio_range(const char *devname,
|
2012-10-27 09:51:36 +00:00
|
|
|
struct pinctrl_gpio_range *range)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev = get_pinctrl_dev_from_devname(devname);
|
|
|
|
|
|
2012-11-20 13:54:18 +00:00
|
|
|
/*
|
|
|
|
|
* If we can't find this device, let's assume that is because
|
|
|
|
|
* it has not probed yet, so the driver trying to register this
|
|
|
|
|
* range need to defer probing.
|
|
|
|
|
*/
|
2012-10-27 09:51:36 +00:00
|
|
|
if (!pctldev)
|
2012-11-20 13:54:18 +00:00
|
|
|
return ERR_PTR(-EPROBE_DEFER);
|
2012-10-27 09:51:36 +00:00
|
|
|
|
|
|
|
|
pinctrl_add_gpio_range(pctldev, range);
|
|
|
|
|
return pctldev;
|
|
|
|
|
}
|
2012-11-20 13:03:37 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_find_and_add_gpio_range);
|
2012-10-27 09:51:36 +00:00
|
|
|
|
2012-11-20 13:25:07 +00:00
|
|
|
/**
|
|
|
|
|
* pinctrl_find_gpio_range_from_pin() - locate the GPIO range for a pin
|
|
|
|
|
* @pctldev: the pin controller device to look in
|
|
|
|
|
* @pin: a controller-local number to find the range for
|
|
|
|
|
*/
|
|
|
|
|
struct pinctrl_gpio_range *
|
|
|
|
|
pinctrl_find_gpio_range_from_pin(struct pinctrl_dev *pctldev,
|
|
|
|
|
unsigned int pin)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_gpio_range *range = NULL;
|
|
|
|
|
|
|
|
|
|
/* Loop over the ranges */
|
|
|
|
|
list_for_each_entry(range, &pctldev->gpio_ranges, node) {
|
|
|
|
|
/* Check if we're in the valid range */
|
|
|
|
|
if (pin >= range->pin_base &&
|
|
|
|
|
pin < range->pin_base + range->npins) {
|
|
|
|
|
return range;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_find_gpio_range_from_pin);
|
|
|
|
|
|
2012-10-27 09:51:35 +00:00
|
|
|
/**
|
|
|
|
|
* pinctrl_remove_gpio_range() - remove a range of GPIOs fro a pin controller
|
|
|
|
|
* @pctldev: pin controller device to remove the range from
|
|
|
|
|
* @range: the GPIO range to remove
|
|
|
|
|
*/
|
|
|
|
|
void pinctrl_remove_gpio_range(struct pinctrl_dev *pctldev,
|
|
|
|
|
struct pinctrl_gpio_range *range)
|
|
|
|
|
{
|
|
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
list_del(&range->node);
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_remove_gpio_range);
|
|
|
|
|
|
2011-10-19 15:07:16 +00:00
|
|
|
/**
|
|
|
|
|
* pinctrl_get_group_selector() - returns the group selector for a group
|
|
|
|
|
* @pctldev: the pin controller handling the group
|
|
|
|
|
* @pin_group: the pin group to look up
|
|
|
|
|
*/
|
|
|
|
|
int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
|
|
|
|
|
const char *pin_group)
|
|
|
|
|
{
|
|
|
|
|
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
|
2012-03-30 05:55:40 +00:00
|
|
|
unsigned ngroups = pctlops->get_groups_count(pctldev);
|
2011-10-19 15:07:16 +00:00
|
|
|
unsigned group_selector = 0;
|
|
|
|
|
|
2012-03-30 05:55:40 +00:00
|
|
|
while (group_selector < ngroups) {
|
2011-10-19 15:07:16 +00:00
|
|
|
const char *gname = pctlops->get_group_name(pctldev,
|
|
|
|
|
group_selector);
|
|
|
|
|
if (!strcmp(gname, pin_group)) {
|
2011-12-09 23:59:05 +00:00
|
|
|
dev_dbg(pctldev->dev,
|
2011-10-19 15:07:16 +00:00
|
|
|
"found group selector %u for %s\n",
|
|
|
|
|
group_selector,
|
|
|
|
|
pin_group);
|
|
|
|
|
return group_selector;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
group_selector++;
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-09 23:59:05 +00:00
|
|
|
dev_err(pctldev->dev, "does not have pin group %s\n",
|
2011-10-19 15:07:16 +00:00
|
|
|
pin_group);
|
|
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
/**
|
|
|
|
|
* pinctrl_request_gpio() - request a single pin to be used in as GPIO
|
|
|
|
|
* @gpio: the GPIO pin number from the GPIO subsystem number space
|
|
|
|
|
*
|
|
|
|
|
* This function should *ONLY* be used from gpiolib-based GPIO drivers,
|
|
|
|
|
* as part of their gpio_request() semantics, platforms and individual drivers
|
|
|
|
|
* shall *NOT* request GPIO pins to be muxed in.
|
|
|
|
|
*/
|
|
|
|
|
int pinctrl_request_gpio(unsigned gpio)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev;
|
|
|
|
|
struct pinctrl_gpio_range *range;
|
|
|
|
|
int ret;
|
|
|
|
|
int pin;
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
if (ret) {
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-04-25 11:38:13 +00:00
|
|
|
return ret;
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
|
|
|
|
|
/* Convert to the pin controllers number space */
|
|
|
|
|
pin = gpio - range->base + range->pin_base;
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
ret = pinmux_request_gpio(pctldev, range, pin, gpio);
|
|
|
|
|
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
|
|
|
|
return ret;
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_request_gpio);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* pinctrl_free_gpio() - free control on a single pin, currently used as GPIO
|
|
|
|
|
* @gpio: the GPIO pin number from the GPIO subsystem number space
|
|
|
|
|
*
|
|
|
|
|
* This function should *ONLY* be used from gpiolib-based GPIO drivers,
|
|
|
|
|
* as part of their gpio_free() semantics, platforms and individual drivers
|
|
|
|
|
* shall *NOT* request GPIO pins to be muxed out.
|
|
|
|
|
*/
|
|
|
|
|
void pinctrl_free_gpio(unsigned gpio)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev;
|
|
|
|
|
struct pinctrl_gpio_range *range;
|
|
|
|
|
int ret;
|
|
|
|
|
int pin;
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
if (ret) {
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-02-09 18:47:48 +00:00
|
|
|
return;
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
|
|
|
|
|
/* Convert to the pin controllers number space */
|
|
|
|
|
pin = gpio - range->base + range->pin_base;
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
pinmux_free_gpio(pctldev, pin, range);
|
|
|
|
|
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_free_gpio);
|
|
|
|
|
|
|
|
|
|
static int pinctrl_gpio_direction(unsigned gpio, bool input)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev;
|
|
|
|
|
struct pinctrl_gpio_range *range;
|
|
|
|
|
int ret;
|
|
|
|
|
int pin;
|
|
|
|
|
|
|
|
|
|
ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
/* Convert to the pin controllers number space */
|
|
|
|
|
pin = gpio - range->base + range->pin_base;
|
|
|
|
|
|
|
|
|
|
return pinmux_gpio_direction(pctldev, range, pin, input);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* pinctrl_gpio_direction_input() - request a GPIO pin to go into input mode
|
|
|
|
|
* @gpio: the GPIO pin number from the GPIO subsystem number space
|
|
|
|
|
*
|
|
|
|
|
* This function should *ONLY* be used from gpiolib-based GPIO drivers,
|
|
|
|
|
* as part of their gpio_direction_input() semantics, platforms and individual
|
|
|
|
|
* drivers shall *NOT* touch pin control GPIO calls.
|
|
|
|
|
*/
|
|
|
|
|
int pinctrl_gpio_direction_input(unsigned gpio)
|
|
|
|
|
{
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
int ret;
|
|
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
ret = pinctrl_gpio_direction(gpio, true);
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
|
|
|
|
return ret;
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_input);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* pinctrl_gpio_direction_output() - request a GPIO pin to go into output mode
|
|
|
|
|
* @gpio: the GPIO pin number from the GPIO subsystem number space
|
|
|
|
|
*
|
|
|
|
|
* This function should *ONLY* be used from gpiolib-based GPIO drivers,
|
|
|
|
|
* as part of their gpio_direction_output() semantics, platforms and individual
|
|
|
|
|
* drivers shall *NOT* touch pin control GPIO calls.
|
|
|
|
|
*/
|
|
|
|
|
int pinctrl_gpio_direction_output(unsigned gpio)
|
|
|
|
|
{
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
int ret;
|
|
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
ret = pinctrl_gpio_direction(gpio, false);
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
|
|
|
|
return ret;
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_output);
|
|
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
static struct pinctrl_state *find_state(struct pinctrl *p,
|
|
|
|
|
const char *name)
|
2012-02-09 18:47:48 +00:00
|
|
|
{
|
2012-03-02 20:05:47 +00:00
|
|
|
struct pinctrl_state *state;
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(state, &p->states, node)
|
|
|
|
|
if (!strcmp(state->name, name))
|
|
|
|
|
return state;
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct pinctrl_state *create_state(struct pinctrl *p,
|
|
|
|
|
const char *name)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_state *state;
|
|
|
|
|
|
|
|
|
|
state = kzalloc(sizeof(*state), GFP_KERNEL);
|
|
|
|
|
if (state == NULL) {
|
|
|
|
|
dev_err(p->dev,
|
|
|
|
|
"failed to alloc struct pinctrl_state\n");
|
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
state->name = name;
|
|
|
|
|
INIT_LIST_HEAD(&state->settings);
|
|
|
|
|
|
|
|
|
|
list_add_tail(&state->node, &p->states);
|
|
|
|
|
|
|
|
|
|
return state;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_state *state;
|
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 pinctrl_setting *setting;
|
2012-03-02 20:05:47 +00:00
|
|
|
int ret;
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
state = find_state(p, map->name);
|
|
|
|
|
if (!state)
|
|
|
|
|
state = create_state(p, map->name);
|
|
|
|
|
if (IS_ERR(state))
|
|
|
|
|
return PTR_ERR(state);
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-03-02 20:05:48 +00:00
|
|
|
if (map->type == PIN_MAP_TYPE_DUMMY_STATE)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
setting = kzalloc(sizeof(*setting), GFP_KERNEL);
|
|
|
|
|
if (setting == NULL) {
|
|
|
|
|
dev_err(p->dev,
|
|
|
|
|
"failed to alloc struct pinctrl_setting\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-03-02 20:05:48 +00:00
|
|
|
setting->type = map->type;
|
|
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
setting->pctldev = get_pinctrl_dev_from_devname(map->ctrl_dev_name);
|
|
|
|
|
if (setting->pctldev == NULL) {
|
2012-04-10 08:00:38 +00:00
|
|
|
dev_info(p->dev, "unknown pinctrl device %s in map entry, deferring probe",
|
2012-03-02 20:05:47 +00:00
|
|
|
map->ctrl_dev_name);
|
|
|
|
|
kfree(setting);
|
2012-04-10 08:00:38 +00:00
|
|
|
/*
|
|
|
|
|
* OK let us guess that the driver is not there yet, and
|
|
|
|
|
* let's defer obtaining this pinctrl handle to later...
|
|
|
|
|
*/
|
|
|
|
|
return -EPROBE_DEFER;
|
2012-03-02 20:05:47 +00:00
|
|
|
}
|
|
|
|
|
|
2012-10-17 18:51:54 +00:00
|
|
|
setting->dev_name = map->dev_name;
|
|
|
|
|
|
2012-03-02 20:05:48 +00:00
|
|
|
switch (map->type) {
|
|
|
|
|
case PIN_MAP_TYPE_MUX_GROUP:
|
|
|
|
|
ret = pinmux_map_to_setting(map, setting);
|
|
|
|
|
break;
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_PIN:
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_GROUP:
|
|
|
|
|
ret = pinconf_map_to_setting(map, setting);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
if (ret < 0) {
|
|
|
|
|
kfree(setting);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
list_add_tail(&setting->node, &state->settings);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct pinctrl *find_pinctrl(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl *p;
|
|
|
|
|
|
2012-03-02 20:05:48 +00:00
|
|
|
list_for_each_entry(p, &pinctrl_list, node)
|
2012-03-02 20:05:47 +00:00
|
|
|
if (p->dev == dev)
|
|
|
|
|
return p;
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void pinctrl_put_locked(struct pinctrl *p, bool inlist);
|
|
|
|
|
|
|
|
|
|
static struct pinctrl *create_pinctrl(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl *p;
|
|
|
|
|
const char *devname;
|
|
|
|
|
struct pinctrl_maps *maps_node;
|
|
|
|
|
int i;
|
|
|
|
|
struct pinctrl_map const *map;
|
|
|
|
|
int ret;
|
2012-02-09 18:47:48 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* create the state cookie holder struct pinctrl for each
|
|
|
|
|
* mapping, this is what consumers will get when requesting
|
|
|
|
|
* a pin control handle with pinctrl_get()
|
|
|
|
|
*/
|
2012-02-22 21:26:00 +00:00
|
|
|
p = kzalloc(sizeof(*p), GFP_KERNEL);
|
2012-02-22 21:25:59 +00:00
|
|
|
if (p == NULL) {
|
|
|
|
|
dev_err(dev, "failed to alloc struct pinctrl\n");
|
2012-02-09 18:47:48 +00:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2012-02-22 21:25:59 +00:00
|
|
|
}
|
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
|
|
|
p->dev = dev;
|
2012-03-02 20:05:47 +00:00
|
|
|
INIT_LIST_HEAD(&p->states);
|
2012-03-23 16:29:46 +00:00
|
|
|
INIT_LIST_HEAD(&p->dt_maps);
|
|
|
|
|
|
|
|
|
|
ret = pinctrl_dt_to_map(p);
|
|
|
|
|
if (ret < 0) {
|
|
|
|
|
kfree(p);
|
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
|
|
|
|
|
devname = dev_name(dev);
|
2012-02-09 18:47:48 +00:00
|
|
|
|
|
|
|
|
/* Iterate over the pin control maps to locate the right ones */
|
2012-02-20 06:45:43 +00:00
|
|
|
for_each_maps(maps_node, i, map) {
|
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
|
|
|
/* Map must be for this device */
|
|
|
|
|
if (strcmp(map->dev_name, devname))
|
|
|
|
|
continue;
|
|
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
ret = add_setting(p, map);
|
|
|
|
|
if (ret < 0) {
|
|
|
|
|
pinctrl_put_locked(p, false);
|
|
|
|
|
return ERR_PTR(ret);
|
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
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
|
2012-12-11 12:12:35 +00:00
|
|
|
/* Add the pinctrl handle to the global list */
|
2012-02-20 06:45:42 +00:00
|
|
|
list_add_tail(&p->node, &pinctrl_list);
|
2012-02-09 18:47:48 +00:00
|
|
|
|
|
|
|
|
return p;
|
2012-03-02 20:05:47 +00:00
|
|
|
}
|
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
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
static struct pinctrl *pinctrl_get_locked(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl *p;
|
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
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
if (WARN_ON(!dev))
|
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
|
|
p = find_pinctrl(dev);
|
|
|
|
|
if (p != NULL)
|
|
|
|
|
return ERR_PTR(-EBUSY);
|
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
|
|
|
|
2012-08-10 14:53:49 +00:00
|
|
|
return create_pinctrl(dev);
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
2012-02-20 06:45:43 +00:00
|
|
|
|
|
|
|
|
/**
|
2012-03-02 20:05:47 +00:00
|
|
|
* pinctrl_get() - retrieves the pinctrl handle for a device
|
|
|
|
|
* @dev: the device to obtain the handle for
|
2012-02-20 06:45:43 +00:00
|
|
|
*/
|
2012-03-02 20:05:47 +00:00
|
|
|
struct pinctrl *pinctrl_get(struct device *dev)
|
2012-02-20 06:45:43 +00:00
|
|
|
{
|
|
|
|
|
struct pinctrl *p;
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
2012-03-02 20:05:47 +00:00
|
|
|
p = pinctrl_get_locked(dev);
|
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
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-02-20 06:45:43 +00:00
|
|
|
|
|
|
|
|
return p;
|
|
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_get);
|
|
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
static void pinctrl_put_locked(struct pinctrl *p, bool inlist)
|
2012-02-09 18:47:48 +00:00
|
|
|
{
|
2012-03-02 20:05:47 +00:00
|
|
|
struct pinctrl_state *state, *n1;
|
|
|
|
|
struct pinctrl_setting *setting, *n2;
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe(state, n1, &p->states, node) {
|
|
|
|
|
list_for_each_entry_safe(setting, n2, &state->settings, node) {
|
2012-03-02 20:05:48 +00:00
|
|
|
switch (setting->type) {
|
|
|
|
|
case PIN_MAP_TYPE_MUX_GROUP:
|
|
|
|
|
if (state == p->state)
|
|
|
|
|
pinmux_disable_setting(setting);
|
|
|
|
|
pinmux_free_setting(setting);
|
|
|
|
|
break;
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_PIN:
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_GROUP:
|
|
|
|
|
pinconf_free_setting(setting);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
list_del(&setting->node);
|
|
|
|
|
kfree(setting);
|
|
|
|
|
}
|
|
|
|
|
list_del(&state->node);
|
|
|
|
|
kfree(state);
|
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
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-03-23 16:29:46 +00:00
|
|
|
pinctrl_dt_free_maps(p);
|
|
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
if (inlist)
|
|
|
|
|
list_del(&p->node);
|
2012-02-09 18:47:48 +00:00
|
|
|
kfree(p);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2012-03-02 20:05:47 +00:00
|
|
|
* pinctrl_put() - release a previously claimed pinctrl handle
|
|
|
|
|
* @p: the pinctrl handle to release
|
2012-02-09 18:47:48 +00:00
|
|
|
*/
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
void pinctrl_put(struct pinctrl *p)
|
|
|
|
|
{
|
|
|
|
|
mutex_lock(&pinctrl_mutex);
|
2012-03-02 20:05:47 +00:00
|
|
|
pinctrl_put_locked(p, true);
|
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
|
|
|
mutex_unlock(&pinctrl_mutex);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_put);
|
|
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
static struct pinctrl_state *pinctrl_lookup_state_locked(struct pinctrl *p,
|
|
|
|
|
const char *name)
|
2012-02-09 18:47:48 +00:00
|
|
|
{
|
2012-03-02 20:05:47 +00:00
|
|
|
struct pinctrl_state *state;
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
state = find_state(p, name);
|
2012-04-26 08:15:50 +00:00
|
|
|
if (!state) {
|
|
|
|
|
if (pinctrl_dummy_state) {
|
|
|
|
|
/* create dummy state */
|
|
|
|
|
dev_dbg(p->dev, "using pinctrl dummy state (%s)\n",
|
|
|
|
|
name);
|
|
|
|
|
state = create_state(p, name);
|
2012-08-10 14:53:49 +00:00
|
|
|
} else
|
|
|
|
|
state = ERR_PTR(-ENODEV);
|
2012-04-26 08:15:50 +00:00
|
|
|
}
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
return state;
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2012-03-02 20:05:47 +00:00
|
|
|
* pinctrl_lookup_state() - retrieves a state handle from a pinctrl handle
|
|
|
|
|
* @p: the pinctrl handle to retrieve the state from
|
|
|
|
|
* @name: the state name to retrieve
|
2012-02-09 18:47:48 +00:00
|
|
|
*/
|
2012-03-02 20:05:47 +00:00
|
|
|
struct pinctrl_state *pinctrl_lookup_state(struct pinctrl *p, const char *name)
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
{
|
2012-03-02 20:05:47 +00:00
|
|
|
struct pinctrl_state *s;
|
|
|
|
|
|
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
|
|
|
mutex_lock(&pinctrl_mutex);
|
2012-03-02 20:05:47 +00:00
|
|
|
s = pinctrl_lookup_state_locked(p, name);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-03-02 20:05:47 +00:00
|
|
|
|
|
|
|
|
return s;
|
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
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
|
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
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
static int pinctrl_select_state_locked(struct pinctrl *p,
|
|
|
|
|
struct pinctrl_state *state)
|
2012-02-09 18:47:48 +00:00
|
|
|
{
|
2012-03-02 20:05:47 +00:00
|
|
|
struct pinctrl_setting *setting, *setting2;
|
|
|
|
|
int ret;
|
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
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
if (p->state == state)
|
|
|
|
|
return 0;
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
if (p->state) {
|
|
|
|
|
/*
|
|
|
|
|
* The set of groups with a mux configuration in the old state
|
|
|
|
|
* may not be identical to the set of groups with a mux setting
|
|
|
|
|
* in the new state. While this might be unusual, it's entirely
|
|
|
|
|
* possible for the "user"-supplied mapping table to be written
|
|
|
|
|
* that way. For each group that was configured in the old state
|
|
|
|
|
* but not in the new state, this code puts that group into a
|
|
|
|
|
* safe/disabled state.
|
|
|
|
|
*/
|
|
|
|
|
list_for_each_entry(setting, &p->state->settings, node) {
|
|
|
|
|
bool found = false;
|
2012-03-02 20:05:48 +00:00
|
|
|
if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
|
|
|
|
|
continue;
|
2012-03-02 20:05:47 +00:00
|
|
|
list_for_each_entry(setting2, &state->settings, node) {
|
2012-03-02 20:05:48 +00:00
|
|
|
if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
|
|
|
|
|
continue;
|
|
|
|
|
if (setting2->data.mux.group ==
|
|
|
|
|
setting->data.mux.group) {
|
2012-03-02 20:05:47 +00:00
|
|
|
found = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (!found)
|
|
|
|
|
pinmux_disable_setting(setting);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
p->state = state;
|
|
|
|
|
|
|
|
|
|
/* Apply all the settings for the new state */
|
|
|
|
|
list_for_each_entry(setting, &state->settings, node) {
|
2012-03-02 20:05:48 +00:00
|
|
|
switch (setting->type) {
|
|
|
|
|
case PIN_MAP_TYPE_MUX_GROUP:
|
|
|
|
|
ret = pinmux_enable_setting(setting);
|
|
|
|
|
break;
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_PIN:
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_GROUP:
|
|
|
|
|
ret = pinconf_apply_setting(setting);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
if (ret < 0) {
|
|
|
|
|
/* FIXME: Difficult to return to prev state */
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
|
|
|
|
|
return 0;
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2012-03-02 20:05:47 +00:00
|
|
|
* pinctrl_select() - select/activate/program a pinctrl state to HW
|
|
|
|
|
* @p: the pinctrl handle for the device that requests configuratio
|
|
|
|
|
* @state: the state handle to select/activate/program
|
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
|
|
|
*/
|
2012-03-02 20:05:47 +00:00
|
|
|
int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
|
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
|
|
|
{
|
2012-03-02 20:05:47 +00:00
|
|
|
int ret;
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
2012-03-02 20:05:47 +00:00
|
|
|
ret = pinctrl_select_state_locked(p, state);
|
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
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-03-02 20:05:47 +00:00
|
|
|
|
|
|
|
|
return ret;
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_select_state);
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-04-16 16:51:00 +00:00
|
|
|
static void devm_pinctrl_release(struct device *dev, void *res)
|
|
|
|
|
{
|
|
|
|
|
pinctrl_put(*(struct pinctrl **)res);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* struct devm_pinctrl_get() - Resource managed pinctrl_get()
|
|
|
|
|
* @dev: the device to obtain the handle for
|
|
|
|
|
*
|
|
|
|
|
* If there is a need to explicitly destroy the returned struct pinctrl,
|
|
|
|
|
* devm_pinctrl_put() should be used, rather than plain pinctrl_put().
|
|
|
|
|
*/
|
|
|
|
|
struct pinctrl *devm_pinctrl_get(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl **ptr, *p;
|
|
|
|
|
|
|
|
|
|
ptr = devres_alloc(devm_pinctrl_release, sizeof(*ptr), GFP_KERNEL);
|
|
|
|
|
if (!ptr)
|
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
|
|
p = pinctrl_get(dev);
|
|
|
|
|
if (!IS_ERR(p)) {
|
|
|
|
|
*ptr = p;
|
|
|
|
|
devres_add(dev, ptr);
|
|
|
|
|
} else {
|
|
|
|
|
devres_free(ptr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return p;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(devm_pinctrl_get);
|
|
|
|
|
|
|
|
|
|
static int devm_pinctrl_match(struct device *dev, void *res, void *data)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl **p = res;
|
|
|
|
|
|
|
|
|
|
return *p == data;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* devm_pinctrl_put() - Resource managed pinctrl_put()
|
|
|
|
|
* @p: the pinctrl handle to release
|
|
|
|
|
*
|
|
|
|
|
* Deallocate a struct pinctrl obtained via devm_pinctrl_get(). Normally
|
|
|
|
|
* this function will not need to be called and the resource management
|
|
|
|
|
* code will ensure that the resource is freed.
|
|
|
|
|
*/
|
|
|
|
|
void devm_pinctrl_put(struct pinctrl *p)
|
|
|
|
|
{
|
|
|
|
|
WARN_ON(devres_destroy(p->dev, devm_pinctrl_release,
|
|
|
|
|
devm_pinctrl_match, p));
|
|
|
|
|
pinctrl_put(p);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(devm_pinctrl_put);
|
|
|
|
|
|
2012-03-23 16:29:46 +00:00
|
|
|
int pinctrl_register_map(struct pinctrl_map const *maps, unsigned num_maps,
|
|
|
|
|
bool dup, bool locked)
|
2012-02-09 18:47:48 +00:00
|
|
|
{
|
2012-03-02 20:05:48 +00:00
|
|
|
int i, ret;
|
2012-02-20 06:45:43 +00:00
|
|
|
struct pinctrl_maps *maps_node;
|
2012-02-09 18:47:48 +00:00
|
|
|
|
|
|
|
|
pr_debug("add %d pinmux maps\n", num_maps);
|
|
|
|
|
|
|
|
|
|
/* First sanity check the new mapping */
|
|
|
|
|
for (i = 0; i < num_maps; i++) {
|
2012-03-02 20:05:48 +00:00
|
|
|
if (!maps[i].dev_name) {
|
|
|
|
|
pr_err("failed to register map %s (%d): no device given\n",
|
|
|
|
|
maps[i].name, i);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
if (!maps[i].name) {
|
|
|
|
|
pr_err("failed to register map %d: no map name given\n",
|
2012-02-22 21:25:59 +00:00
|
|
|
i);
|
2012-02-09 18:47:48 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-02 20:05:48 +00:00
|
|
|
if (maps[i].type != PIN_MAP_TYPE_DUMMY_STATE &&
|
|
|
|
|
!maps[i].ctrl_dev_name) {
|
2012-02-09 18:47:48 +00:00
|
|
|
pr_err("failed to register map %s (%d): no pin control device given\n",
|
|
|
|
|
maps[i].name, i);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-02 20:05:48 +00:00
|
|
|
switch (maps[i].type) {
|
|
|
|
|
case PIN_MAP_TYPE_DUMMY_STATE:
|
|
|
|
|
break;
|
|
|
|
|
case PIN_MAP_TYPE_MUX_GROUP:
|
|
|
|
|
ret = pinmux_validate_map(&maps[i], i);
|
|
|
|
|
if (ret < 0)
|
2012-04-25 16:32:16 +00:00
|
|
|
return ret;
|
2012-03-02 20:05:48 +00:00
|
|
|
break;
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_PIN:
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_GROUP:
|
|
|
|
|
ret = pinconf_validate_map(&maps[i], i);
|
|
|
|
|
if (ret < 0)
|
2012-04-25 16:32:16 +00:00
|
|
|
return ret;
|
2012-03-02 20:05:48 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
pr_err("failed to register map %s (%d): invalid type given\n",
|
2012-02-22 21:25:59 +00:00
|
|
|
maps[i].name, i);
|
2012-02-22 21:25:58 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
|
2012-02-20 06:45:43 +00:00
|
|
|
maps_node = kzalloc(sizeof(*maps_node), GFP_KERNEL);
|
|
|
|
|
if (!maps_node) {
|
|
|
|
|
pr_err("failed to alloc struct pinctrl_maps\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-02-20 06:45:43 +00:00
|
|
|
maps_node->num_maps = num_maps;
|
2012-03-23 16:29:46 +00:00
|
|
|
if (dup) {
|
|
|
|
|
maps_node->maps = kmemdup(maps, sizeof(*maps) * num_maps,
|
|
|
|
|
GFP_KERNEL);
|
|
|
|
|
if (!maps_node->maps) {
|
|
|
|
|
pr_err("failed to duplicate mapping table\n");
|
|
|
|
|
kfree(maps_node);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
maps_node->maps = maps;
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
|
2012-03-23 16:29:46 +00:00
|
|
|
if (!locked)
|
|
|
|
|
mutex_lock(&pinctrl_mutex);
|
2012-02-20 06:45:43 +00:00
|
|
|
list_add_tail(&maps_node->node, &pinctrl_maps);
|
2012-03-23 16:29:46 +00:00
|
|
|
if (!locked)
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-02-20 06:45:43 +00:00
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-23 16:29:46 +00:00
|
|
|
/**
|
|
|
|
|
* pinctrl_register_mappings() - register a set of pin controller mappings
|
|
|
|
|
* @maps: the pincontrol mappings table to register. This should probably be
|
|
|
|
|
* marked with __initdata so it can be discarded after boot. This
|
|
|
|
|
* function will perform a shallow copy for the mapping entries.
|
|
|
|
|
* @num_maps: the number of maps in the mapping table
|
|
|
|
|
*/
|
|
|
|
|
int pinctrl_register_mappings(struct pinctrl_map const *maps,
|
|
|
|
|
unsigned num_maps)
|
|
|
|
|
{
|
|
|
|
|
return pinctrl_register_map(maps, num_maps, true, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void pinctrl_unregister_map(struct pinctrl_map const *map)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_maps *maps_node;
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(maps_node, &pinctrl_maps, node) {
|
|
|
|
|
if (maps_node->maps == map) {
|
|
|
|
|
list_del(&maps_node->node);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
|
|
|
|
|
|
static int pinctrl_pins_show(struct seq_file *s, void *what)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev = s->private;
|
|
|
|
|
const struct pinctrl_ops *ops = pctldev->desc->pctlops;
|
2012-01-03 07:47:50 +00:00
|
|
|
unsigned i, pin;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
|
|
|
|
seq_printf(s, "registered pins: %d\n", pctldev->desc->npins);
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
2012-01-03 07:47:50 +00:00
|
|
|
/* The pin number can be retrived from the pin controller descriptor */
|
|
|
|
|
for (i = 0; i < pctldev->desc->npins; i++) {
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
struct pin_desc *desc;
|
|
|
|
|
|
2012-01-03 07:47:50 +00:00
|
|
|
pin = pctldev->desc->pins[i].number;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
desc = pin_desc_get(pctldev, pin);
|
|
|
|
|
/* Pin space may be sparse */
|
|
|
|
|
if (desc == NULL)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
seq_printf(s, "pin %d (%s) ", pin,
|
|
|
|
|
desc->name ? desc->name : "unnamed");
|
|
|
|
|
|
|
|
|
|
/* Driver-specific info per pin */
|
|
|
|
|
if (ops->pin_dbg_show)
|
|
|
|
|
ops->pin_dbg_show(pctldev, s, pin);
|
|
|
|
|
|
|
|
|
|
seq_puts(s, "\n");
|
|
|
|
|
}
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_unlock(&pinctrl_mutex);
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pinctrl_groups_show(struct seq_file *s, void *what)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev = s->private;
|
|
|
|
|
const struct pinctrl_ops *ops = pctldev->desc->pctlops;
|
2012-03-30 05:55:40 +00:00
|
|
|
unsigned ngroups, selector = 0;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
2012-03-30 05:55:40 +00:00
|
|
|
ngroups = ops->get_groups_count(pctldev);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
seq_puts(s, "registered pin groups:\n");
|
2012-03-30 05:55:40 +00:00
|
|
|
while (selector < ngroups) {
|
2011-10-19 22:19:25 +00:00
|
|
|
const unsigned *pins;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
unsigned num_pins;
|
|
|
|
|
const char *gname = ops->get_group_name(pctldev, selector);
|
2012-04-17 07:00:46 +00:00
|
|
|
const char *pname;
|
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
|
|
|
int ret;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
ret = ops->get_group_pins(pctldev, selector,
|
|
|
|
|
&pins, &num_pins);
|
|
|
|
|
if (ret)
|
|
|
|
|
seq_printf(s, "%s [ERROR GETTING PINS]\n",
|
|
|
|
|
gname);
|
|
|
|
|
else {
|
2012-04-17 07:00:46 +00:00
|
|
|
seq_printf(s, "group: %s\n", gname);
|
|
|
|
|
for (i = 0; i < num_pins; i++) {
|
|
|
|
|
pname = pin_get_name(pctldev, pins[i]);
|
2012-10-22 04:58:09 +00:00
|
|
|
if (WARN_ON(!pname)) {
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-04-17 07:00:46 +00:00
|
|
|
return -EINVAL;
|
2012-10-22 04:58:09 +00:00
|
|
|
}
|
2012-04-17 07:00:46 +00:00
|
|
|
seq_printf(s, "pin %d (%s)\n", pins[i], pname);
|
|
|
|
|
}
|
|
|
|
|
seq_puts(s, "\n");
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
selector++;
|
|
|
|
|
}
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_unlock(&pinctrl_mutex);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pinctrl_gpioranges_show(struct seq_file *s, void *what)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev = s->private;
|
|
|
|
|
struct pinctrl_gpio_range *range = NULL;
|
|
|
|
|
|
|
|
|
|
seq_puts(s, "GPIO ranges handled:\n");
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
/* Loop over the ranges */
|
|
|
|
|
list_for_each_entry(range, &pctldev->gpio_ranges, node) {
|
2011-11-16 08:58:51 +00:00
|
|
|
seq_printf(s, "%u: %s GPIOS [%u - %u] PINS [%u - %u]\n",
|
|
|
|
|
range->id, range->name,
|
|
|
|
|
range->base, (range->base + range->npins - 1),
|
|
|
|
|
range->pin_base,
|
|
|
|
|
(range->pin_base + range->npins - 1));
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pinctrl_devices_show(struct seq_file *s, void *what)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev;
|
|
|
|
|
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
seq_puts(s, "name [pinmux] [pinconf]\n");
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
|
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
list_for_each_entry(pctldev, &pinctrldev_list, node) {
|
|
|
|
|
seq_printf(s, "%s ", pctldev->desc->name);
|
|
|
|
|
if (pctldev->desc->pmxops)
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
seq_puts(s, "yes ");
|
|
|
|
|
else
|
|
|
|
|
seq_puts(s, "no ");
|
|
|
|
|
if (pctldev->desc->confops)
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
seq_puts(s, "yes");
|
|
|
|
|
else
|
|
|
|
|
seq_puts(s, "no");
|
|
|
|
|
seq_puts(s, "\n");
|
|
|
|
|
}
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-02 20:05:48 +00:00
|
|
|
static inline const char *map_type(enum pinctrl_map_type type)
|
|
|
|
|
{
|
|
|
|
|
static const char * const names[] = {
|
|
|
|
|
"INVALID",
|
|
|
|
|
"DUMMY_STATE",
|
|
|
|
|
"MUX_GROUP",
|
|
|
|
|
"CONFIGS_PIN",
|
|
|
|
|
"CONFIGS_GROUP",
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
if (type >= ARRAY_SIZE(names))
|
|
|
|
|
return "UNKNOWN";
|
|
|
|
|
|
|
|
|
|
return names[type];
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-24 00:04:40 +00:00
|
|
|
static int pinctrl_maps_show(struct seq_file *s, void *what)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_maps *maps_node;
|
|
|
|
|
int i;
|
|
|
|
|
struct pinctrl_map const *map;
|
|
|
|
|
|
|
|
|
|
seq_puts(s, "Pinctrl maps:\n");
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
2012-02-24 00:04:40 +00:00
|
|
|
for_each_maps(maps_node, i, map) {
|
2012-03-02 20:05:48 +00:00
|
|
|
seq_printf(s, "device %s\nstate %s\ntype %s (%d)\n",
|
|
|
|
|
map->dev_name, map->name, map_type(map->type),
|
|
|
|
|
map->type);
|
|
|
|
|
|
|
|
|
|
if (map->type != PIN_MAP_TYPE_DUMMY_STATE)
|
|
|
|
|
seq_printf(s, "controlling device %s\n",
|
|
|
|
|
map->ctrl_dev_name);
|
|
|
|
|
|
|
|
|
|
switch (map->type) {
|
|
|
|
|
case PIN_MAP_TYPE_MUX_GROUP:
|
|
|
|
|
pinmux_show_map(s, map);
|
|
|
|
|
break;
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_PIN:
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_GROUP:
|
|
|
|
|
pinconf_show_map(s, map);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
seq_printf(s, "\n");
|
2012-02-24 00:04:40 +00:00
|
|
|
}
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
2012-02-24 00:04:40 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
static int pinctrl_show(struct seq_file *s, void *what)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl *p;
|
2012-03-02 20:05:47 +00:00
|
|
|
struct pinctrl_state *state;
|
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 pinctrl_setting *setting;
|
2012-02-09 18:47:48 +00:00
|
|
|
|
|
|
|
|
seq_puts(s, "Requested pin control handlers their pinmux maps:\n");
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
|
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
list_for_each_entry(p, &pinctrl_list, node) {
|
2012-03-02 20:05:47 +00:00
|
|
|
seq_printf(s, "device: %s current state: %s\n",
|
|
|
|
|
dev_name(p->dev),
|
|
|
|
|
p->state ? p->state->name : "none");
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(state, &p->states, node) {
|
|
|
|
|
seq_printf(s, " state: %s\n", state->name);
|
2012-02-09 18:47:48 +00:00
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
list_for_each_entry(setting, &state->settings, node) {
|
2012-03-02 20:05:48 +00:00
|
|
|
struct pinctrl_dev *pctldev = setting->pctldev;
|
|
|
|
|
|
|
|
|
|
seq_printf(s, " type: %s controller %s ",
|
|
|
|
|
map_type(setting->type),
|
|
|
|
|
pinctrl_dev_get_name(pctldev));
|
|
|
|
|
|
|
|
|
|
switch (setting->type) {
|
|
|
|
|
case PIN_MAP_TYPE_MUX_GROUP:
|
|
|
|
|
pinmux_show_setting(s, setting);
|
|
|
|
|
break;
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_PIN:
|
|
|
|
|
case PIN_MAP_TYPE_CONFIGS_GROUP:
|
|
|
|
|
pinconf_show_setting(s, setting);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
}
|
2012-02-09 18:47:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_unlock(&pinctrl_mutex);
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
static int pinctrl_pins_open(struct inode *inode, struct file *file)
|
|
|
|
|
{
|
|
|
|
|
return single_open(file, pinctrl_pins_show, inode->i_private);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pinctrl_groups_open(struct inode *inode, struct file *file)
|
|
|
|
|
{
|
|
|
|
|
return single_open(file, pinctrl_groups_show, inode->i_private);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pinctrl_gpioranges_open(struct inode *inode, struct file *file)
|
|
|
|
|
{
|
|
|
|
|
return single_open(file, pinctrl_gpioranges_show, inode->i_private);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int pinctrl_devices_open(struct inode *inode, struct file *file)
|
|
|
|
|
{
|
|
|
|
|
return single_open(file, pinctrl_devices_show, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-24 00:04:40 +00:00
|
|
|
static int pinctrl_maps_open(struct inode *inode, struct file *file)
|
|
|
|
|
{
|
|
|
|
|
return single_open(file, pinctrl_maps_show, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
static int pinctrl_open(struct inode *inode, struct file *file)
|
|
|
|
|
{
|
|
|
|
|
return single_open(file, pinctrl_show, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
static const struct file_operations pinctrl_pins_ops = {
|
|
|
|
|
.open = pinctrl_pins_open,
|
|
|
|
|
.read = seq_read,
|
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
|
.release = single_release,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct file_operations pinctrl_groups_ops = {
|
|
|
|
|
.open = pinctrl_groups_open,
|
|
|
|
|
.read = seq_read,
|
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
|
.release = single_release,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct file_operations pinctrl_gpioranges_ops = {
|
|
|
|
|
.open = pinctrl_gpioranges_open,
|
|
|
|
|
.read = seq_read,
|
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
|
.release = single_release,
|
|
|
|
|
};
|
|
|
|
|
|
2012-02-24 00:04:40 +00:00
|
|
|
static const struct file_operations pinctrl_devices_ops = {
|
|
|
|
|
.open = pinctrl_devices_open,
|
2012-02-09 18:47:48 +00:00
|
|
|
.read = seq_read,
|
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
|
.release = single_release,
|
|
|
|
|
};
|
|
|
|
|
|
2012-02-24 00:04:40 +00:00
|
|
|
static const struct file_operations pinctrl_maps_ops = {
|
|
|
|
|
.open = pinctrl_maps_open,
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
.read = seq_read,
|
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
|
.release = single_release,
|
|
|
|
|
};
|
|
|
|
|
|
2012-02-09 18:47:48 +00:00
|
|
|
static const struct file_operations pinctrl_ops = {
|
|
|
|
|
.open = pinctrl_open,
|
|
|
|
|
.read = seq_read,
|
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
|
.release = single_release,
|
|
|
|
|
};
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
static struct dentry *debugfs_root;
|
|
|
|
|
|
|
|
|
|
static void pinctrl_init_device_debugfs(struct pinctrl_dev *pctldev)
|
|
|
|
|
{
|
2012-01-20 16:17:22 +00:00
|
|
|
struct dentry *device_root;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
|
2011-12-09 23:59:05 +00:00
|
|
|
device_root = debugfs_create_dir(dev_name(pctldev->dev),
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
debugfs_root);
|
2012-01-20 16:17:22 +00:00
|
|
|
pctldev->device_root = device_root;
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
if (IS_ERR(device_root) || !device_root) {
|
|
|
|
|
pr_warn("failed to create debugfs directory for %s\n",
|
2011-12-09 23:59:05 +00:00
|
|
|
dev_name(pctldev->dev));
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
debugfs_create_file("pins", S_IFREG | S_IRUGO,
|
|
|
|
|
device_root, pctldev, &pinctrl_pins_ops);
|
|
|
|
|
debugfs_create_file("pingroups", S_IFREG | S_IRUGO,
|
|
|
|
|
device_root, pctldev, &pinctrl_groups_ops);
|
|
|
|
|
debugfs_create_file("gpio-ranges", S_IFREG | S_IRUGO,
|
|
|
|
|
device_root, pctldev, &pinctrl_gpioranges_ops);
|
|
|
|
|
pinmux_init_device_debugfs(device_root, pctldev);
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
pinconf_init_device_debugfs(device_root, pctldev);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
|
2012-01-20 16:17:22 +00:00
|
|
|
static void pinctrl_remove_device_debugfs(struct pinctrl_dev *pctldev)
|
|
|
|
|
{
|
|
|
|
|
debugfs_remove_recursive(pctldev->device_root);
|
|
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
static void pinctrl_init_debugfs(void)
|
|
|
|
|
{
|
|
|
|
|
debugfs_root = debugfs_create_dir("pinctrl", NULL);
|
|
|
|
|
if (IS_ERR(debugfs_root) || !debugfs_root) {
|
|
|
|
|
pr_warn("failed to create debugfs directory\n");
|
|
|
|
|
debugfs_root = NULL;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
|
|
|
|
|
debugfs_root, NULL, &pinctrl_devices_ops);
|
2012-02-24 00:04:40 +00:00
|
|
|
debugfs_create_file("pinctrl-maps", S_IFREG | S_IRUGO,
|
|
|
|
|
debugfs_root, NULL, &pinctrl_maps_ops);
|
2012-02-09 18:47:48 +00:00
|
|
|
debugfs_create_file("pinctrl-handles", S_IFREG | S_IRUGO,
|
|
|
|
|
debugfs_root, NULL, &pinctrl_ops);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#else /* CONFIG_DEBUG_FS */
|
|
|
|
|
|
|
|
|
|
static void pinctrl_init_device_debugfs(struct pinctrl_dev *pctldev)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void pinctrl_init_debugfs(void)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-20 16:17:22 +00:00
|
|
|
static void pinctrl_remove_device_debugfs(struct pinctrl_dev *pctldev)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
#endif
|
|
|
|
|
|
2012-03-16 20:54:25 +00:00
|
|
|
static int pinctrl_check_ops(struct pinctrl_dev *pctldev)
|
|
|
|
|
{
|
|
|
|
|
const struct pinctrl_ops *ops = pctldev->desc->pctlops;
|
|
|
|
|
|
|
|
|
|
if (!ops ||
|
2012-03-30 05:55:40 +00:00
|
|
|
!ops->get_groups_count ||
|
2012-03-16 20:54:25 +00:00
|
|
|
!ops->get_group_name ||
|
|
|
|
|
!ops->get_group_pins)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2012-03-23 16:29:46 +00:00
|
|
|
if (ops->dt_node_to_map && !ops->dt_free_map)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2012-03-16 20:54:25 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
/**
|
|
|
|
|
* pinctrl_register() - register a pin controller device
|
|
|
|
|
* @pctldesc: descriptor for this pin controller
|
|
|
|
|
* @dev: parent device for this pin controller
|
|
|
|
|
* @driver_data: private pin controller data for this pin controller
|
|
|
|
|
*/
|
|
|
|
|
struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
|
|
|
|
|
struct device *dev, void *driver_data)
|
|
|
|
|
{
|
|
|
|
|
struct pinctrl_dev *pctldev;
|
|
|
|
|
int ret;
|
|
|
|
|
|
2012-06-16 18:13:16 +00:00
|
|
|
if (!pctldesc)
|
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
|
|
|
return NULL;
|
2012-06-16 18:13:16 +00:00
|
|
|
if (!pctldesc->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
|
|
|
return NULL;
|
|
|
|
|
|
2012-02-22 21:26:00 +00:00
|
|
|
pctldev = kzalloc(sizeof(*pctldev), GFP_KERNEL);
|
2012-02-22 21:25:59 +00:00
|
|
|
if (pctldev == NULL) {
|
|
|
|
|
dev_err(dev, "failed to alloc struct pinctrl_dev\n");
|
2012-01-25 00:28:08 +00:00
|
|
|
return NULL;
|
2012-02-22 21:25:59 +00:00
|
|
|
}
|
2012-01-25 00:28:08 +00:00
|
|
|
|
|
|
|
|
/* Initialize pin control device struct */
|
|
|
|
|
pctldev->owner = pctldesc->owner;
|
|
|
|
|
pctldev->desc = pctldesc;
|
|
|
|
|
pctldev->driver_data = driver_data;
|
|
|
|
|
INIT_RADIX_TREE(&pctldev->pin_desc_tree, GFP_KERNEL);
|
|
|
|
|
INIT_LIST_HEAD(&pctldev->gpio_ranges);
|
|
|
|
|
pctldev->dev = dev;
|
|
|
|
|
|
2012-03-16 20:54:25 +00:00
|
|
|
/* check core ops for sanity */
|
2012-06-16 18:13:16 +00:00
|
|
|
if (pinctrl_check_ops(pctldev)) {
|
2012-04-26 14:47:11 +00:00
|
|
|
dev_err(dev, "pinctrl ops lacks necessary functions\n");
|
2012-03-16 20:54:25 +00:00
|
|
|
goto out_err;
|
|
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
/* If we're implementing pinmuxing, check the ops for sanity */
|
|
|
|
|
if (pctldesc->pmxops) {
|
2012-06-16 18:13:16 +00:00
|
|
|
if (pinmux_check_ops(pctldev))
|
2012-01-25 00:28:08 +00:00
|
|
|
goto out_err;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
/* If we're implementing pinconfig, check the ops for sanity */
|
|
|
|
|
if (pctldesc->confops) {
|
2012-06-16 18:13:16 +00:00
|
|
|
if (pinconf_check_ops(pctldev))
|
2012-01-25 00:28:08 +00:00
|
|
|
goto out_err;
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 16:14:33 +00:00
|
|
|
}
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
/* Register all the pins */
|
2012-04-26 14:47:11 +00:00
|
|
|
dev_dbg(dev, "try to register %d pins ...\n", pctldesc->npins);
|
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
|
|
|
ret = pinctrl_register_pins(pctldev, pctldesc->pins, pctldesc->npins);
|
|
|
|
|
if (ret) {
|
2012-04-26 14:47:11 +00:00
|
|
|
dev_err(dev, "error during pin registration\n");
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
pinctrl_free_pindescs(pctldev, pctldesc->pins,
|
|
|
|
|
pctldesc->npins);
|
2011-12-09 23:59:05 +00:00
|
|
|
goto out_err;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
2012-02-20 06:45:42 +00:00
|
|
|
list_add_tail(&pctldev->node, &pinctrldev_list);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
pctldev->p = pinctrl_get_locked(pctldev->dev);
|
|
|
|
|
if (!IS_ERR(pctldev->p)) {
|
|
|
|
|
struct pinctrl_state *s =
|
|
|
|
|
pinctrl_lookup_state_locked(pctldev->p,
|
|
|
|
|
PINCTRL_STATE_DEFAULT);
|
2012-04-26 14:47:11 +00:00
|
|
|
if (IS_ERR(s)) {
|
|
|
|
|
dev_dbg(dev, "failed to lookup the default state\n");
|
|
|
|
|
} else {
|
2012-06-16 18:13:16 +00:00
|
|
|
if (pinctrl_select_state_locked(pctldev->p, s))
|
2012-04-26 14:47:11 +00:00
|
|
|
dev_err(dev,
|
|
|
|
|
"failed to select default state\n");
|
|
|
|
|
}
|
2012-03-02 20:05:47 +00:00
|
|
|
}
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
|
|
|
|
|
2012-02-22 21:26:01 +00:00
|
|
|
pinctrl_init_device_debugfs(pctldev);
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
return pctldev;
|
|
|
|
|
|
2011-12-09 23:59:05 +00:00
|
|
|
out_err:
|
|
|
|
|
kfree(pctldev);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_register);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* pinctrl_unregister() - unregister pinmux
|
|
|
|
|
* @pctldev: pin controller to unregister
|
|
|
|
|
*
|
|
|
|
|
* Called by pinmux drivers to unregister a pinmux.
|
|
|
|
|
*/
|
|
|
|
|
void pinctrl_unregister(struct pinctrl_dev *pctldev)
|
|
|
|
|
{
|
2012-05-23 13:22:40 +00:00
|
|
|
struct pinctrl_gpio_range *range, *n;
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
if (pctldev == NULL)
|
|
|
|
|
return;
|
|
|
|
|
|
2012-01-20 16:17:22 +00:00
|
|
|
pinctrl_remove_device_debugfs(pctldev);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
|
|
|
|
mutex_lock(&pinctrl_mutex);
|
|
|
|
|
|
2012-03-02 20:05:47 +00:00
|
|
|
if (!IS_ERR(pctldev->p))
|
|
|
|
|
pinctrl_put_locked(pctldev->p, true);
|
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
|
|
|
|
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
|
|
|
/* TODO: check that no pinmuxes are still active? */
|
|
|
|
|
list_del(&pctldev->node);
|
|
|
|
|
/* Destroy descriptor tree */
|
|
|
|
|
pinctrl_free_pindescs(pctldev, pctldev->desc->pins,
|
|
|
|
|
pctldev->desc->npins);
|
2012-05-23 13:22:40 +00:00
|
|
|
/* remove gpio ranges map */
|
|
|
|
|
list_for_each_entry_safe(range, n, &pctldev->gpio_ranges, node)
|
|
|
|
|
list_del(&range->node);
|
|
|
|
|
|
2011-12-09 23:59:05 +00:00
|
|
|
kfree(pctldev);
|
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking:
struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.
Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.
There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.
As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.
However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.
The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.
This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-02 20:05:44 +00:00
|
|
|
|
|
|
|
|
mutex_unlock(&pinctrl_mutex);
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 18:50:54 +00:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(pinctrl_unregister);
|
|
|
|
|
|
|
|
|
|
static int __init pinctrl_init(void)
|
|
|
|
|
{
|
|
|
|
|
pr_info("initialized pinctrl subsystem\n");
|
|
|
|
|
pinctrl_init_debugfs();
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* init early since many drivers really need to initialized pinmux early */
|
|
|
|
|
core_initcall(pinctrl_init);
|