Lines Matching refs:pins
6 - Enumerating and naming controllable pins
8 - Multiplexing of pins, pads, fingers (etc) see below for details
10 - Configuration of pins, pads, fingers (etc), such as software-controlled
11 biasing and driving mode specific pins, such as pull-up/down, open drain,
21 set drive strength, etc. for individual pins or groups of pins.
34 describing the pins handled by this specific pin controller.
56 To register a pin controller and name all the pins on this package we can do
73 .pins = foo_pins,
95 the pins from 0 in the upper left corner to 63 in the lower right corner.
102 For a padring with 467 pads, as opposed to actual pins, I used an enumeration
118 Many controllers need to deal with groups of pins, so the pin controller
119 subsystem has a mechanism for enumerating groups of pins and retrieving the
120 actual enumerated pins that are part of a certain group.
122 For example, say that we have a group of pins dealing with an SPI interface
123 on { 0, 8, 16, 24 }, and a group of pins dealing with an I2C interface on pins
133 const unsigned int *pins;
143 .pins = spi0_pins,
148 .pins = i2c0_pins,
166 const unsigned **pins,
169 *pins = (unsigned *) foo_groups[selector].pins;
188 to retrieve the name and pins of the group. Maintaining the data structure of
269 Since some controllers have special logic for handling entire groups of pins
273 group-level handling and then fall through to iterate over all pins, in which
282 physical pins that are also registered as pin controller pins.
287 situations a cross-subsystem mapping between pins and GPIOs is needed.
293 one set of pins, but internally several GPIO silicon blocks, each modelled as
326 GPIO chips. "chip a" has 16 pins and "chip b" has 8 pins. The "chip a" and
345 The above examples assume the mapping between the GPIOs and pins is
355 .pins = &range_pins,
361 group is known, the pins and npins elements of the above structure can be
365 pinctrl_get_group_pins(pctl, "foo", &gpio_range.pins, &gpio_range.npins);
428 pins you see some will be taken by things like a few VCC and GND to feed power
430 memory interface. The remaining pins will often be subject to pin multiplexing.
433 to its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using
436 In this 8x8 BGA package the pins { A8, A7, A6, A5 } can be used as an SPI port
437 (these are four pins: CLK, RXD, TXD, FRM). In that case, pin B5 can be used as
438 some general-purpose GPIO pin. However, in another setting, pins { A5, B5 } can
439 be used as an I2C port (these are just two pins: SCL, SDA). Needless to say,
442 out on pins { G4, G3, G2, G1 }.
446 consume 2, 4 or 8 pins respectively, so either { A1, B1 } are taken or
448 port on pins { G4, G3, G2, G1 } of course.
453 different pins by pinmux settings.
455 Since general-purpose I/O pins (GPIO) are typically always in shortage, it is
483 function i2c is associated with the pins { A5, B5 }, enumerated as
494 for a certain set of pins. The knowledge of the functions and pin groups
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 -
532 a certain pin controller may use different sets of pins in different
542 pads (or "fingers") rather than pins - these are the soldering surfaces on the
544 pins/balls underneath the capsule. Pick some enumeration that makes sense to
545 you. Define enumerators only for the pins you can control if that makes sense.
562 The pinmux core takes care of preventing conflicts on pins and calling
577 group of pins would work something like this:
584 const unsigned int *pins;
598 .pins = spi0_0_pins,
603 .pins = spi0_1_pins,
608 .pins = i2c0_pins,
613 .pins = mmc0_1_pins,
618 .pins = mmc0_2_pins,
623 .pins = mmc0_3_pins,
641 unsigned ** const pins,
644 *pins = (unsigned *) foo_groups[selector].pins;
730 pins and who is using them, it will already have denied an impossible
734 pins. Thus bits 0 and 1 in the control register will never be set at the
757 NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
759 that driver request proper muxing and other control for its pins.
762 individual pin into a GPIO pin independent of any other pins, and then try
773 controller core, so you know which GPIO pins are being affected by the request
813 Physical pins --- pad --- pinmux -+- I2C
838 Physical pins --- pad --- pinmux -+- I2C
861 from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
946 Here the pins we want to control are in the "u0_group" and there is some
947 function called "u0" that can be enabled on this group of pins, and then
949 named "gpio-mode" that can be mapped onto the same pins to move them into
956 by that UART device to control the pins that pertain to that very UART
962 pins is a question for the driver.
1066 As it is possible to map a function to different groups of pins an optional
1092 groups of pins, say for example in the mmc0 example above, where you can
1093 additively expand the mmc0 bus from 2 to 4 to 8 pins. If we want to use all
1094 three groups for a total of 2+2+4 = 8 pins (for an 8-bit MMC bus as is the
1176 So if you just want to put the pins for a certain device into the default
1187 A typical case is if a driver needs to switch bias of pins from normal
1189 PINCTRL_STATE_SLEEP at runtime, re-biasing or even re-muxing pins to save
1267 the associated pins, whereas select_state pass on to the pin controller
1271 The pins are allocated for your device when you issue the devm_pinctrl_get()
1273 pins.
1303 mux in and bias pins in a certain way before the GPIO subsystems starts to
1307 setting up the config and muxing for the pins right before the device is
1318 If a pin control driver and a GPIO driver is dealing with the same pins
1358 an SPI port from one set of pins to another set of pins. Say for example for
1359 spi0 in the example above, we expose two different groups of pins for the same
1365 then muxes the function in the pins defined by group A, and finally muxes it in
1366 on the pins defined by group B:
1406 The above has to be done from process context. The reservation of the pins