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
|
2015-08-30 22:55:12 +00:00
|
|
|
framework. Most SoCs have their own 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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
config SPL_PINCTRL
|
|
|
|
bool "Support pin controlloers in SPL"
|
|
|
|
depends on SPL && SPL_DM
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the PINCTRL option.
|
|
|
|
See the help of PINCTRL for details.
|
|
|
|
|
|
|
|
config SPL_PINCTRL_FULL
|
|
|
|
bool "Support full pin controllers in SPL"
|
|
|
|
depends on SPL_PINCTRL && SPL_OF_CONTROL
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option is an SPL-variant of the PINCTRL_FULL option.
|
|
|
|
See the help of PINCTRL_FULL for details.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
if PINCTRL || SPL_PINCTRL
|
|
|
|
|
2016-03-16 08:59:55 +00:00
|
|
|
config AR933X_PINCTRL
|
|
|
|
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.
|
|
|
|
|
2016-03-16 08:59:56 +00:00
|
|
|
config QCA953X_PINCTRL
|
|
|
|
bool "QCA/Athores qca953x pin control driver"
|
|
|
|
depends on DM && SOC_QCA953X
|
|
|
|
help
|
|
|
|
Support pin multiplexing control on QCA/Athores qca953x 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.
|
|
|
|
|
2015-08-30 22:55:35 +00:00
|
|
|
config ROCKCHIP_PINCTRL
|
|
|
|
bool "Rockchip pin control driver"
|
|
|
|
depends on DM
|
|
|
|
help
|
|
|
|
Support pin multiplexing control on Rockchip 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.
|
|
|
|
|
2015-11-17 06:20:20 +00:00
|
|
|
config ROCKCHIP_3036_PINCTRL
|
|
|
|
bool "Rockchip rk3036 pin control driver"
|
|
|
|
depends on DM
|
|
|
|
help
|
|
|
|
Support pin multiplexing control on Rockchip rk3036 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.
|
|
|
|
|
2015-08-27 03:44:30 +00:00
|
|
|
config PINCTRL_SANDBOX
|
|
|
|
bool "Sandbox pinctrl driver"
|
|
|
|
depends on SANDBOX
|
|
|
|
help
|
|
|
|
This enables pinctrl driver for sandbox. Currently, this driver
|
|
|
|
actually does nothing but print debug messages when pinctrl
|
|
|
|
operations are invoked.
|
|
|
|
|
2016-01-28 10:00:12 +00:00
|
|
|
config PIC32_PINCTRL
|
|
|
|
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 contains both GPIO defintion and pin control
|
|
|
|
functions.
|
|
|
|
|
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
|
|
|
|
|
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"
|
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
|