Lines Matching +full:init +full:- +full:b +full:- +full:gpios
9 - Enumerating and naming controllable pins
11 - Multiplexing of pins, pads, fingers (etc) see below for details
13 - Configuration of pins, pads, fingers (etc), such as software-controlled
14 biasing and driving mode specific pins, such as pull-up, pull-down, open drain,
17 Top-level interface
22 - A PIN CONTROLLER is a piece of hardware, usually a set of registers, that
26 - PINS are equal to pads, fingers, balls or whatever packaging input or
30 be sparse - i.e. there may be gaps in the space with numbers where no
39 A B C D E F G H
60 .. code-block:: c
97 See ``arch/arm/mach-ux500/Kconfig`` for an example.
136 .. code-block:: c
183 the groups is up to the driver, this is just a simple example - in practice you
191 Pins can sometimes be software-configured in various ways, mostly related
193 may be able to make an output pin high impedance (Hi-Z), or "tristate" meaning it is
195 using a certain resistor value - pull up and pull down - so that the pin has a
208 .. code-block:: c
274 `Drivers needing both pin control and GPIOs`_ below for details. But in some
275 situations a cross-subsystem mapping between pins and GPIOs is needed.
285 .. code-block:: c
304 .name = "chip b",
322 GPIO chips. "chip a" has 16 pins and "chip b" has 8 pins. The "chip a" and
323 "chip b" have different ``pin_base``, which means a start pin number of the
327 pin range also starts from 32. However "chip b" has different starting
328 offset for the GPIO range and pin range. The GPIO range of "chip b" starts
329 from GPIO number 48, while the pin range of "chip b" starts from 64.
335 - GPIO range : [32 .. 47]
336 - pin range : [32 .. 47]
337 chip b:
338 - GPIO range : [48 .. 55]
339 - pin range : [64 .. 71]
341 The above examples assume the mapping between the GPIOs and pins is
345 .. code-block:: c
363 .. code-block:: c
367 When GPIO-specific functions in the pin control subsystem are called, these
370 pin controller handling the matching range is found, GPIO-specific functions
406 A B C D E F G H
407 +---+
413 +---+---+
415 +---+---+ +---+
421 +-------+-------+-------+---+---+
423 +-------+-------+-------+---+---+
426 are chessboard-like, big ones have "holes" in some arrangement according to
438 some general-purpose GPIO pin. However, in another setting, pins { A5, B5 } can
445 special - it's an external MMC bus that can be 2, 4 or 8 bits wide, and it will
455 Since general-purpose I/O pins (GPIO) are typically always in shortage, it is
471 - FUNCTIONS can be switched in and out by a driver residing with the pin
476 - FUNCTIONS are assumed to be enumerable from zero in a one-dimensional array.
480 - FUNCTIONS have PIN GROUPS as defined on the generic level - so a certain
493 - The combination of a FUNCTION and a PIN GROUP determine a certain function
495 and their machine-specific particulars are kept inside the pinmux driver,
499 - The name of a function with a certain selector (>= 0)
500 - A list of groups associated with a certain function
501 - That a certain group in that list to be activated for a certain function
503 As already described above, pin groups are in turn self-descriptive, so
507 - FUNCTIONS and GROUPS on a certain PIN CONTROLLER are MAPPED to a certain
512 of pins is available for the function, no group name need to be supplied -
520 .. code-block:: c
523 {"map-spi0", spi0, pinctrl0, fspi0, gspi0},
524 {"map-i2c0", i2c0, pinctrl0, fi2c0, gi2c0},
528 function. The group is not compulsory - if it is omitted the first group
537 - PINS for a certain FUNCTION using a certain PIN GROUP on a certain
538 PIN CONTROLLER are provided on a first-come first-serve basis, so if some
544 pads (or "fingers") rather than pins - these are the soldering surfaces on the
581 .. code-block:: c
688 things - when it gets a selector passed in, the pinmux subsystem makes
708 gpiolib-based drivers as part of their ``.request()`` and ``.free()`` semantics.
741 special GPIO-handler is registered.
757 software-control a few electrical properties of the pin that you would
769 | +- SPI
770 Physical pins --- pad --- pinmux -+- I2C
771 | +- mmc
772 | +- GPIO
795 Example **(B)**::
799 | +- SPI
800 Physical pins --- pad --- pinmux -+- I2C
801 | | +- mmc
816 way as (B), the GPIO function still can't be enabled at the same time as the
823 - Registers (or fields within registers) that control electrical
827 - Registers (or fields within registers) that control muxing of signals
831 - Registers (or fields within registers) that control GPIO functionality
845 may be placed at some pin-specific register in all cases or as part
846 of the GPIO register in case (B) especially. This doesn't mean that such
852 If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
863 a certain pin config setting. Look in e.g. ``<linux/pinctrl/pinconf-generic.h>``
874 .. code-block:: c
882 pins_default = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_DEFAULT);
883 pins_sleep = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_SLEEP);
893 .. code-block:: c
904 PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
906 PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
908 PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
909 "u0_group", "gpio-mode"),
910 PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
922 named "gpio-mode" that can be mapped onto the same pins to move them into
931 kernel sense are just some 1-bit line, and is a different use case.
934 configuration and the muxing of the "u0" or "gpio-mode" group onto these
949 together, including how GPIOs and devices are muxed, how regulators are
957 .. code-block:: c
963 .dev_name = "foo-spi.0",
966 .ctrl_dev_name = "pinctrl-foo",
970 .dev_name = "foo-i2c.0",
973 .ctrl_dev_name = "pinctrl-foo",
977 .dev_name = "foo-mmc.0",
980 .ctrl_dev_name = "pinctrl-foo",
994 .. code-block:: c
999 it even more compact which assumes you want to use pinctrl-foo and position
1002 .. code-block:: c
1005 PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1006 "pinctrl-foo", NULL, "i2c0"),
1014 .. code-block:: c
1027 PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1028 "pinctrl-foo", "i2c0", "i2c0"),
1029 PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1030 "pinctrl-foo", "i2c0", i2c_grp_configs),
1031 PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1032 "pinctrl-foo", "i2c0scl", i2c_pin_configs),
1033 PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1034 "pinctrl-foo", "i2c0sda", i2c_pin_configs),
1044 .. code-block:: c
1047 PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT),
1057 .. code-block:: c
1061 .dev_name = "foo-spi.0",
1062 .name = "spi0-pos-A",
1064 .ctrl_dev_name = "pinctrl-foo",
1069 .dev_name = "foo-spi.0",
1070 .name = "spi0-pos-B",
1072 .ctrl_dev_name = "pinctrl-foo",
1084 three groups for a total of 2 + 2 + 4 = 8 pins (for an 8-bit MMC bus as is the
1087 .. code-block:: c
1091 .dev_name = "foo-mmc.0",
1094 .ctrl_dev_name = "pinctrl-foo",
1099 .dev_name = "foo-mmc.0",
1102 .ctrl_dev_name = "pinctrl-foo",
1107 .dev_name = "foo-mmc.0",
1110 .ctrl_dev_name = "pinctrl-foo",
1115 .dev_name = "foo-mmc.0",
1118 .ctrl_dev_name = "pinctrl-foo",
1123 .dev_name = "foo-mmc.0",
1126 .ctrl_dev_name = "pinctrl-foo",
1131 .dev_name = "foo-mmc.0",
1134 .ctrl_dev_name = "pinctrl-foo",
1143 .. code-block:: c
1151 .. code-block:: c
1168 Possible standard state names are: "default", "init", "sleep" and "idle".
1170 - if ``default`` is defined in the device tree, it is selected before
1173 - if ``init`` and ``default`` are defined in the device tree, the "init"
1177 - the ``sleep`` and ``idle`` states are for power management and can only
1182 PM runtime suspend/resume might need to execute the same init sequence as
1187 - ``pinctrl_pm_select_default_state()``
1188 - ``pinctrl_pm_select_init_state()``
1189 - ``pinctrl_pm_select_sleep_state()``
1190 - ``pinctrl_pm_select_idle_state()``
1194 .. code-block:: c
1215 of the type found below. However when doing fine-grained state selection
1232 ``PINCTRL_STATE_SLEEP`` at runtime, re-biasing or even re-muxing pins to save
1244 .. code-block:: c
1260 foo->p = devm_pinctrl_get(&device);
1261 if (IS_ERR(foo->p)) {
1262 ret = PTR_ERR(foo->p);
1263 foo->p = NULL;
1267 foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT);
1268 if (IS_ERR(foo->s)) {
1269 devm_pinctrl_put(foo->p);
1270 return PTR_ERR(foo->s);
1273 ret = pinctrl_select_state(foo->p, foo->s);
1275 devm_pinctrl_put(foo->p);
1286 - ``pinctrl_get()`` is called in process context to obtain a handle to all pinctrl
1291 - ``devm_pinctrl_get()`` is a variant of pinctrl_get() that causes ``pinctrl_put()``
1296 - ``pinctrl_lookup_state()`` is called in process context to obtain a handle to a
1299 - ``pinctrl_select_state()`` programs pin controller hardware according to the
1301 fast-path operation, since it only involved blasting some register settings
1303 registers on a slow/IRQ-based bus, so client devices should not assume they
1304 can call ``pinctrl_select_state()`` from non-blocking contexts.
1306 - ``pinctrl_put()`` frees all information associated with a pinctrl handle.
1308 - ``devm_pinctrl_put()`` is a variant of ``pinctrl_put()`` that may be used to
1328 NOTE: the pinctrl system will return ``-EPROBE_DEFER`` if it cannot find the
1334 Drivers needing both pin control and GPIOs
1342 .. code-block:: c
1367 back-end. This is when the GPIO driver may call out to the functions
1369 above. This only involves per-pin multiplexing, and will be completely
1375 as a back-end for the GPIO driver like this, unless your hardware design
1392 .. code-block:: c
1395 .dev_name = "pinctrl-foo",
1398 .ctrl_dev_name = "pinctrl-foo",
1402 Since it may be common to request the core to hog a few always-applicable
1406 .. code-block:: c
1408 PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */,
1422 "pos-A" and "pos-B".
1426 on the pins defined by group B:
1428 .. code-block:: c
1442 s1 = pinctrl_lookup_state(p, "pos-A");
1446 s2 = pinctrl_lookup_state(p, "pos-B");
1460 /* Enable on position B */
1478 - ``pinctrl-devices``: prints each pin controller device along with columns to
1481 - ``pinctrl-handles``: prints each configured pin controller handle and the
1484 - ``pinctrl-maps``: prints all pinctrl maps
1486 A sub-directory is created inside of ``/sys/kernel/debug/pinctrl`` for each pin
1489 - ``pins``: prints a line for each pin registered on the pin controller. The
1492 - ``gpio-ranges``: prints ranges that map gpio lines to pins on the controller
1494 - ``pingroups``: prints all pin groups registered on the pin controller
1496 - ``pinconf-pins``: prints pin config settings for each pin
1498 - ``pinconf-groups``: prints pin config settings per pin group
1500 - ``pinmux-functions``: prints each pin function along with the pin groups that
1503 - ``pinmux-pins``: iterates through all pins and prints mux owner, gpio owner
1506 - ``pinmux-select``: write to this file to activate a pin function for a group:
1508 .. code-block:: sh
1510 echo "<group-name function-name>" > pinmux-select