Lines Matching refs:pin
2 This document outlines the pin control subsystem in Linux
19 - A pin controller is a piece of hardware, usually a set of registers, that
28 there may be several such number spaces in a system. This pin space may
30 pin exists.
33 pin control framework, and this descriptor contains an array of pin descriptors
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
84 pr_err("could not register foo pin driver\n");
100 the pin controller.
118 Many controllers need to deal with groups of pins, so the pin controller
126 These two groups are presented to the pin control subsystem by implementing
186 The pin control subsystem will call the .get_groups_count() function to
199 may be able to make an output pin high impedance, or "tristate" meaning it is
200 effectively disconnected. You may be able to connect an input pin to VDD or GND
201 using a certain resistor value - pull up and pull down - so that the pin has a
209 above, is entirely defined by the pin controller driver.
211 The pin configuration driver implements callbacks for changing pin
212 configuration in the pin controller ops like this:
224 ... Find setting for pin @ offset ...
263 /* Pin config operations are handled by some pin controller */
270 they can exploit the special whole-group pin control function. The
274 case each individual pin will be treated by separate pin_config_set() calls as
282 physical pins that are also registered as pin controller pins.
285 see the section named "pin control requests from drivers" and
286 "drivers needing both pin control and GPIOs" below for details. But in some
289 Since the pin controller subsystem have its pinspace local to the pin
290 controller we need a mapping so that the pin control subsystem can figure out
291 which pin controller handles control of a certain GPIO pin. Since a single
292 pin controller may be muxing several GPIO ranges (typically SoCs that have
294 a struct gpio_chip) any number of GPIO ranges can be added to a pin controller
325 So this complex system has one pin controller handling two different
327 "chip b" have different .pin_base, which means a start pin number of the
331 pin range also starts from 32. However "chip b" has different starting
332 offset for the GPIO range and pin range. The GPIO range of "chip b" starts
333 from GPIO number 48, while the pin range of "chip b" starts from 64.
335 We can convert a gpio number to actual pin number using this "pin_base".
336 They are mapped in the global GPIO pin space at:
340 - pin range : [32 .. 47]
343 - pin range : [64 .. 71]
346 linear. If the mapping is sparse or haphazard, an array of arbitrary pin
360 In this case the pin_base property will be ignored. If the name of a pin
362 initialised using the function pinctrl_get_group_pins(), e.g. for pin
367 When GPIO-specific functions in the pin control subsystem are called, these
368 ranges will be used to look up the appropriate pin controller by inspecting
369 and matching the pin to the pin ranges across all controllers. When a
370 pin controller handling the matching range is found, GPIO-specific functions
371 will be called on that specific pin controller.
373 For all functionalities dealing with pin biasing, pin muxing etc, the pin
374 controller subsystem will look up the corresponding pin number from the passed
375 in gpio number, and use the range's internals to retrieve a pin number. After
376 that, the subsystem passes it on to the pin control driver, so the driver
377 will get a pin number into its handled number range. Further it is also passed
378 the range ID value, so that the pin controller knows which range it should
398 a certain physical pin (ball, pad, finger, etc) for multiple mutually exclusive
430 memory interface. The remaining pins will often be subject to pin multiplexing.
432 The example 8x8 PGA package above will have pin numbers 0 through 63 assigned
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
451 out on different pin ranges. Often contemporary SoC (systems on chip) will
456 common to be able to use almost any pin as a GPIO pin if it is not currently
463 The purpose of the pinmux functionality in the pin controller subsystem is to
467 to request a single pin for e.g. GPIO.
471 - FUNCTIONS can be switched in and out by a driver residing with the pin
473 pin control driver knows the possible functions. In the example above you can
481 function is *always* associated with a certain set of pin groups, could
484 { 24, 25 } in the controller pin space.
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
494 for a certain set of pins. The knowledge of the functions and pin groups
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
510 name. Defining a pin controller, function and group thus uniquely identify
517 fi2c0 group gi2c0, on the primary pin controller, we get mappings
525 Every map must be assigned a state name, pin controller, device and
531 pin controller and function. This is for cases where a certain function on
532 a certain pin controller may use different sets of pins in different
537 other device mux setting or GPIO pin request has already taken your physical
538 pin, you will be denied the use of it. To get (activate) a new setting, the
549 We assume that the number of possible function maps to pin groups is limited by
551 mapped to any pin, like in a phone exchange. So the available pin groups for
555 expect pinmux drivers to present *all* possible function vs pin group mappings
563 the pin controller driver to execute different settings.
573 some certain registers to activate a certain mux setting for a certain pin.
719 /* Pinmux operations are handled by some pin controller */
727 0 and 1, uses one pin in common so they would collide.
743 Note that the following implies that the use case is to use a certain pin
762 individual pin into a GPIO pin independent of any other pins, and then try
763 the approach to define every pin as a function.
768 For this reason there are two functions a pin control driver can implement
769 to enable only GPIO on an individual pin: .gpio_request_enable() and
772 This function will pass in the affected GPIO range identified by the pin
777 GPIO pin shall be used for input or output you can implement the
779 gpiolib driver and the affected GPIO range, pin offset and desired direction
783 named functions for each GPIO pin, the pinctrl_request_gpio() will attempt to
784 obtain the function "gpioN" where "N" is the global GPIO pin number if no
793 may be confused by a datasheet talking about a pin being possible to set
796 interface <linux/gpio.h>: a pin that you grab from kernel code and then
801 software-control a few electrical properties of the pin that you would
802 not be able to control if the pin was in some other mode, such as muxed in
805 The GPIO portions of a pin and its relation to a certain pin controller
810 pin config
816 pin
820 Here some electrical properties of the pin can be configured no matter
821 whether the pin is used for GPIO or not. If you multiplex a GPIO onto a
822 pin, you can also drive it high/low from "GPIO" registers.
823 Alternatively, the pin can be controlled by a certain peripheral, while
824 still applying desired pin config properties. GPIO functionality is thus
825 orthogonal to any other device using the pin.
827 In this arrangement the registers for the GPIO portions of the pin controller,
830 range dealing with pin config and pin multiplexing get placed into a
835 pin config
841 GPIO pin
847 pulsed out. It is likely possible to disrupt the traffic on the pin by doing
849 possible that the GPIO, pin config and pin multiplex registers are placed into
857 properties of the pin such as biasing and drive strength should be
858 exposed through the pinctrl subsystem, as "pin configuration" settings.
866 setting GPIO pin direction should be exposed through the GPIO subsystem,
873 be needed for HW with separate GPIO and pin controller HW modules, where
874 e.g. GPIO direction is determined by a register in the pin controller HW
877 Electrical properties of the pin such as biasing and drive strength
878 may be placed at some pin-specific register in all cases or as part
882 Example: a pin is usually muxed in to be used as a UART TX line. But during
883 system sleep, we need to put this pin into "GPIO mode" and ground it.
885 If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
887 pin shall be used for UART TX and GPIO at the same time, that you will grab
888 a pin control handle and set it to a certain state to enable UART TX to be
896 a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
899 PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
902 So it is perfectly possible to push a pin into "GPIO mode" and drive the
903 line low as part of the usual pin control map. So for example your UART
954 when going to sleep, it might imply that the pin is set into something the
980 A pin controller configuration for a machine looks pretty much like a simple
1012 must match a function provided by the pinmux driver handling this pin range.
1014 As you can see we may have several pin controllers on the system and thus
1029 The mapping table may also contain pin configuration entries. It's common for
1030 each pin/group to have a number of configuration entries that affect it, so
1052 named states. When running on hardware that doesn't need any pin controller
1056 a named state without causing any pin controller to be programmed:
1160 once. Since they share the same name, pin controller device, function and
1181 Generally it is discouraged to let individual drivers get and enable pin
1182 control. So if possible, handle the pin control in platform code or some other
1246 - pinctrl_select_state() programs pin controller hardware according to the
1249 into hardware. However, note that some pin controllers may have their
1265 Usually the pin control core handled the get/put pair and call out to the
1267 the associated pins, whereas select_state pass on to the pin controller
1281 Drivers needing both pin control and GPIOs
1284 Again, it is discouraged to let drivers lookup and select pin control states
1298 Here we first request a certain pin state and then request GPIO 14 to be
1314 above. This only involves per-pin multiplexing, and will be completely
1316 need not interact with the pin control subsystem at all.
1318 If a pin control driver and a GPIO driver is dealing with the same pins
1319 and the use cases involve multiplexing, you MUST implement the pin controller
1321 is such that the GPIO controller can override the pin controller's
1323 pin control system.
1326 System pin control hogging
1329 Pin control map entries can be hogged by the core when the pin controller
1331 lookup_state() and select_state() on it immediately after the pin control
1335 to the pin controller device name, and the state name is PINCTRL_STATE_DEFAULT.
1346 mux settings on the primary pin controller, there is a convenience macro for
1407 will be done when the state is activated, so in effect one specific pin