UPSTREAM: pinctrl: Add pinmux property support to pinctrl-generic

The pinmux property allows for smaller and more compact device trees,
especially when there are many pins which need to be assigned

UPSTREAM: pinctrl: Add pinmux property support to pinctrl-generic

The pinmux property allows for smaller and more compact device trees,
especially when there are many pins which need to be assigned individually.
Instead of specifying an array of strings to be parsed as pins and a
function property, the pinmux property contains an array of integers
representing pinmux groups. A pinmux group consists of the pin identifier
and mux settings represented as a single integer or an array of integers.
Each individual pin controller driver specifies the exact format of a
pinmux group. As specified in the Linux documentation, a pinmux group may
be multiple integers long. However, no existing drivers use multi-integer
pinmux groups, so I have chosen to omit this feature. This makes the
implementation easier, since there is no need to allocate a buffer to do
endian conversions.

Support for the pinmux property is done differently than in Linux. As far
as I can tell, inversion of control is used when implementing support for
the pins and groups properties to avoid allocating. This results in some
duplication of effort; every property in a config node is parsed once for
each pin in that node. This is not such an overhead with pins and groups
properties, since having multiple pins in one config node does not occur
especially often. However, the semantics of the pinmux property make such a
configuration much more appealing. A future patch could parse all config
properties at once and store them in an array. This would make it easier to
create drivers which do not function solely as callbacks from
pinctrl-generic.

This commit increases the size of the sandbox build by approximately 48
bytes. However, it also decreases the size of the K210 device tree by 2
KiB from the previous version of this series.

The documentation has been updated from the last Linux commit before it was
split off into yaml files.

Change-Id: I25c7920371f950c5fece54492d5eae8e013529d5
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 9c08fbfc951fa90953b75462e5dff533c0031a4d)
Signed-off-by: Cody Xie <cody.xie@rock-chips.com>

show more ...

UPSTREAM: cmd: pinmux: Add pinmux command

pinmux command allows to :
- list all pin-controllers available on platforms
- select a pin-controller
- display the muxing of all pins of the current pi

UPSTREAM: cmd: pinmux: Add pinmux command

pinmux command allows to :
- list all pin-controllers available on platforms
- select a pin-controller
- display the muxing of all pins of the current pin-controller
or all pin-controllers depending of given options

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
cmd: pinmux: Fix pinmux command

if "pinmux status" command is used without having
set dev using "pinmux dev", print pinmux usage
Reviewed-by: Simon Glass <sjg@chromium.org>

(cherry picked from commit d5a8313905f54ebdf128ac428c3cf58a2ebcbda2)
Change-Id: Ie23ca7b987bceb83724c3ddea42eddb579dc0ea5
Signed-off-by: Cody Xie <cody.xie@rock-chips.com>

show more ...

UPSTREAM: pinctrl: gpio: Add callback for configuring pin as GPIO

Add callback to configure, and de-configure, pin as a GPIO on the
pin controller side. This matches similar functionality in Linux
a

UPSTREAM: pinctrl: gpio: Add callback for configuring pin as GPIO

Add callback to configure, and de-configure, pin as a GPIO on the
pin controller side. This matches similar functionality in Linux
and aims to replace the ad-hoc implementations present in U-Boot.

Change-Id: Ic4c1e898c6c1054193e49bd011358008c1e4007e
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Alex Kiernan <alex.kiernan@gmail.com>
Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Cc: Eugeniu Rosca <roscaeugeniu@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Patrick DELAUNAY <patrick.delaunay@st.com>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Cc: Simon Glass <sjg@chromium.org>
(cherry picked from commit ae59d7ca59dbfc770531f51c717dc6f5d9a18f78)
Signed-off-by: Cody Xie <cody.xie@rock-chips.com>

show more ...

UPSTREAM: dm: pinctrl: Add get_pin_muxing() ops

Add get_pin_muxing() which allows to display the muxing
of a given pin belonging to a pin-controller.

Change-Id: Icbc3b41ae38b695403f5757c1c0fb0a4155

UPSTREAM: dm: pinctrl: Add get_pin_muxing() ops

Add get_pin_muxing() which allows to display the muxing
of a given pin belonging to a pin-controller.

Change-Id: Icbc3b41ae38b695403f5757c1c0fb0a4155e4dcd
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit f55a0c0a20cad56440ebe9a9b2999f21ae00f61a)
Signed-off-by: Cody Xie <cody.xie@rock-chips.com>

show more ...

UPSTREAM: dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count

Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods
to obtain pin's name and pin's muxing given a pin reference

UPSTREAM: dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count

Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods
to obtain pin's name and pin's muxing given a pin reference.

This will be used by the new pinmux command.

Change-Id: I478e164107a547fb7dc73743481d106c4c9ec533
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 8bbb5b20852aa81024eb7b2dcc3eb58275e83bb0)
Signed-off-by: Cody Xie <cody.xie@rock-chips.com>

show more ...

pinctrl: support to build without pinctrl driver

Change-Id: I353d4a761d42ad2a22f94cc72dfeb7724e288061
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

pinctrl: export pinctrl_get_pins_count as generic API

Change-Id: I0c5e4977b068a09276a1d0561058679bd1791e0a
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

dm: pinctrl: Add a way for a GPIO driver to obtain a pin function

GPIO drivers want to be able to show if a pin is enabled for input, output,
or is being used by another function. Some drivers can e

dm: pinctrl: Add a way for a GPIO driver to obtain a pin function

GPIO drivers want to be able to show if a pin is enabled for input, output,
or is being used by another function. Some drivers can easily find this
and the code is included in the driver. For some SoCs this is more complex.
Conceptually this should be handled by pinctrl rather than GPIO. Most
pinctrl drivers will have this feature anyway.

Add a method by which a GPIO driver can obtain the pin mux value given a
GPIO reference. This avoids repeating the code in two places.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

dm: pinctrl: Add a function to parse PIN_CONFIG flags

Add a function which produces a flags word from a few common PIN_CONFIG
settings. This is useful for simple pinctrl drivers that don't need to w

dm: pinctrl: Add a function to parse PIN_CONFIG flags

Add a function which produces a flags word from a few common PIN_CONFIG
settings. This is useful for simple pinctrl drivers that don't need to worry
about drive strength, etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

Merge git://git.denx.de/u-boot-rockchip

pinctrl: Add the concept of peripheral IDs

My original pinctrl patch operating using a peripheral ID enum. This was
shared between pinmux and clock and provides an easy way to specify a device
that

pinctrl: Add the concept of peripheral IDs

My original pinctrl patch operating using a peripheral ID enum. This was
shared between pinmux and clock and provides an easy way to specify a device
that needs to be controlled, even it is does not (yet) have a driver within
driver model.

Masahiro's new simple pinctrl gets around this by providing a
set_state_simple() pinctrl method. By passing a device to that call the
peripheral ID becomes unnecessary. If the driver needs it, it can calculate
it itself and use it internally.

However this does not solve the problem for peripheral clocks. The 'pure'
solution would be to pass a driver to the clock uclass also. But this
requires that all devices should have a driver, and a struct udevide. Also
a key optimisation of the clock uclass is allowing a peripheral clock to
be set even when there is no device for that clock.

There may be a better way to achive the same goal, but for now it seems
expedient to add in peripheral ID to the pinctrl uclass. Two methods are
added - one to get the peripheral ID and one to select it. The existing
set_state_simple() is effectively the union of these.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

Merge git://git.denx.de/u-boot-dm

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

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>

show more ...