- A pin controller is a piece of hardware, usually a set of registers, that
can control PINs. It may be able to multiplex, bias, set load capacitance,
- A pin controller is a piece of hardware, usually a set of registers, that
can control PINs. It may be able to multiplex, bias, set load capacitance,
since these are so tightly integrated with the machines they are used on.
See for example arch/arm/mach-u300/Kconfig for an example.
since these are so tightly integrated with the machines they are used on.
See for example arch/arm/mach-u300/Kconfig for an example.
for your chip. Notice that the core pinctrl.h file provides a fancy macro
called PINCTRL_PIN() to create the struct entries. As you can see I enumerated
the pins from 0 in the upper left corner to 63 in the lower right corner.
for your chip. Notice that the core pinctrl.h file provides a fancy macro
called PINCTRL_PIN() to create the struct entries. As you can see I enumerated
the pins from 0 in the upper left corner to 63 in the lower right corner.
to retrieve the name and pins of the group. Maintaining the data structure of
the groups is up to the driver, this is just a simple example - in practice you
may need more entries in your group structure, for example specific register
to retrieve the name and pins of the group. Maintaining the data structure of
the groups is up to the driver, this is just a simple example - in practice you
may need more entries in your group structure, for example specific register
to their electronic properties when used as inputs or outputs. For example you
may be able to make an output pin high impedance, or "tristate" meaning it is
effectively disconnected. You may be able to connect an input pin to VDD or GND
to their electronic properties when used as inputs or outputs. For example you
may be able to make an output pin high impedance, or "tristate" meaning it is
effectively disconnected. You may be able to connect an input pin to VDD or GND
controller we need a mapping so that the pin control subsystem can figure out
which pin controller handles control of a certain GPIO pin. Since a single
pin controller may be muxing several GPIO ranges (typically SoCs that have
controller we need a mapping so that the pin control subsystem can figure out
which pin controller handles control of a certain GPIO pin. Since a single
pin controller may be muxing several GPIO ranges (typically SoCs that have
For all functionalities dealing with pin biasing, pin muxing etc, the pin
controller subsystem will look up the corresponding pin number from the passed
For all functionalities dealing with pin biasing, pin muxing etc, the pin
controller subsystem will look up the corresponding pin number from the passed
to the chip, and quite a few will be taken by large ports like an external
memory interface. The remaining pins will often be subject to pin multiplexing.
to the chip, and quite a few will be taken by large ports like an external
memory interface. The remaining pins will often be subject to pin multiplexing.
-The example 8x8 PGA package above will have pin numbers 0 thru 63 assigned to
-its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using
+The example 8x8 PGA package above will have pin numbers 0 through 63 assigned
+to its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using
pinctrl_register_pins() and a suitable data set as shown earlier.
In this 8x8 BGA package the pins { A8, A7, A6, A5 } can be used as an SPI port
pinctrl_register_pins() and a suitable data set as shown earlier.
In this 8x8 BGA package the pins { A8, A7, A6, A5 } can be used as an SPI port
of the package the silicon performing the SPI logic can alternatively be routed
out on pins { G4, G3, G2, G1 }.
of the package the silicon performing the SPI logic can alternatively be routed
out on pins { G4, G3, G2, G1 }.
-On the botton row at { A1, B1, C1, D1, E1, F1, G1, H1 } we have something
+On the bottom row at { A1, B1, C1, D1, E1, F1, G1, H1 } we have something
special - it's an external MMC bus that can be 2, 4 or 8 bits wide, and it will
consume 2, 4 or 8 pins respectively, so either { A1, B1 } are taken or
{ A1, B1, C1, D1 } or all of them. If we use all 8 bits, we cannot use the SPI
special - it's an external MMC bus that can be 2, 4 or 8 bits wide, and it will
consume 2, 4 or 8 pins respectively, so either { A1, B1 } are taken or
{ A1, B1, C1, D1 } or all of them. If we use all 8 bits, we cannot use the SPI
We assume that the number of possible function maps to pin groups is limited by
the hardware. I.e. we assume that there is no system where any function can be
We assume that the number of possible function maps to pin groups is limited by
the hardware. I.e. we assume that there is no system where any function can be
a certain function will be limited to a few choices (say up to eight or so),
not hundreds or any amount of choices. This is the characteristic we have found
by inspecting available pinmux hardware, and a necessary assumption since we
a certain function will be limited to a few choices (say up to eight or so),
not hundreds or any amount of choices. This is the characteristic we have found
by inspecting available pinmux hardware, and a necessary assumption since we
the pin controller driver to execute different settings.
It is the responsibility of the pinmux driver to impose further restrictions
the pin controller driver to execute different settings.
It is the responsibility of the pinmux driver to impose further restrictions
whether or not the requested function can actually be allowed, and in case it
is possible to perform the requested mux setting, poke the hardware so that
this happens.
whether or not the requested function can actually be allowed, and in case it
is possible to perform the requested mux setting, poke the hardware so that
this happens.
Note that the following implies that the use case is to use a certain pin
from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
and similar functions. There are cases where you may be using something
Note that the following implies that the use case is to use a certain pin
from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
and similar functions. There are cases where you may be using something
configuration for a certain device. See the section below named
"GPIO mode pitfalls" for more details on this scenario.
configuration for a certain device. See the section below named
"GPIO mode pitfalls" for more details on this scenario.
- Registers (or fields within registers) that control muxing of signals
from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
- Registers (or fields within registers) that control muxing of signals
from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
- Registers (or fields within registers) that control GPIO functionality
such as setting a GPIO's output value, reading a GPIO's input value, or
- Registers (or fields within registers) that control GPIO functionality
such as setting a GPIO's output value, reading a GPIO's input value, or
system sleep, we need to put this pin into "GPIO mode" and ground it.
If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
system sleep, we need to put this pin into "GPIO mode" and ground it.
If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
pin shall be used for UART TX and GPIO at the same time, that you will grab
a pin control handle and set it to a certain state to enable UART TX to be
muxed in, then twist it over to GPIO mode and use gpio_direction_output()
pin shall be used for UART TX and GPIO at the same time, that you will grab
a pin control handle and set it to a certain state to enable UART TX to be
muxed in, then twist it over to GPIO mode and use gpio_direction_output()
This will give the desired effect without any bogus interaction with the
GPIO subsystem. It is just an electrical configuration used by that device
when going to sleep, it might imply that the pin is set into something the
This will give the desired effect without any bogus interaction with the
GPIO subsystem. It is just an electrical configuration used by that device
when going to sleep, it might imply that the pin is set into something the
by that UART device to control the pins that pertain to that very UART
driver, putting them into modes needed by the UART. GPIO in the Linux
kernel sense are just some 1-bit line, and is a different use case.
by that UART device to control the pins that pertain to that very UART
driver, putting them into modes needed by the UART. GPIO in the Linux
kernel sense are just some 1-bit line, and is a different use case.
configuration and the muxing of the "u0" or "gpio-mode" group onto these
pins is a question for the driver.
configuration and the muxing of the "u0" or "gpio-mode" group onto these
pins is a question for the driver.
"low power mode" rather than anything to do with GPIO. This often means
the same thing electrically speaking, but in this latter case the
software engineers will usually quickly identify that this is some
"low power mode" rather than anything to do with GPIO. This often means
the same thing electrically speaking, but in this latter case the
software engineers will usually quickly identify that this is some
must match a function provided by the pinmux driver handling this pin range.
As you can see we may have several pin controllers on the system and thus
must match a function provided by the pinmux driver handling this pin range.
As you can see we may have several pin controllers on the system and thus
fast-path operation, since it only involved blasting some register settings
into hardware. However, note that some pin controllers may have their
registers on a slow/IRQ-based bus, so client devices should not assume they
fast-path operation, since it only involved blasting some register settings
into hardware. However, note that some pin controllers may have their
registers on a slow/IRQ-based bus, so client devices should not assume they