Lines Matching +full:p +full:- +full:states
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
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
275 situations a cross-subsystem mapping between pins and GPIOs is needed.
285 .. code-block:: c
335 - GPIO range : [32 .. 47]
336 - pin range : [32 .. 47]
338 - GPIO range : [48 .. 55]
339 - pin range : [64 .. 71]
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
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
799 | +- SPI
800 Physical pins --- pad --- pinmux -+- I2C
801 | | +- mmc
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
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
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),
1038 named states. When running on hardware that doesn't need any pin controller
1039 configuration, the mapping table must still contain those named states, in
1040 order to explicitly indicate that the states were provided and intended to
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
1145 p = devm_pinctrl_get(dev);
1146 s = pinctrl_lookup_state(p, "8bit");
1147 ret = pinctrl_select_state(p, s);
1151 .. code-block:: c
1153 p = devm_pinctrl_get_select(dev, "8bit");
1166 standard states if they are defined in the device tree by calling
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
1183 during probe. Since the predefined states are already attached to the
1184 device, the driver can activate these states explicitly with the
1187 - ``pinctrl_pm_select_default_state()``
1188 - ``pinctrl_pm_select_init_state()``
1189 - ``pinctrl_pm_select_sleep_state()``
1190 - ``pinctrl_pm_select_idle_state()``
1192 For example, if resuming the device depend on certain pinmux states
1194 .. code-block:: c
1215 of the type found below. However when doing fine-grained state selection
1217 handling of the pinctrl handles and states.
1232 ``PINCTRL_STATE_SLEEP`` at runtime, re-biasing or even re-muxing pins to save
1244 .. code-block:: c
1249 struct pinctrl *p;
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
1337 Again, it is discouraged to let drivers lookup and select pin control states
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 */,
1421 "Advanced mapping" above. So that for an SPI device, we have two states named
1422 "pos-A" and "pos-B".
1428 .. code-block:: c
1432 struct pinctrl *p;
1438 p = devm_pinctrl_get(&device);
1439 if (IS_ERR(p))
1442 s1 = pinctrl_lookup_state(p, "pos-A");
1446 s2 = pinctrl_lookup_state(p, "pos-B");
1454 ret = pinctrl_select_state(p, s1);
1461 ret = pinctrl_select_state(p, s2);
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