Lines Matching +full:g4 +full:- +full:pinctrl
2 PINCTRL (PIN CONTROL) subsystem
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/down, open drain,
17 Top-level interface
22 - A pin controller is a piece of hardware, usually a set of registers, that
28 - PINS are equal to pads, fingers, balls or whatever packaging input or
32 be sparse - i.e. there may be gaps in the space with numbers where no
62 #include <linux/pinctrl/pinctrl.h>
95 To enable the pinctrl subsystem and the subgroups for PINMUX and PINCONF and
98 See for example arch/arm/mach-u300/Kconfig for an example.
101 for your chip. Notice that the core pinctrl.h file provides a fancy macro
137 #include <linux/pinctrl/pinctrl.h>
197 the groups is up to the driver, this is just a simple example - in practice you
205 Pins can sometimes be software-configured in various ways, mostly related
209 using a certain resistor value - pull up and pull down - so that the pin has a
222 #include <linux/pinctrl/pinctrl.h>
223 #include <linux/pinctrl/pinconf.h>
286 situations a cross-subsystem mapping between pins and GPIOs is needed.
338 - GPIO range : [32 .. 47]
339 - pin range : [32 .. 47]
341 - GPIO range : [48 .. 55]
342 - pin range : [64 .. 71]
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
381 Calling pinctrl_add_gpio_range from pinctrl driver is DEPRECATED. Please see
383 pinctrl and gpio drivers.
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
442 out on pins { G4, G3, G2, G1 }.
445 special - it's an external MMC bus that can be 2, 4 or 8 bits wide, and it will
448 port on pins { G4, G3, G2, G1 } of course.
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
472 control subsystem in the drivers/pinctrl/* directory of the kernel. The
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
487 and { G4, G3, G2, G1 }, which are enumerated as { 0, 8, 16, 24 } and
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 -
521 {"map-spi0", spi0, pinctrl0, fspi0, gspi0},
522 {"map-i2c0", i2c0, pinctrl0, fi2c0, gi2c0}
526 function. The group is not compulsory - if it is omitted the first group
535 - PINS for a certain FUNCTION using a certain PIN GROUP on a certain
536 PIN CONTROLLER are provided on a first-come first-serve basis, so if some
542 pads (or "fingers") rather than pins - these are the soldering surfaces on the
579 #include <linux/pinctrl/pinctrl.h>
580 #include <linux/pinctrl/pinmux.h>
733 things - when it gets a selector passed in, the pinmux subsystem makes
753 gpiolib-based drivers as part of their gpio_request() and
786 special GPIO-handler is registered.
802 software-control a few electrical properties of the pin that you would
813 | +- SPI
814 Physical pins --- pad --- pinmux -+- I2C
815 | +- mmc
816 | +- GPIO
836 consumers on hardware of this type. The pinctrl driver should set this flag
845 | +- SPI
846 Physical pins --- pad --- pinmux -+- I2C
847 | | +- mmc
869 - Registers (or fields within registers) that control electrical
871 exposed through the pinctrl subsystem, as "pin configuration" settings.
873 - Registers (or fields within registers) that control muxing of signals
875 be exposed through the pinctrl subsystem, as mux functions.
877 - Registers (or fields within registers) that control GPIO functionality
884 GPIO subsystem may call into the pinctrl subsystem in order to
885 co-ordinate register settings across HW modules. In particular, this may
891 may be placed at some pin-specific register in all cases or as part
898 If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
909 a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
920 #include <linux/pinctrl/consumer.h>
922 struct pinctrl *pinctrl;
926 pins_default = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_DEFAULT);
927 pins_sleep = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_SLEEP);
930 retval = pinctrl_select_state(pinctrl, pins_default);
932 retval = pinctrl_select_state(pinctrl, pins_sleep);
935 --------------------------------------------------
948 PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
950 PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
952 PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
953 "u0_group", "gpio-mode"),
954 PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
965 named "gpio-mode" that can be mapped onto the same pins to move them into
974 kernel sense are just some 1-bit line, and is a different use case.
977 configuration and the muxing of the "u0" or "gpio-mode" group onto these
1000 #include <linux/pinctrl/machine.h>
1004 .dev_name = "foo-spi.0",
1007 .ctrl_dev_name = "pinctrl-foo",
1011 .dev_name = "foo-i2c.0",
1014 .ctrl_dev_name = "pinctrl-foo",
1018 .dev_name = "foo-mmc.0",
1021 .ctrl_dev_name = "pinctrl-foo",
1038 it even more compact which assumes you want to use pinctrl-foo and position
1042 PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT,
1043 "pinctrl-foo", NULL, "i2c0"),
1062 PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1063 "pinctrl-foo", "i2c0", "i2c0"),
1064 PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1065 "pinctrl-foo", "i2c0", i2c_grp_configs),
1066 PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1067 "pinctrl-foo", "i2c0scl", i2c_pin_configs),
1068 PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT,
1069 "pinctrl-foo", "i2c0sda", i2c_pin_configs),
1080 PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT),
1092 .dev_name = "foo-spi.0",
1093 .name = "spi0-pos-A",
1095 .ctrl_dev_name = "pinctrl-foo",
1100 .dev_name = "foo-spi.0",
1101 .name = "spi0-pos-B",
1103 .ctrl_dev_name = "pinctrl-foo",
1115 three groups for a total of 2+2+4 = 8 pins (for an 8-bit MMC bus as is the
1120 .dev_name = "foo-mmc.0",
1123 .ctrl_dev_name = "pinctrl-foo",
1128 .dev_name = "foo-mmc.0",
1131 .ctrl_dev_name = "pinctrl-foo",
1136 .dev_name = "foo-mmc.0",
1139 .ctrl_dev_name = "pinctrl-foo",
1144 .dev_name = "foo-mmc.0",
1147 .ctrl_dev_name = "pinctrl-foo",
1152 .dev_name = "foo-mmc.0",
1155 .ctrl_dev_name = "pinctrl-foo",
1160 .dev_name = "foo-mmc.0",
1163 .ctrl_dev_name = "pinctrl-foo",
1193 of the type found below. However when doing fine-grained state selection
1195 handling of the pinctrl handles and states.
1210 PINCTRL_STATE_SLEEP at runtime, re-biasing or even re-muxing pins to save
1216 #include <linux/pinctrl/consumer.h>
1219 struct pinctrl *p;
1229 foo->p = devm_pinctrl_get(&device);
1230 if (IS_ERR(foo->p)) {
1232 return PTR_ERR(foo->p);
1235 foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT);
1236 if (IS_ERR(foo->s)) {
1241 ret = pinctrl_select_state(foo->s);
1252 The semantics of the pinctrl APIs are:
1254 - pinctrl_get() is called in process context to obtain a handle to all pinctrl
1259 - devm_pinctrl_get() is a variant of pinctrl_get() that causes pinctrl_put()
1264 - pinctrl_lookup_state() is called in process context to obtain a handle to a
1267 - pinctrl_select_state() programs pin controller hardware according to the
1269 fast-path operation, since it only involved blasting some register settings
1271 registers on a slow/IRQ-based bus, so client devices should not assume they
1272 can call pinctrl_select_state() from non-blocking contexts.
1274 - pinctrl_put() frees all information associated with a pinctrl handle.
1276 - devm_pinctrl_put() is a variant of pinctrl_put() that may be used to
1277 explicitly destroy a pinctrl object returned by devm_pinctrl_get().
1296 NOTE: the pinctrl system will return -EPROBE_DEFER if it cannot find the
1297 requested pinctrl handles, for example if the pinctrl driver has not yet
1310 #include <linux/pinctrl/consumer.h>
1313 struct pinctrl *pinctrl;
1316 pinctrl = devm_pinctrl_get_select_default(&dev);
1321 nominally always get your pinctrl handle and select the desired pinctrl
1327 The above can be hidden: using the device core, the pinctrl core may be
1332 to communicate directly with the pinctrl subsystem, using the latter as a
1333 back-end. This is when the GPIO driver may call out to the functions
1335 above. This only involves per-pin multiplexing, and will be completely
1341 as a back-end for the GPIO driver like this, unless your hardware design
1359 .dev_name = "pinctrl-foo",
1362 .ctrl_dev_name = "pinctrl-foo",
1366 Since it may be common to request the core to hog a few always-applicable
1370 PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */,
1384 "pos-A" and "pos-B".
1390 #include <linux/pinctrl/consumer.h>
1392 struct pinctrl *p;
1402 s1 = pinctrl_lookup_state(foo->p, "pos-A");
1406 s2 = pinctrl_lookup_state(foo->p, "pos-B");