2019-05-19 05:07:45 -07:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
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 11:50:54 -07:00
|
|
|
#
|
|
|
|
|
# PINCTRL infrastructure and drivers
|
|
|
|
|
#
|
|
|
|
|
|
2017-10-05 22:08:05 -07:00
|
|
|
menuconfig PINCTRL
|
|
|
|
|
bool "Pin controllers"
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 11:50:54 -07:00
|
|
|
|
2017-10-05 22:08:05 -07:00
|
|
|
if PINCTRL
|
2011-11-05 13:28:46 -07:00
|
|
|
|
2016-12-30 07:04:43 -07:00
|
|
|
config GENERIC_PINCTRL_GROUPS
|
2016-12-27 10:20:00 -07:00
|
|
|
bool
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 11:50:54 -07:00
|
|
|
config PINMUX
|
2014-06-03 01:02:36 -07:00
|
|
|
bool "Support pin multiplexing controllers" if COMPILE_TEST
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 09:14:33 -07:00
|
|
|
|
2016-12-27 10:20:01 -07:00
|
|
|
config GENERIC_PINMUX_FUNCTIONS
|
|
|
|
|
bool
|
|
|
|
|
select PINMUX
|
|
|
|
|
|
pinctrl: add a pin config interface
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-10-19 09:14:33 -07:00
|
|
|
config PINCONF
|
2014-06-03 01:02:36 -07:00
|
|
|
bool "Support pin configuration controllers" if COMPILE_TEST
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 11:50:54 -07:00
|
|
|
|
2011-11-24 10:27:15 -07:00
|
|
|
config GENERIC_PINCONF
|
|
|
|
|
bool
|
|
|
|
|
select PINCONF
|
|
|
|
|
|
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 11:50:54 -07:00
|
|
|
config DEBUG_PINCTRL
|
|
|
|
|
bool "Debug PINCTRL calls"
|
|
|
|
|
depends on DEBUG_KERNEL
|
|
|
|
|
help
|
|
|
|
|
Say Y here to add some extra checks and diagnostics to PINCTRL calls.
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_AMD
|
2022-07-13 10:59:50 -07:00
|
|
|
bool "AMD GPIO pin control"
|
2021-12-09 04:34:56 -07:00
|
|
|
depends on HAS_IOMEM
|
|
|
|
|
depends on ACPI || COMPILE_TEST
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
The driver for memory mapped GPIO functionality on AMD platforms
|
|
|
|
|
(x86 or arm). Most of the pins are usually muxed to some other
|
|
|
|
|
functionality by firmware, so only a small amount is available
|
|
|
|
|
for GPIO use.
|
|
|
|
|
|
|
|
|
|
Requires ACPI/FDT device enumeration code to set up a platform
|
|
|
|
|
device.
|
|
|
|
|
|
2021-10-26 10:58:14 -07:00
|
|
|
config PINCTRL_APPLE_GPIO
|
|
|
|
|
tristate "Apple SoC GPIO pin controller driver"
|
|
|
|
|
depends on ARCH_APPLE
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select GENERIC_PINCTRL_GROUPS
|
|
|
|
|
select GENERIC_PINMUX_FUNCTIONS
|
|
|
|
|
select OF_GPIO
|
|
|
|
|
help
|
|
|
|
|
This is the driver for the GPIO controller found on Apple ARM SoCs,
|
|
|
|
|
including M1.
|
|
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
|
will be called pinctrl-apple-gpio.
|
|
|
|
|
|
2017-04-03 05:47:04 -07:00
|
|
|
config PINCTRL_ARTPEC6
|
2019-11-20 20:19:41 -07:00
|
|
|
bool "Axis ARTPEC-6 pin controller driver"
|
|
|
|
|
depends on MACH_ARTPEC6
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
This is the driver for the Axis ARTPEC-6 pin controller. This driver
|
|
|
|
|
supports pin function multiplexing as well as pin bias and drive
|
|
|
|
|
strength configuration. Device tree integration instructions can be
|
|
|
|
|
found in Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
|
2017-04-03 05:47:04 -07:00
|
|
|
|
2013-10-02 08:50:29 -07:00
|
|
|
config PINCTRL_AS3722
|
2016-06-13 14:10:22 -07:00
|
|
|
tristate "Pinctrl and GPIO driver for ams AS3722 PMIC"
|
2013-10-02 08:50:29 -07:00
|
|
|
depends on MFD_AS3722 && GPIOLIB
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
AS3722 device supports the configuration of GPIO pins for different
|
|
|
|
|
functionality. This driver supports the pinmux, push-pull and
|
|
|
|
|
open drain configuration for the GPIO pins of AS3722 devices. It also
|
|
|
|
|
supports the GPIO functionality through gpiolib.
|
|
|
|
|
|
2012-07-12 08:35:02 -07:00
|
|
|
config PINCTRL_AT91
|
|
|
|
|
bool "AT91 pinctrl driver"
|
|
|
|
|
depends on OF
|
|
|
|
|
depends on ARCH_AT91
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
2014-04-15 13:09:41 -07:00
|
|
|
select GPIOLIB
|
|
|
|
|
select OF_GPIO
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
2012-07-12 08:35:02 -07:00
|
|
|
help
|
|
|
|
|
Say Y here to enable the at91 pinctrl driver
|
|
|
|
|
|
2015-09-16 08:36:57 -07:00
|
|
|
config PINCTRL_AT91PIO4
|
|
|
|
|
bool "AT91 PIO4 pinctrl driver"
|
|
|
|
|
depends on OF
|
2020-11-24 02:17:03 -07:00
|
|
|
depends on HAS_IOMEM
|
2020-05-23 04:45:26 -07:00
|
|
|
depends on ARCH_AT91 || COMPILE_TEST
|
2015-09-16 08:36:57 -07:00
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select OF_GPIO
|
|
|
|
|
help
|
|
|
|
|
Say Y here to enable the at91 pinctrl/gpio driver for Atmel PIO4
|
|
|
|
|
controller available on sama5d2 SoC.
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_AXP209
|
|
|
|
|
tristate "X-Powers AXP209 PMIC pinctrl and GPIO Support"
|
|
|
|
|
depends on MFD_AXP20X
|
|
|
|
|
depends on OF
|
2017-09-26 06:51:28 -07:00
|
|
|
select PINMUX
|
2015-03-10 00:02:19 -07:00
|
|
|
select GENERIC_PINCONF
|
2021-12-09 04:34:56 -07:00
|
|
|
select GPIOLIB
|
2015-03-10 00:02:19 -07:00
|
|
|
help
|
2021-12-09 04:34:56 -07:00
|
|
|
AXP PMICs provides multiple GPIOs that can be muxed for different
|
|
|
|
|
functions. This driver bundles a pinctrl driver to select the function
|
|
|
|
|
muxing and a GPIO driver to handle the GPIO when the GPIO function is
|
|
|
|
|
selected.
|
|
|
|
|
Say Y to enable pinctrl and GPIO support for the AXP209 PMIC.
|
2015-03-10 00:02:19 -07:00
|
|
|
|
2024-03-01 06:29:24 -07:00
|
|
|
config PINCTRL_AW9523
|
2024-03-05 04:00:03 -07:00
|
|
|
tristate "Awinic AW9523/AW9523B I2C GPIO expander pinctrl driver"
|
2024-03-01 06:29:24 -07:00
|
|
|
depends on OF && I2C
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select REGMAP
|
|
|
|
|
select REGMAP_I2C
|
|
|
|
|
help
|
|
|
|
|
The Awinic AW9523/AW9523B is a multi-function I2C GPIO
|
|
|
|
|
expander with PWM functionality. This driver bundles a
|
|
|
|
|
pinctrl driver to select the function muxing and a GPIO
|
|
|
|
|
driver to handle GPIO, when the GPIO function is selected.
|
|
|
|
|
|
|
|
|
|
Say yes to enable pinctrl and GPIO support for the AW9523(B).
|
|
|
|
|
|
2019-04-24 05:02:23 -07:00
|
|
|
config PINCTRL_BM1880
|
|
|
|
|
bool "Bitmain BM1880 Pinctrl driver"
|
2019-04-25 01:32:24 -07:00
|
|
|
depends on OF && (ARCH_BITMAIN || COMPILE_TEST)
|
|
|
|
|
default ARCH_BITMAIN
|
2019-04-24 05:02:23 -07:00
|
|
|
select PINMUX
|
|
|
|
|
help
|
|
|
|
|
Pinctrl driver for Bitmain BM1880 SoC.
|
|
|
|
|
|
2022-08-15 22:49:15 -07:00
|
|
|
config PINCTRL_CY8C95X0
|
|
|
|
|
tristate "Cypress CY8C95X0 I2C pinctrl and GPIO driver"
|
2022-09-02 11:26:46 -07:00
|
|
|
depends on I2C
|
2022-08-15 22:49:15 -07:00
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select REGMAP_I2C
|
|
|
|
|
help
|
|
|
|
|
Support for 20/40/60 pin Cypress Cy8C95x0 pinctrl/gpio I2C expander.
|
|
|
|
|
This driver can also be built as a module. If so, the module will be
|
|
|
|
|
called pinctrl-cy8c95x0.
|
|
|
|
|
|
2016-11-28 09:40:25 -07:00
|
|
|
config PINCTRL_DA850_PUPD
|
2021-12-09 04:34:56 -07:00
|
|
|
tristate "TI DA850/OMAP-L138/AM18XX pull-up and pull-down groups"
|
2016-11-28 09:40:25 -07:00
|
|
|
depends on OF && (ARCH_DAVINCI_DA850 || COMPILE_TEST)
|
|
|
|
|
select PINCONF
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
Driver for TI DA850/OMAP-L138/AM18XX pinconf. Used to control
|
2021-12-09 04:34:56 -07:00
|
|
|
pull-up and pull-down pin groups.
|
2016-11-28 09:40:25 -07:00
|
|
|
|
2020-01-08 03:47:46 -07:00
|
|
|
config PINCTRL_DA9062
|
|
|
|
|
tristate "Dialog Semiconductor DA9062 PMIC pinctrl and GPIO Support"
|
|
|
|
|
depends on MFD_DA9062
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
help
|
|
|
|
|
The Dialog DA9062 PMIC provides multiple GPIOs that can be muxed for
|
|
|
|
|
different functions. This driver bundles a pinctrl driver to select the
|
|
|
|
|
function muxing and a GPIO driver to handle the GPIO when the GPIO
|
|
|
|
|
function is selected.
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
Say Y to enable pinctrl and GPIO support for the DA9062 PMIC.
|
2020-01-08 03:47:46 -07:00
|
|
|
|
2015-05-05 03:55:10 -07:00
|
|
|
config PINCTRL_DIGICOLOR
|
|
|
|
|
bool
|
2023-01-13 07:36:40 -07:00
|
|
|
depends on ARCH_DIGICOLOR || COMPILE_TEST
|
2015-05-05 03:55:10 -07:00
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
|
2024-09-09 01:10:29 -07:00
|
|
|
config PINCTRL_EP93XX
|
|
|
|
|
bool
|
|
|
|
|
depends on ARCH_EP93XX || COMPILE_TEST
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select MFD_SYSCON
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_EQUILIBRIUM
|
|
|
|
|
tristate "Generic pinctrl and GPIO driver for Intel Lightning Mountain SoC"
|
|
|
|
|
depends on OF && HAS_IOMEM
|
|
|
|
|
depends on X86 || COMPILE_TEST
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIO_GENERIC
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GENERIC_PINCTRL_GROUPS
|
|
|
|
|
select GENERIC_PINMUX_FUNCTIONS
|
|
|
|
|
help
|
|
|
|
|
Equilibrium driver is a pinctrl and GPIO driver for Intel Lightning
|
|
|
|
|
Mountain network processor SoC that supports both the GPIO and pin
|
|
|
|
|
control frameworks. It provides interfaces to setup pin muxing, assign
|
|
|
|
|
desired pin functions, configure GPIO attributes for LGM SoC pins.
|
|
|
|
|
Pin muxing and pin config settings are retrieved from device tree.
|
|
|
|
|
|
2024-07-30 09:08:19 -07:00
|
|
|
config PINCTRL_EYEQ5
|
|
|
|
|
bool "Mobileye EyeQ5 pinctrl driver"
|
|
|
|
|
depends on OF
|
|
|
|
|
depends on MACH_EYEQ5 || COMPILE_TEST
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select AUXILIARY_BUS
|
|
|
|
|
default MACH_EYEQ5
|
|
|
|
|
help
|
|
|
|
|
Pin controller driver for the Mobileye EyeQ5 platform. It does both
|
|
|
|
|
pin config & pin muxing. It does not handle GPIO.
|
|
|
|
|
|
|
|
|
|
Pin muxing supports two functions for each pin: first is GPIO, second
|
|
|
|
|
is pin-dependent. Pin config is about bias & drive strength.
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_GEMINI
|
|
|
|
|
bool
|
|
|
|
|
depends on ARCH_GEMINI
|
|
|
|
|
default ARCH_GEMINI
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select MFD_SYSCON
|
|
|
|
|
|
|
|
|
|
config PINCTRL_INGENIC
|
|
|
|
|
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
|
|
|
|
|
default MACH_INGENIC
|
|
|
|
|
depends on OF
|
|
|
|
|
depends on MIPS || COMPILE_TEST
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GENERIC_PINCTRL_GROUPS
|
|
|
|
|
select GENERIC_PINMUX_FUNCTIONS
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select REGMAP_MMIO
|
|
|
|
|
|
|
|
|
|
config PINCTRL_K210
|
|
|
|
|
bool "Pinctrl driver for the Canaan Kendryte K210 SoC"
|
2024-03-28 10:06:12 -07:00
|
|
|
depends on RISCV && SOC_CANAAN_K210 && OF
|
2021-12-09 04:34:56 -07:00
|
|
|
select GENERIC_PINMUX_FUNCTIONS
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select OF_GPIO
|
|
|
|
|
select REGMAP_MMIO
|
2024-03-28 10:06:12 -07:00
|
|
|
default SOC_CANAAN_K210
|
2021-12-09 04:34:56 -07:00
|
|
|
help
|
|
|
|
|
Add support for the Canaan Kendryte K210 RISC-V SOC Field
|
|
|
|
|
Programmable IO Array (FPIOA) controller.
|
|
|
|
|
|
|
|
|
|
config PINCTRL_KEEMBAY
|
|
|
|
|
tristate "Pinctrl driver for Intel Keem Bay SoC"
|
|
|
|
|
depends on ARCH_KEEMBAY || (ARM64 && COMPILE_TEST)
|
|
|
|
|
depends on HAS_IOMEM
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GENERIC_PINCTRL_GROUPS
|
|
|
|
|
select GENERIC_PINMUX_FUNCTIONS
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select GPIO_GENERIC
|
|
|
|
|
help
|
|
|
|
|
This selects pin control driver for the Intel Keem Bay SoC.
|
|
|
|
|
It provides pin config functions such as pull-up, pull-down,
|
|
|
|
|
interrupt, drive strength, sec lock, Schmitt trigger, slew
|
|
|
|
|
rate control and direction control. This module will be
|
|
|
|
|
called as pinctrl-keembay.
|
|
|
|
|
|
2012-08-28 03:44:59 -07:00
|
|
|
config PINCTRL_LANTIQ
|
|
|
|
|
bool
|
|
|
|
|
depends on LANTIQ
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_FALCON
|
|
|
|
|
bool
|
|
|
|
|
depends on SOC_FALCON
|
|
|
|
|
depends on PINCTRL_LANTIQ
|
|
|
|
|
|
2022-11-13 19:49:41 -07:00
|
|
|
config PINCTRL_LOONGSON2
|
|
|
|
|
tristate "Pinctrl driver for the Loongson-2 SoC"
|
2022-11-21 06:26:08 -07:00
|
|
|
depends on OF && (LOONGARCH || COMPILE_TEST)
|
2022-11-13 19:49:41 -07:00
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
This selects pin control driver for the Loongson-2 SoC. It
|
|
|
|
|
provides pin config functions multiplexing. GPIO pin pull-up,
|
|
|
|
|
pull-down functions are not supported. Say yes to enable
|
|
|
|
|
pinctrl for Loongson-2 SoC.
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_XWAY
|
|
|
|
|
bool
|
|
|
|
|
depends on SOC_TYPE_XWAY
|
|
|
|
|
depends on PINCTRL_LANTIQ
|
|
|
|
|
|
2015-04-27 15:14:08 -07:00
|
|
|
config PINCTRL_LPC18XX
|
|
|
|
|
bool "NXP LPC18XX/43XX SCU pinctrl driver"
|
|
|
|
|
depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
|
|
|
|
|
default ARCH_LPC18XX
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
Pinctrl driver for NXP LPC18xx/43xx System Control Unit (SCU).
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_MAX77620
|
|
|
|
|
tristate "MAX77620/MAX20024 Pincontrol support"
|
|
|
|
|
depends on MFD_MAX77620 && OF
|
2017-08-05 14:04:08 -07:00
|
|
|
select PINMUX
|
2017-10-28 06:37:18 -07:00
|
|
|
select GENERIC_PINCONF
|
2021-12-09 04:34:56 -07:00
|
|
|
help
|
|
|
|
|
Say Y here to enable Pin control support for Maxim MAX77620 PMIC.
|
|
|
|
|
This PMIC has 8 GPIO pins that work as GPIO as well as special
|
|
|
|
|
function in alternate mode. This driver also configure push-pull,
|
|
|
|
|
open drain, FPS slots etc.
|
2017-08-05 14:04:08 -07:00
|
|
|
|
2020-04-07 10:38:49 -07:00
|
|
|
config PINCTRL_MCP23S08_I2C
|
|
|
|
|
tristate
|
|
|
|
|
select REGMAP_I2C
|
|
|
|
|
|
|
|
|
|
config PINCTRL_MCP23S08_SPI
|
|
|
|
|
tristate
|
|
|
|
|
select REGMAP_SPI
|
|
|
|
|
|
2017-05-15 02:24:25 -07:00
|
|
|
config PINCTRL_MCP23S08
|
|
|
|
|
tristate "Microchip MCP23xxx I/O expander"
|
|
|
|
|
depends on SPI_MASTER || I2C
|
2017-10-11 03:04:35 -07:00
|
|
|
select GPIOLIB
|
2017-05-15 02:24:25 -07:00
|
|
|
select GPIOLIB_IRQCHIP
|
2017-05-15 02:24:26 -07:00
|
|
|
select GENERIC_PINCONF
|
2020-04-07 10:38:49 -07:00
|
|
|
select PINCTRL_MCP23S08_I2C if I2C
|
|
|
|
|
select PINCTRL_MCP23S08_SPI if SPI_MASTER
|
2017-05-15 02:24:25 -07:00
|
|
|
help
|
2018-02-15 07:56:03 -07:00
|
|
|
SPI/I2C driver for Microchip MCP23S08 / MCP23S17 / MCP23S18 /
|
|
|
|
|
MCP23008 / MCP23017 / MCP23018 I/O expanders.
|
|
|
|
|
This provides a GPIO interface supporting inputs and outputs and a
|
|
|
|
|
corresponding interrupt-controller.
|
2017-05-15 02:24:25 -07:00
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_MICROCHIP_SGPIO
|
2022-09-05 09:21:28 -07:00
|
|
|
tristate "Pinctrl driver for Microsemi/Microchip Serial GPIO"
|
2016-05-11 00:34:21 -07:00
|
|
|
depends on OF
|
2021-12-09 04:34:56 -07:00
|
|
|
depends on HAS_IOMEM
|
2016-05-11 00:34:21 -07:00
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
2013-06-10 13:16:22 -07:00
|
|
|
select GENERIC_PINCONF
|
2021-12-09 04:34:56 -07:00
|
|
|
select GENERIC_PINCTRL_GROUPS
|
|
|
|
|
select GENERIC_PINMUX_FUNCTIONS
|
2020-09-05 14:49:55 -07:00
|
|
|
select OF_GPIO
|
2021-03-04 17:39:06 -07:00
|
|
|
help
|
2021-12-09 04:34:56 -07:00
|
|
|
Support for the serial GPIO interface used on Microsemi and
|
|
|
|
|
Microchip SoCs. By using a serial interface, the SIO
|
|
|
|
|
controller significantly extends the number of available
|
|
|
|
|
GPIOs with a minimum number of additional pins on the
|
|
|
|
|
device. The primary purpose of the SIO controller is to
|
|
|
|
|
connect control signals from SFP modules and to act as an
|
|
|
|
|
LED controller.
|
2013-06-10 13:16:22 -07:00
|
|
|
|
2022-09-05 09:21:28 -07:00
|
|
|
If compiled as a module, the module name will be
|
|
|
|
|
pinctrl-microchip-sgpio.
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_OCELOT
|
2022-06-17 03:35:48 -07:00
|
|
|
tristate "Pinctrl driver for the Microsemi Ocelot and Jaguar2 SoCs"
|
2012-07-10 02:05:46 -07:00
|
|
|
depends on OF
|
2017-11-13 03:04:27 -07:00
|
|
|
depends on HAS_IOMEM
|
2017-10-11 03:04:35 -07:00
|
|
|
select GPIOLIB
|
2016-10-21 02:09:58 -07:00
|
|
|
select GPIOLIB_IRQCHIP
|
2015-05-06 12:59:03 -07:00
|
|
|
select GENERIC_PINCONF
|
2021-12-09 04:34:56 -07:00
|
|
|
select GENERIC_PINCTRL_GROUPS
|
|
|
|
|
select GENERIC_PINMUX_FUNCTIONS
|
2015-05-06 12:59:03 -07:00
|
|
|
select OF_GPIO
|
2021-12-09 04:34:56 -07:00
|
|
|
select REGMAP_MMIO
|
2022-09-09 08:38:02 -07:00
|
|
|
help
|
|
|
|
|
Support for the internal GPIO interfaces on Microsemi Ocelot and
|
|
|
|
|
Jaguar2 SoCs.
|
|
|
|
|
|
|
|
|
|
If conpiled as a module, the module name will be pinctrl-ocelot.
|
2015-05-06 12:59:03 -07:00
|
|
|
|
2013-08-06 06:12:35 -07:00
|
|
|
config PINCTRL_PALMAS
|
2016-06-13 14:10:21 -07:00
|
|
|
tristate "Pinctrl driver for the PALMAS Series MFD devices"
|
2013-08-06 06:12:35 -07:00
|
|
|
depends on OF && MFD_PALMAS
|
2013-08-21 23:30:08 -07:00
|
|
|
select PINMUX
|
2013-08-06 06:12:35 -07:00
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
Palmas device supports the configuration of pins for different
|
|
|
|
|
functionality. This driver supports the pinmux, push-pull and
|
|
|
|
|
open drain configuration for the Palmas series devices like
|
|
|
|
|
TPS65913, TPS80036 etc.
|
|
|
|
|
|
2023-11-28 06:25:33 -07:00
|
|
|
config PINCTRL_PEF2256
|
|
|
|
|
tristate "Lantiq PEF2256 (FALC56) pin controller driver"
|
|
|
|
|
depends on OF && FRAMER_PEF2256
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
This option enables the pin controller support for the Lantiq PEF2256
|
|
|
|
|
framer, also known as FALC56.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called pinctrl-pef2256.
|
|
|
|
|
|
2016-02-01 15:48:30 -07:00
|
|
|
config PINCTRL_PIC32
|
|
|
|
|
bool "Microchip PIC32 pin controller driver"
|
|
|
|
|
depends on OF
|
|
|
|
|
depends on MACH_PIC32
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select OF_GPIO
|
|
|
|
|
help
|
|
|
|
|
This is the pin controller and gpio driver for Microchip PIC32
|
|
|
|
|
microcontrollers. This option is selected automatically when specific
|
|
|
|
|
machine and arch are selected to build.
|
|
|
|
|
|
|
|
|
|
config PINCTRL_PIC32MZDA
|
|
|
|
|
def_bool y if PIC32MZDA
|
|
|
|
|
select PINCTRL_PIC32
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_PISTACHIO
|
|
|
|
|
bool "IMG Pistachio SoC pinctrl driver"
|
|
|
|
|
depends on OF && (MIPS || COMPILE_TEST)
|
|
|
|
|
depends on GPIOLIB
|
2021-04-22 01:30:02 -07:00
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
2018-08-21 09:42:32 -07:00
|
|
|
select GPIOLIB_IRQCHIP
|
2021-12-09 04:34:56 -07:00
|
|
|
select OF_GPIO
|
|
|
|
|
help
|
|
|
|
|
This support pinctrl and GPIO driver for IMG Pistachio SoC.
|
2017-05-12 09:52:56 -07:00
|
|
|
|
2017-08-20 18:28:40 -07:00
|
|
|
config PINCTRL_RK805
|
|
|
|
|
tristate "Pinctrl and GPIO driver for RK805 PMIC"
|
2023-05-04 10:36:09 -07:00
|
|
|
depends on MFD_RK8XX
|
2017-08-20 18:28:40 -07:00
|
|
|
select GPIOLIB
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
This selects the pinctrl driver for RK805.
|
|
|
|
|
|
2013-06-10 13:16:22 -07:00
|
|
|
config PINCTRL_ROCKCHIP
|
2021-03-04 17:39:07 -07:00
|
|
|
tristate "Rockchip gpio and pinctrl driver"
|
2021-03-16 06:40:59 -07:00
|
|
|
depends on ARCH_ROCKCHIP || COMPILE_TEST
|
2020-09-05 14:49:55 -07:00
|
|
|
depends on OF
|
2021-03-04 17:39:06 -07:00
|
|
|
select GPIOLIB
|
2013-06-10 13:16:22 -07:00
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GENERIC_IRQ_CHIP
|
2014-05-05 04:58:20 -07:00
|
|
|
select MFD_SYSCON
|
2020-09-05 14:49:55 -07:00
|
|
|
select OF_GPIO
|
2021-03-04 17:39:06 -07:00
|
|
|
default ARCH_ROCKCHIP
|
|
|
|
|
help
|
2021-12-09 04:34:56 -07:00
|
|
|
This support pinctrl and GPIO driver for Rockchip SoCs.
|
2013-06-10 13:16:22 -07:00
|
|
|
|
2024-04-17 18:32:31 -07:00
|
|
|
config PINCTRL_SCMI
|
|
|
|
|
tristate "Pinctrl driver using SCMI protocol interface"
|
|
|
|
|
depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
This driver provides support for pinctrl which is controlled
|
|
|
|
|
by firmware that implements the SCMI interface.
|
|
|
|
|
It uses SCMI Message Protocol to interact with the
|
|
|
|
|
firmware providing all the pinctrl controls.
|
|
|
|
|
|
2012-07-10 02:05:46 -07:00
|
|
|
config PINCTRL_SINGLE
|
|
|
|
|
tristate "One-register-per-pin type device tree based pinctrl driver"
|
|
|
|
|
depends on OF
|
2017-11-13 03:04:27 -07:00
|
|
|
depends on HAS_IOMEM
|
2016-12-27 10:20:02 -07:00
|
|
|
select GENERIC_PINCTRL_GROUPS
|
2016-12-27 10:20:03 -07:00
|
|
|
select GENERIC_PINMUX_FUNCTIONS
|
2013-02-17 04:42:55 -07:00
|
|
|
select GENERIC_PINCONF
|
2012-07-10 02:05:46 -07:00
|
|
|
help
|
|
|
|
|
This selects the device tree based generic pinctrl driver.
|
|
|
|
|
|
2013-06-20 07:05:38 -07:00
|
|
|
config PINCTRL_ST
|
|
|
|
|
bool
|
|
|
|
|
depends on OF
|
|
|
|
|
select PINMUX
|
|
|
|
|
select PINCONF
|
2014-04-08 05:45:47 -07:00
|
|
|
select GPIOLIB_IRQCHIP
|
2013-06-20 07:05:38 -07:00
|
|
|
|
2019-05-09 01:58:51 -07:00
|
|
|
config PINCTRL_STMFX
|
|
|
|
|
tristate "STMicroelectronics STMFX GPIO expander pinctrl driver"
|
2019-05-10 06:39:18 -07:00
|
|
|
depends on I2C
|
2019-05-24 00:32:05 -07:00
|
|
|
depends on OF_GPIO
|
2019-05-09 01:58:51 -07:00
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select MFD_STMFX
|
|
|
|
|
help
|
|
|
|
|
Driver for STMicroelectronics Multi-Function eXpander (STMFX)
|
|
|
|
|
GPIO expander.
|
|
|
|
|
This provides a GPIO interface supporting inputs and outputs,
|
|
|
|
|
and configuring push-pull, open-drain, and can also be used as
|
|
|
|
|
interrupt-controller.
|
|
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_SX150X
|
|
|
|
|
bool "Semtech SX150x I2C GPIO expander pinctrl driver"
|
|
|
|
|
depends on I2C=y
|
2016-06-13 08:18:35 -07:00
|
|
|
select PINMUX
|
2021-12-09 04:34:56 -07:00
|
|
|
select PINCONF
|
2016-05-12 22:19:15 -07:00
|
|
|
select GENERIC_PINCONF
|
2021-01-11 17:58:40 -07:00
|
|
|
select GPIOLIB
|
2021-12-09 04:34:56 -07:00
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
select REGMAP
|
2016-05-12 22:19:15 -07:00
|
|
|
help
|
2021-12-09 04:34:56 -07:00
|
|
|
Say Y here to provide support for Semtech SX150x-series I2C
|
|
|
|
|
GPIO expanders as pinctrl module.
|
|
|
|
|
Compatible models include:
|
|
|
|
|
- 8 bits: sx1508q, sx1502q
|
|
|
|
|
- 16 bits: sx1509q, sx1506q
|
2016-05-12 22:19:15 -07:00
|
|
|
|
2021-12-09 04:34:56 -07:00
|
|
|
config PINCTRL_TB10X
|
|
|
|
|
bool
|
|
|
|
|
depends on OF && ARC_PLAT_TB10X
|
|
|
|
|
select GPIOLIB
|
2013-08-06 06:12:35 -07:00
|
|
|
|
2023-11-08 03:41:24 -07:00
|
|
|
config PINCTRL_TPS6594
|
|
|
|
|
tristate "Pinctrl and GPIO driver for TI TPS6594 PMIC"
|
|
|
|
|
depends on OF && MFD_TPS6594
|
|
|
|
|
default MFD_TPS6594
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select REGMAP
|
|
|
|
|
select GPIO_REGMAP
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
|
|
|
|
Say Y to select the pinmuxing and GPIOs driver for the TPS6594
|
|
|
|
|
PMICs chip family.
|
|
|
|
|
|
|
|
|
|
This driver can also be built as a module
|
|
|
|
|
called tps6594-pinctrl.
|
|
|
|
|
|
2015-01-09 08:43:48 -07:00
|
|
|
config PINCTRL_ZYNQ
|
|
|
|
|
bool "Pinctrl driver for Xilinx Zynq"
|
|
|
|
|
depends on ARCH_ZYNQ
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
help
|
2015-11-30 00:57:35 -07:00
|
|
|
This selects the pinctrl driver for Xilinx Zynq.
|
2015-01-09 08:43:48 -07:00
|
|
|
|
2021-04-22 01:30:02 -07:00
|
|
|
config PINCTRL_ZYNQMP
|
|
|
|
|
tristate "Pinctrl driver for Xilinx ZynqMP"
|
|
|
|
|
depends on ZYNQMP_FIRMWARE
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GENERIC_PINCONF
|
|
|
|
|
default ZYNQMP_FIRMWARE
|
|
|
|
|
help
|
|
|
|
|
This selects the pinctrl driver for Xilinx ZynqMP platform.
|
|
|
|
|
This driver will query the pin information from the firmware
|
|
|
|
|
and allow configuring the pins.
|
|
|
|
|
Configuration can include the mux function to select on those
|
|
|
|
|
pin(s)/group(s), and various pin configuration parameters
|
|
|
|
|
such as pull-up, slew rate, etc.
|
2021-06-21 04:00:14 -07:00
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
|
will be called pinctrl-zynqmp.
|
2021-04-22 01:30:02 -07:00
|
|
|
|
2023-03-15 14:50:27 -07:00
|
|
|
config PINCTRL_MLXBF3
|
|
|
|
|
tristate "NVIDIA BlueField-3 SoC Pinctrl driver"
|
|
|
|
|
depends on (MELLANOX_PLATFORM && ARM64) || COMPILE_TEST
|
|
|
|
|
select PINMUX
|
|
|
|
|
select GPIOLIB
|
|
|
|
|
select GPIOLIB_IRQCHIP
|
|
|
|
|
help
|
|
|
|
|
Say Y to select the pinctrl driver for BlueField-3 SoCs.
|
|
|
|
|
This pin controller allows selecting the mux function for
|
|
|
|
|
each pin. This driver can also be built as a module called
|
|
|
|
|
pinctrl-mlxbf3.
|
|
|
|
|
|
2018-04-04 10:22:52 -07:00
|
|
|
source "drivers/pinctrl/actions/Kconfig"
|
2016-08-30 00:54:24 -07:00
|
|
|
source "drivers/pinctrl/aspeed/Kconfig"
|
2015-03-04 17:35:49 -07:00
|
|
|
source "drivers/pinctrl/bcm/Kconfig"
|
2014-05-19 10:36:29 -07:00
|
|
|
source "drivers/pinctrl/berlin/Kconfig"
|
2021-12-09 04:34:56 -07:00
|
|
|
source "drivers/pinctrl/cirrus/Kconfig"
|
2014-09-03 04:37:38 -07:00
|
|
|
source "drivers/pinctrl/freescale/Kconfig"
|
2014-10-24 05:16:52 -07:00
|
|
|
source "drivers/pinctrl/intel/Kconfig"
|
2021-12-09 04:34:56 -07:00
|
|
|
source "drivers/pinctrl/mediatek/Kconfig"
|
|
|
|
|
source "drivers/pinctrl/meson/Kconfig"
|
2012-10-24 14:38:58 -07:00
|
|
|
source "drivers/pinctrl/mvebu/Kconfig"
|
2014-07-11 05:57:06 -07:00
|
|
|
source "drivers/pinctrl/nomadik/Kconfig"
|
2018-08-08 02:25:26 -07:00
|
|
|
source "drivers/pinctrl/nuvoton/Kconfig"
|
2023-02-19 19:33:19 -07:00
|
|
|
source "drivers/pinctrl/nxp/Kconfig"
|
2015-11-21 11:04:53 -07:00
|
|
|
source "drivers/pinctrl/pxa/Kconfig"
|
2014-07-09 04:55:12 -07:00
|
|
|
source "drivers/pinctrl/qcom/Kconfig"
|
2023-09-19 03:11:11 -07:00
|
|
|
source "drivers/pinctrl/realtek/Kconfig"
|
2020-09-09 06:15:33 -07:00
|
|
|
source "drivers/pinctrl/renesas/Kconfig"
|
2014-07-10 05:03:27 -07:00
|
|
|
source "drivers/pinctrl/samsung/Kconfig"
|
2024-08-01 17:35:17 -07:00
|
|
|
source "drivers/pinctrl/sophgo/Kconfig"
|
2012-03-28 09:57:07 -07:00
|
|
|
source "drivers/pinctrl/spear/Kconfig"
|
2017-08-16 23:50:38 -07:00
|
|
|
source "drivers/pinctrl/sprd/Kconfig"
|
2022-09-29 23:08:19 -07:00
|
|
|
source "drivers/pinctrl/starfive/Kconfig"
|
2016-01-14 05:16:30 -07:00
|
|
|
source "drivers/pinctrl/stm32/Kconfig"
|
2022-01-16 07:52:14 -07:00
|
|
|
source "drivers/pinctrl/sunplus/Kconfig"
|
2014-04-18 09:53:02 -07:00
|
|
|
source "drivers/pinctrl/sunxi/Kconfig"
|
2016-01-23 08:30:08 -07:00
|
|
|
source "drivers/pinctrl/tegra/Kconfig"
|
pinctrl: Introduce TI IOdelay configuration driver
SoC family such as DRA7 family of processors have, in addition
to the regular muxing of pins (as done by pinctrl-single), a separate
hardware module called IODelay which is also expected to be configured.
The "IODelay" module has it's own register space that is independent
of the control module and the padconf register area.
With recent changes to the pinctrl framework, we can now support
this hardware with a reasonably minimal driver by using #pinctrl-cells,
GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUNCTIONS.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay reconfiguration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do as little of muxing as absolutely necessary
without I/O isolation (which can only be done in initial stages of
bootloader).
NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
family, it is not reasonable to do stop all I/O operations for every
such pad configuration scheme. So, we will let it glitch when used in
this mode.
Even with the above limitation, certain functionality such as MMC has
mandatory need for IODelay reconfiguration requirements, depending on
speed of transfer. In these cases, with careful examination of usecase
involved, the expected glitch can be controlled such that it does not
impact functionality.
In short, IODelay module support as a padconf driver being introduced
here is not expected to do SoC wide I/O Isolation and is meant for
a limited subset of IODelay configuration requirements that need to
be dynamic and whose glitchy behavior will not cause functionality
failure for that interface.
IMPORTANT NOTE: we take the approach of keeping LOCK_BITs cleared
to 0x0 at all times, even when configuring Manual IO Timing Modes.
This is done by eliminating the LOCK_BIT=1 setting from Step
of the Manual IO timing Mode configuration procedure. This option
leaves the CFG_* registers unprotected from unintended writes to the
CTRL_CORE_PAD_* registers while Manual IO Timing Modes are configured.
This approach is taken to allow for a generic driver to exist in kernel
world that has to be used carefully in required usecases.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[tony@atomide.com: updated to use generic pinctrl functions, added
binding documentation, updated comments]
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-05 11:54:14 -07:00
|
|
|
source "drivers/pinctrl/ti/Kconfig"
|
2015-07-13 19:40:01 -07:00
|
|
|
source "drivers/pinctrl/uniphier/Kconfig"
|
2020-09-09 13:43:30 -07:00
|
|
|
source "drivers/pinctrl/visconti/Kconfig"
|
2021-12-09 04:34:56 -07:00
|
|
|
source "drivers/pinctrl/vt8500/Kconfig"
|
2019-11-15 02:25:07 -07:00
|
|
|
|
2017-10-05 22:08:05 -07:00
|
|
|
endif
|