pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
#
|
|
|
|
# PINCTRL infrastructure and drivers
|
|
|
|
#
|
|
|
|
|
|
|
|
menu "Pin controllers"
|
|
|
|
|
|
|
|
config PINCTRL
|
|
|
|
bool "Support pin controllers"
|
|
|
|
depends on DM
|
|
|
|
help
|
|
|
|
This enables the basic support for pinctrl framework. You may want
|
|
|
|
to enable some more options depending on what you want to do.
|
|
|
|
|
|
|
|
config PINCTRL_FULL
|
|
|
|
bool "Support full pin controllers"
|
|
|
|
depends on PINCTRL && OF_CONTROL
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This provides Linux-compatible device tree interface for the pinctrl
|
|
|
|
subsystem. This feature depends on device tree configuration because
|
|
|
|
it parses a device tree to look for the pinctrl device which the
|
|
|
|
peripheral device is associated with.
|
|
|
|
|
|
|
|
If this option is disabled (it is the only possible choice for non-DT
|
|
|
|
boards), the pinctrl core provides no systematic mechanism for
|
|
|
|
identifying peripheral devices, applying needed pinctrl settings.
|
|
|
|
It is totally up to the implementation of each low-level driver.
|
|
|
|
You can save memory footprint in return for some limitations.
|
|
|
|
|
|
|
|
config PINCTRL_GENERIC
|
|
|
|
bool "Support generic pin controllers"
|
|
|
|
depends on PINCTRL_FULL
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Say Y here if you want to use the pinctrl subsystem through the
|
|
|
|
generic DT interface. If enabled, some functions become available
|
|
|
|
to parse common properties such as "pins", "groups", "functions" and
|
|
|
|
some pin configuration parameters. It would be easier if you only
|
|
|
|
need the generic DT interface for pin muxing and pin configuration.
|
|
|
|
If you need to handle vendor-specific DT properties, you can disable
|
|
|
|
this option and implement your own set_state callback in the pinctrl
|
|
|
|
operations.
|
|
|
|
|
|
|
|
config PINMUX
|
|
|
|
bool "Support pin multiplexing controllers"
|
|
|
|
depends on PINCTRL_GENERIC
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option enables pin multiplexing through the generic pinctrl
|
2018-03-02 08:56:00 +00:00
|
|
|
framework. Most SoCs have their own multiplexing arrangement where
|
|
|
|
a single pin can be used for several functions. An SoC pinctrl driver
|
|
|
|
allows the required function to be selected for each pin.
|
2015-08-30 22:55:12 +00:00
|
|
|
The driver is typically controlled by the device tree.
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
|
|
|
|
config PINCONF
|
|
|
|
bool "Support pin configuration controllers"
|
|
|
|
depends on PINCTRL_GENERIC
|
|
|
|
help
|
|
|
|
This option enables pin configuration through the generic pinctrl
|
|
|
|
framework.
|
|
|
|
|
2019-08-02 12:48:00 +00:00
|
|
|
config PINCONF_RECURSIVE
|
|
|
|
bool "Support recursive binding for pin configuration nodes"
|
|
|
|
depends on PINCTRL_FULL
|
|
|
|
default n if ARCH_STM32MP
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
In the Linux pinctrl binding, the pin configuration nodes need not be
|
|
|
|
direct children of the pin controller device (may be grandchildren for
|
|
|
|
example). It is define is each individual pin controller device.
|
|
|
|
Say Y here if you want to keep this behavior with the pinconfig
|
|
|
|
u-class: all sub are recursivelly bounded.
|
|
|
|
If the option is disabled, this behavior is deactivated and only
|
|
|
|
the direct children of pin controller will be assumed as pin
|
|
|
|
configuration; you can save memory footprint when this feature is
|
|
|
|
no needed.
|
|
|
|
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
config SPL_PINCTRL
|
2017-07-26 10:27:42 +00:00
|
|
|
bool "Support pin controllers in SPL"
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
depends on SPL && SPL_DM
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the PINCTRL option.
|
|
|
|
See the help of PINCTRL for details.
|
|
|
|
|
2019-12-07 04:41:45 +00:00
|
|
|
config TPL_PINCTRL
|
|
|
|
bool "Support pin controllers in TPL"
|
|
|
|
depends on TPL && TPL_DM
|
|
|
|
help
|
|
|
|
This option is an TPL variant of the PINCTRL option.
|
|
|
|
See the help of PINCTRL for details.
|
|
|
|
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
config SPL_PINCTRL_FULL
|
|
|
|
bool "Support full pin controllers in SPL"
|
|
|
|
depends on SPL_PINCTRL && SPL_OF_CONTROL
|
2017-05-28 19:55:10 +00:00
|
|
|
default n if TARGET_STM32F746_DISCO
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the PINCTRL_FULL option.
|
|
|
|
See the help of PINCTRL_FULL for details.
|
|
|
|
|
2019-12-07 04:41:45 +00:00
|
|
|
config TPL_PINCTRL_FULL
|
|
|
|
bool "Support full pin controllers in TPL"
|
|
|
|
depends on TPL_PINCTRL && TPL_OF_CONTROL
|
|
|
|
help
|
|
|
|
This option is an TPL-variant of the PINCTRL_FULL option.
|
|
|
|
See the help of PINCTRL_FULL for details.
|
|
|
|
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
config SPL_PINCTRL_GENERIC
|
|
|
|
bool "Support generic pin controllers in SPL"
|
|
|
|
depends on SPL_PINCTRL_FULL
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the PINCTRL_GENERIC option.
|
|
|
|
See the help of PINCTRL_GENERIC for details.
|
|
|
|
|
|
|
|
config SPL_PINMUX
|
|
|
|
bool "Support pin multiplexing controllers in SPL"
|
|
|
|
depends on SPL_PINCTRL_GENERIC
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the PINMUX option.
|
|
|
|
See the help of PINMUX for details.
|
2015-08-30 22:55:12 +00:00
|
|
|
The pinctrl subsystem can add a substantial overhead to the SPL
|
|
|
|
image since it typically requires quite a few tables either in the
|
|
|
|
driver or in the device tree. If this is acceptable and you need
|
|
|
|
to adjust pin multiplexing in SPL in order to boot into U-Boot,
|
|
|
|
enable this option. You will need to enable device tree in SPL
|
|
|
|
for this to work.
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
|
|
|
|
config SPL_PINCONF
|
|
|
|
bool "Support pin configuration controllers in SPL"
|
|
|
|
depends on SPL_PINCTRL_GENERIC
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the PINCONF option.
|
|
|
|
See the help of PINCONF for details.
|
|
|
|
|
2019-08-02 12:48:00 +00:00
|
|
|
config SPL_PINCONF_RECURSIVE
|
|
|
|
bool "Support recursive binding for pin configuration nodes in SPL"
|
|
|
|
depends on SPL_PINCTRL_FULL
|
|
|
|
default n if ARCH_STM32MP
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the PINCONF_RECURSIVE option.
|
|
|
|
See the help of PINCONF_RECURSIVE for details.
|
|
|
|
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
if PINCTRL || SPL_PINCTRL
|
|
|
|
|
2017-04-19 14:46:37 +00:00
|
|
|
config PINCTRL_AR933X
|
2016-03-16 08:59:55 +00:00
|
|
|
bool "QCA/Athores ar933x pin control driver"
|
|
|
|
depends on DM && SOC_AR933X
|
|
|
|
help
|
|
|
|
Support pin multiplexing control on QCA/Athores ar933x SoCs.
|
|
|
|
The driver is controlled by a device tree node which contains
|
|
|
|
both the GPIO definitions and pin control functions for each
|
|
|
|
available multiplex function.
|
|
|
|
|
2017-04-19 14:46:37 +00:00
|
|
|
config PINCTRL_AT91
|
|
|
|
bool "AT91 pinctrl driver"
|
|
|
|
depends on DM
|
|
|
|
help
|
|
|
|
This option is to enable the AT91 pinctrl driver for AT91 PIO
|
|
|
|
controller.
|
|
|
|
|
|
|
|
AT91 PIO controller is a combined gpio-controller, pin-mux and
|
|
|
|
pin-config module. Each I/O pin may be dedicated as a general-purpose
|
|
|
|
I/O or be assigned to a function of an embedded peripheral. Each I/O
|
|
|
|
pin has a glitch filter providing rejection of glitches lower than
|
|
|
|
one-half of peripheral clock cycle and a debouncing filter providing
|
|
|
|
rejection of unwanted pulses from key or push button operations. You
|
|
|
|
can also control the multi-driver capability, pull-up and pull-down
|
|
|
|
feature on each I/O pin.
|
|
|
|
|
|
|
|
config PINCTRL_AT91PIO4
|
|
|
|
bool "AT91 PIO4 pinctrl driver"
|
|
|
|
depends on DM
|
|
|
|
help
|
|
|
|
This option is to enable the AT91 pinctrl driver for AT91 PIO4
|
|
|
|
controller which is available on SAMA5D2 SoC.
|
|
|
|
|
|
|
|
config PINCTRL_PIC32
|
|
|
|
bool "Microchip PIC32 pin-control and pin-mux driver"
|
|
|
|
depends on DM && MACH_PIC32
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Supports individual pin selection and configuration for each
|
|
|
|
remappable peripheral available on Microchip PIC32
|
|
|
|
SoCs. This driver is controlled by a device tree node which
|
2019-01-13 09:13:26 +00:00
|
|
|
contains both GPIO definition and pin control functions.
|
2017-04-19 14:46:37 +00:00
|
|
|
|
|
|
|
config PINCTRL_QCA953X
|
2016-03-16 08:59:56 +00:00
|
|
|
bool "QCA/Athores qca953x pin control driver"
|
|
|
|
depends on DM && SOC_QCA953X
|
|
|
|
help
|
|
|
|
Support pin multiplexing control on QCA/Athores qca953x SoCs.
|
|
|
|
|
2017-04-19 14:46:37 +00:00
|
|
|
The driver is controlled by a device tree node which contains both
|
|
|
|
the GPIO definitions and pin control functions for each available
|
|
|
|
multiplex function.
|
|
|
|
|
2017-06-01 10:00:10 +00:00
|
|
|
config PINCTRL_ROCKCHIP_RV1108
|
|
|
|
bool "Rockchip rv1108 pin control driver"
|
|
|
|
depends on DM
|
|
|
|
help
|
|
|
|
Support pin multiplexing control on Rockchip rv1108 SoC.
|
|
|
|
|
|
|
|
The driver is controlled by a device tree node which contains
|
|
|
|
both the GPIO definitions and pin control functions for each
|
|
|
|
available multiplex function.
|
|
|
|
|
2015-08-27 03:44:30 +00:00
|
|
|
config PINCTRL_SANDBOX
|
|
|
|
bool "Sandbox pinctrl driver"
|
|
|
|
depends on SANDBOX
|
|
|
|
help
|
2017-04-19 14:46:37 +00:00
|
|
|
This enables pinctrl driver for sandbox.
|
2015-08-27 03:44:30 +00:00
|
|
|
|
2017-04-19 14:46:37 +00:00
|
|
|
Currently, this driver actually does nothing but print debug
|
|
|
|
messages when pinctrl operations are invoked.
|
|
|
|
|
|
|
|
config PINCTRL_SINGLE
|
|
|
|
bool "Single register pin-control and pin-multiplex driver"
|
|
|
|
depends on DM
|
2016-01-28 10:00:12 +00:00
|
|
|
help
|
2017-04-19 14:46:37 +00:00
|
|
|
This enables pinctrl driver for systems using a single register for
|
|
|
|
pin configuration and multiplexing. TI's AM335X SoCs are examples of
|
|
|
|
such systems.
|
|
|
|
|
|
|
|
Depending on the platform make sure to also enable OF_TRANSLATE and
|
|
|
|
eventually SPL_OF_TRANSLATE to get correct address translations.
|
2016-01-28 10:00:12 +00:00
|
|
|
|
2017-02-21 12:37:10 +00:00
|
|
|
config PINCTRL_STI
|
|
|
|
bool "STMicroelectronics STi pin-control and pin-mux driver"
|
|
|
|
depends on DM && ARCH_STI
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Support pin multiplexing control on STMicrolectronics STi SoCs.
|
2017-04-19 14:46:37 +00:00
|
|
|
|
2017-02-21 12:37:10 +00:00
|
|
|
The driver is controlled by a device tree node which contains both
|
2017-04-19 14:46:37 +00:00
|
|
|
the GPIO definitions and pin control functions for each available
|
|
|
|
multiplex function.
|
2017-02-21 12:37:10 +00:00
|
|
|
|
2017-02-12 18:25:49 +00:00
|
|
|
config PINCTRL_STM32
|
|
|
|
bool "ST STM32 pin control driver"
|
|
|
|
depends on DM
|
|
|
|
help
|
2017-04-19 14:46:37 +00:00
|
|
|
Supports pin multiplexing control on stm32 SoCs.
|
2017-02-12 18:25:49 +00:00
|
|
|
|
2017-04-19 14:46:37 +00:00
|
|
|
The driver is controlled by a device tree node which contains both
|
|
|
|
the GPIO definitions and pin control functions for each available
|
|
|
|
multiplex function.
|
2017-03-22 10:26:44 +00:00
|
|
|
|
2019-03-11 10:13:15 +00:00
|
|
|
config PINCTRL_STMFX
|
|
|
|
bool "STMicroelectronics STMFX I2C GPIO expander pinctrl driver"
|
|
|
|
depends on DM && PINCTRL_FULL
|
|
|
|
help
|
|
|
|
I2C driver for STMicroelectronics Multi-Function eXpander (STMFX)
|
|
|
|
GPIO expander.
|
|
|
|
Supports pin multiplexing control on stm32 SoCs.
|
|
|
|
|
|
|
|
The driver is controlled by a device tree node which contains both
|
|
|
|
the GPIO definitions and pin control functions for each available
|
|
|
|
multiplex function.
|
|
|
|
|
|
|
|
config SPL_PINCTRL_STMFX
|
|
|
|
bool "STMicroelectronics STMFX I2C GPIO expander pinctrl driver in SPL"
|
|
|
|
depends on SPL_PINCTRL_FULL
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the SPL_PINCTRL_STMFX option.
|
|
|
|
See the help of PINCTRL_STMFX for details.
|
|
|
|
|
2017-04-17 19:00:27 +00:00
|
|
|
config ASPEED_AST2500_PINCTRL
|
|
|
|
bool "Aspeed AST2500 pin control driver"
|
|
|
|
depends on DM && PINCTRL_GENERIC && ASPEED_AST2500
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Support pin multiplexing control on Aspeed ast2500 SoC. The driver uses
|
|
|
|
Generic Pinctrl framework and is compatible with the Linux driver,
|
|
|
|
i.e. it uses the same device tree configuration.
|
|
|
|
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
endif
|
|
|
|
|
2019-02-01 14:11:48 +00:00
|
|
|
source "drivers/pinctrl/broadcom/Kconfig"
|
|
|
|
source "drivers/pinctrl/exynos/Kconfig"
|
2018-11-15 02:07:58 +00:00
|
|
|
source "drivers/pinctrl/mediatek/Kconfig"
|
2019-02-01 14:11:48 +00:00
|
|
|
source "drivers/pinctrl/meson/Kconfig"
|
|
|
|
source "drivers/pinctrl/mscc/Kconfig"
|
2019-09-25 09:45:26 +00:00
|
|
|
source "drivers/pinctrl/mtmips/Kconfig"
|
2019-02-01 14:11:48 +00:00
|
|
|
source "drivers/pinctrl/mvebu/Kconfig"
|
pinctrl: imx: Introduce pinctrl driver for i.MX6
Introduce pinctrl for i.MX6
1. pinctrl-imx.c is for common usage. It's used by i.MX6/7.
2. Add PINCTRL_IMX PINCTRL_IMX6 Kconfig entry.
3. To the pinctrl_ops implementation, only set_state is implemented.
To i.MX6/7, the pinctrl dts entry is as following:
&iomuxc {
pinctrl-names = "default";
pinctrl_csi1: csi1grp {
fsl,pins = <
MX6UL_PAD_CSI_MCLK__CSI_MCLK 0x1b088
MX6UL_PAD_CSI_PIXCLK__CSI_PIXCLK 0x1b088
MX6UL_PAD_CSI_VSYNC__CSI_VSYNC 0x1b088
>;
};
[.....]
};
there is no property named function or groups. So pinctrl_generic_set_state
can not be used here.
5. This driver is a simple implementation for i.mx iomux controller,
only parse the fsl,pins property and write value to registers.
6. With DEBUG enabled, we can see log when "i2c bus 0":
"
set_state_simple op missing
imx_pinctrl_set_state: i2c1grp
mux_reg 0x14c, conf_reg 0x3bc, input_reg 0x5d8, mux_mode 0x0, input_val 0x1, config_val 0x4000007f
write mux: offset 0x14c val 0x10
select_input: offset 0x5d8 val 0x1
write config: offset 0x3bc val 0x7f
mux_reg 0x148, conf_reg 0x3b8, input_reg 0x5d4, mux_mode 0x0, input_val 0x1, config_val 0x4000007f
write mux: offset 0x148 val 0x10
select_input: offset 0x5d4 val 0x1
write config: offset 0x3b8 val 0x7f
"
this means imx6 pinctrl driver works as expected.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-02-03 02:06:07 +00:00
|
|
|
source "drivers/pinctrl/nxp/Kconfig"
|
2017-09-15 19:13:55 +00:00
|
|
|
source "drivers/pinctrl/renesas/Kconfig"
|
2019-02-01 14:15:38 +00:00
|
|
|
source "drivers/pinctrl/rockchip/Kconfig"
|
2015-09-11 11:17:32 +00:00
|
|
|
source "drivers/pinctrl/uniphier/Kconfig"
|
|
|
|
|
pinctrl: add pin control uclass support
This creates a new framework for handling of pin control devices,
i.e. devices that control different aspects of package pins.
This uclass handles pinmuxing and pin configuration; pinmuxing
controls switching among silicon blocks that share certain physical
pins, pin configuration handles electronic properties such as pin-
biasing, load capacitance etc.
This framework can support the same device tree bindings, but if you
do not need full interface support, you can disable some features to
reduce memory foot print. Typically around 1.5KB is necessary to
include full-featured uclass support on ARM board (CONFIG_PINCTRL +
CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX),
for example.
We are often limited on code size for SPL. Besides, we still have
many boards that do not support device tree configuration. The full
pinctrl, which requires OF_CONTROL, does not make sense for those
boards. So, this framework also has a Do-It-Yourself (let's say
simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the
uclass itself provides no systematic mechanism for identifying the
peripheral device, applying pinctrl settings, etc. They must be
done in each low-level driver. In return, you can save much memory
footprint and it might be useful especially for SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
|
|
|
endmenu
|