Table Contents

Introduction

Pin controller subsystem deals with enumerating and multiplexing pins, as well as configuring IO behavior of the pins such as bias pull up/down, slew rate, etc. Pin controller is a piece of hardware, usually a set of registers, which can control pins. It may be able to multiplex, bias, set load capacitance, set drive strength, etc. for individual pins or groups of pins. When a pin controller is instantiated, it will register a descriptor to the pin control framework, and this descriptor contains an array of pin descriptors describing the pins handled by this specific pin controller.
Many controllers need to deal with groups of pins, so the pin controller subsystem has a mechanism for enumerating groups of pins and retrieving the actual enumerated pins that are part of a certain group. For example, say that we have a group of pins dealing with an SPI interface on {16, 17, 18, 19, 20}, and a group of pins dealing with an I2C interface on pins on {10, 11}. Pin controller can be used to define such pin groups and configure them based on requirement.
Pins can sometimes be software-configured in various ways, mostly related to their electronic properties when used as inputs or outputs. You may be able to connect an input pin to VDD or GND using a certain resistor value - pull up and pull down - so that the pin has a stable value. when nothing is driving the rail it is connected to, or when it's unconnected. Pin configuration can be programmed by adding configuration entries into the mapping table.
Below peripheral currently use pin control driver:

sdhci
uart1
usb0
i2c0
gem0
can0

Benefits of using pin control drivers:

Avoid multiple drivers configuring same pins
- Pin control subsystem prevents multiple peripherals to use same pins. Consider an example of a pair of pins that can be used as I2C as well as CAN. If pin control subsystem is not used then both I2C and CAN will independently try to use these pins. It’s easier to detect and avoid such conflicts with pin controller driver as all pin configurations are listed in the device tree file.
Platform independent implementation
- Pin control subsystem allows platform independent implementation for the drivers. This sub system allows to provide pin details in platform device tree and hence the drivers can be made hardware independent, fetching all pin configuration details from the device tree.

The pin-controller subsystem is documented in the kernel documentation in /Documentation/pinctrl.txt

HW IP features

Supports 54 MIO pins, 192 EMIO pins.
Supports fast or slow slew rate configurable by software
Supports pin pull up/down configurable by software

Features supported in driver

Supports below pin configurations:

Output Slew Rate
Bias Pull Up/Down
Bias Disable
IO Voltage Standard

Missing Features, Known Issues and Limitations

Missing support for disabling MIO pin and routing just to EMIO

Kernel Configuration

To enable pin-controller driver in the kernel, the following configuration options need to be enabled:

CONFIG_PINCTRL=y
CONFIG_PINCTRL_ZYNQ=y
CONFIG_ARCH_ZYNQ=y
CONFIG_PINMUX=y
CONFIG_GENERIC_PINCONF=y

Devicetree

pinctrl0: pinctrl {
        compatible = "xlnx,pinctrl-zynq";
		reg = <0x700 0x200>;
		syscon = <&slcr>;
        pinctrl_uart1_default: uart1-default {
			mux {
				groups = "uart1_10_grp";
				function = "uart1";
			};
  
			conf {
				groups = "uart1_10_grp";
				slew-rate = <0>;
				io-standard = <1>;
			};
  
			conf-rx {
				pins = "MIO49";
				bias-high-impedance;
			};
  
			conf-tx {
				pins = "MIO48";
				bias-disable;
			};
	};
};

Test procedure

The drivers are tested on actual Zc702 board. Kernel logs are used to validate the functionality of the drivers. For negative testing,
errors are deliberately injected in the device tree blob’s pin control nodes and then the functionality of the peripheral is checked.
The testing observations (Kernel Logs) for I2C bus is mentioned hereafter. It can be seen from the kernel logs that under ideal scenario I2C is probed,
pins are properly configured, I2C bus entries are added and EEPROM is successfully attached over I2C, but under error scenarios pin control shouts for error,
no I2C busses are added as well as EEPROM node is not found.

Expected Output

Ideal Scenario
Successfully Probed pin control drivers

[    0.252703] pinctrl core: initialized pinctrl subsystem
[    1.837114] zynq-pinctrl 700.pinctrl: zynq pinctrl initialized

I2C multiplexed busses added

i2c i2c-0: Added multiplexed i2c bus 1
[    2.870802] i2c i2c-0: Added multiplexed i2c bus 2
[    2.872127] at24 3-0054: 1024 byte 24c08 EEPROM, writable, 1 bytes/write
[    2.872261] i2c i2c-0: Added multiplexed i2c bus 3
[    2.872731] i2c i2c-0: Added multiplexed i2c bus 4
[    2.875426] rtc-pcf8563 5-0051: registered as rtc0
[    2.875987] i2c i2c-0: Added multiplexed i2c bus 5
[    2.876307] i2c i2c-0: Added multiplexed i2c bus 6
[    2.876605] i2c i2c-0: Added multiplexed i2c bus 7
[    2.877353] i2c i2c-0: Added multiplexed i2c bus 8

Mainline Status

In Sync with Mainline driver.

Change Log

2023.2

None

2023.1

None

2022.2

None

2022.1

None

2021.2

Summary:

Add support for 'power-source' parameter

Commits:

0de8a6a