Lines Matching +full:function +full:- +full:group
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.
127 actual enumerated pins that are part of a certain group.
129 For example, say that we have a group of pins dealing with an SPI interface
130 on { 0, 8, 16, 24 }, and a group of pins dealing with an I2C interface on pins
136 .. code-block:: c
180 The pin control subsystem will call the ``.get_groups_count()`` function to
182 to retrieve the name and pins of the group. Maintaining the data structure of
183 the groups is up to the driver, this is just a simple example - in practice you
184 may need more entries in your group structure, for example specific register
185 ranges associated with each group and so on.
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
359 group is known, the pins and npins elements of the above structure can be
360 initialised using the function ``pinctrl_get_group_pins()``, e.g. for pin
361 group "foo":
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
401 system, even though the framework makes it possible to also change the function
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
481 function is *always* associated with a certain set of pin groups, could
483 function i2c is associated with the pins { A5, B5 }, enumerated as
486 The Function spi is associated with pin groups { A8, A7, A6, A5 }
490 Group names must be unique per pin controller, no two groups on the same
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
504 the core will retrieve the actual pin range in a certain group from the
507 - FUNCTIONS and GROUPS on a certain PIN CONTROLLER are MAPPED to a certain
510 name. Defining a pin controller, function and group thus uniquely identify
511 the set of pins to be used by a certain device. (If only one possible group
512 of pins is available for the function, no group name need to be supplied -
513 the core will simply select the first and only group available.)
516 use device spi0 with pinmux function fspi0 group gspi0 and i2c0 on function
517 fi2c0 group gi2c0, on the primary pin controller, we get mappings
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
529 presented by the driver as applicable for the function will be selected,
533 pin controller and function. This is for cases where a certain function on
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
551 We assume that the number of possible function maps to pin groups is limited by
552 the hardware. I.e. we assume that there is no system where any function can be
554 a certain function will be limited to a few choices (say up to eight or so),
557 expect pinmux drivers to present *all* possible function vs pin group mappings
569 whether or not the requested function can actually be allowed, and in case it
574 optional. Usually the ``.set_mux()`` function is implemented, writing values into
578 into some register named MUX to select a certain function with a certain
579 group of pins would work something like this:
581 .. code-block:: c
658 unsigned int group)
660 u8 regbit = BIT(group);
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.
717 The function list could become long, especially if you can convert every
719 the approach to define every pin as a function.
721 In this case, the function array would become 64 entries for each GPIO
728 This function will pass in the affected GPIO range identified by the pin
734 ``.gpio_set_direction()`` function. As described this shall be called from the
736 will be passed along to this function.
740 obtain the function "gpioN" where "N" is the global GPIO pin number if no
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
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
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",
920 function called "u0" that can be enabled on this group of pins, and then
921 everything is UART business as usual. But there is also some function
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
955 and spi on the second function mapping:
957 .. code-block:: c
963 .dev_name = "foo-spi.0",
966 .ctrl_dev_name = "pinctrl-foo",
967 .data.mux.function = "spi0",
970 .dev_name = "foo-i2c.0",
973 .ctrl_dev_name = "pinctrl-foo",
974 .data.mux.function = "i2c0",
977 .dev_name = "foo-mmc.0",
980 .ctrl_dev_name = "pinctrl-foo",
981 .data.mux.function = "mmc0",
986 up the device struct (just like with clockdev or regulators). The function name
987 must match a function provided by the pinmux driver handling this pin range.
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"),
1010 each pin/group to have a number of configuration entries that affect it, so
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),
1054 As it is possible to map a function to different groups of pins an optional
1055 .group can be specified like this:
1057 .. code-block:: c
1061 .dev_name = "foo-spi.0",
1062 .name = "spi0-pos-A",
1064 .ctrl_dev_name = "pinctrl-foo",
1065 .function = "spi0",
1066 .group = "spi0_0_grp",
1069 .dev_name = "foo-spi.0",
1070 .name = "spi0-pos-B",
1072 .ctrl_dev_name = "pinctrl-foo",
1073 .function = "spi0",
1074 .group = "spi0_1_grp",
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",
1095 .function = "mmc0",
1096 .group = "mmc0_1_grp",
1099 .dev_name = "foo-mmc.0",
1102 .ctrl_dev_name = "pinctrl-foo",
1103 .function = "mmc0",
1104 .group = "mmc0_1_grp",
1107 .dev_name = "foo-mmc.0",
1110 .ctrl_dev_name = "pinctrl-foo",
1111 .function = "mmc0",
1112 .group = "mmc0_2_grp",
1115 .dev_name = "foo-mmc.0",
1118 .ctrl_dev_name = "pinctrl-foo",
1119 .function = "mmc0",
1120 .group = "mmc0_1_grp",
1123 .dev_name = "foo-mmc.0",
1126 .ctrl_dev_name = "pinctrl-foo",
1127 .function = "mmc0",
1128 .group = "mmc0_2_grp",
1131 .dev_name = "foo-mmc.0",
1134 .ctrl_dev_name = "pinctrl-foo",
1135 .function = "mmc0",
1136 .group = "mmc0_3_grp",
1143 .. code-block:: c
1151 .. code-block:: c
1156 once. Since they share the same name, pin controller device, function and
1168 of the type found below. However when doing fine-grained state selection
1185 ``PINCTRL_STATE_SLEEP`` at runtime, re-biasing or even re-muxing pins to save
1191 .. code-block:: c
1206 foo->p = devm_pinctrl_get(&device);
1207 if (IS_ERR(foo->p)) {
1209 return PTR_ERR(foo->p);
1212 foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT);
1213 if (IS_ERR(foo->s)) {
1215 return PTR_ERR(foo->s);
1218 ret = pinctrl_select_state(foo->p, foo->s);
1231 - ``pinctrl_get()`` is called in process context to obtain a handle to all pinctrl
1236 - ``devm_pinctrl_get()`` is a variant of pinctrl_get() that causes ``pinctrl_put()``
1238 device is removed. It is recommended to use this function over plain
1241 - ``pinctrl_lookup_state()`` is called in process context to obtain a handle to a
1244 - ``pinctrl_select_state()`` programs pin controller hardware according to the
1246 fast-path operation, since it only involved blasting some register settings
1248 registers on a slow/IRQ-based bus, so client devices should not assume they
1249 can call ``pinctrl_select_state()`` from non-blocking contexts.
1251 - ``pinctrl_put()`` frees all information associated with a pinctrl handle.
1253 - ``devm_pinctrl_put()`` is a variant of ``pinctrl_put()`` that may be used to
1255 However, use of this function will be rare, due to the automatic cleanup
1273 NOTE: the pinctrl system will return ``-EPROBE_DEFER`` if it cannot find the
1287 .. code-block:: c
1312 back-end. This is when the GPIO driver may call out to the functions
1314 above. This only involves per-pin multiplexing, and will be completely
1315 hidden behind the gpiod_*() function namespace. In this case, the driver
1320 as a back-end for the GPIO driver like this, unless your hardware design
1337 .. code-block:: c
1340 .dev_name = "pinctrl-foo",
1343 .ctrl_dev_name = "pinctrl-foo",
1344 .function = "power_func",
1347 Since it may be common to request the core to hog a few always-applicable
1351 .. code-block:: c
1353 PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */,
1362 It is possible to mux a certain function in and out at runtime, say to move
1365 function, but with different named in the mapping as described under
1367 "pos-A" and "pos-B".
1370 then muxes the function in the pins defined by group A, and finally muxes it in
1371 on the pins defined by group B:
1373 .. code-block:: c
1387 s1 = pinctrl_lookup_state(p, "pos-A");
1391 s2 = pinctrl_lookup_state(p, "pos-B");
1423 - ``pinctrl-devices``: prints each pin controller device along with columns to
1426 - ``pinctrl-handles``: prints each configured pin controller handle and the
1429 - ``pinctrl-maps``: prints all pinctrl maps
1431 A sub-directory is created inside of ``/sys/kernel/debug/pinctrl`` for each pin
1434 - ``pins``: prints a line for each pin registered on the pin controller. The
1437 - ``gpio-ranges``: prints ranges that map gpio lines to pins on the controller
1439 - ``pingroups``: prints all pin groups registered on the pin controller
1441 - ``pinconf-pins``: prints pin config settings for each pin
1443 - ``pinconf-groups``: prints pin config settings per pin group
1445 - ``pinmux-functions``: prints each pin function along with the pin groups that
1446 map to the pin function
1448 - ``pinmux-pins``: iterates through all pins and prints mux owner, gpio owner
1451 - ``pinmux-select``: write to this file to activate a pin function for a group:
1453 .. code-block:: sh
1455 echo "<group-name function-name>" > pinmux-select