Merge commit 'pinctrl/devel 4ddb1c2' into spear-for-3.8 (22595e28) · Commits · e / devices / android_kernel_oneplus_sm7250

Documentation/devicetree/bindings/gpio/gpio.txt

+36 −0

Original line number	Diff line number	Diff line
		@@ -75,4 +75,40 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
		gpio-controller;
		};

		2.1) gpio-controller and pinctrl subsystem
		------------------------------------------

		gpio-controller on a SOC might be tightly coupled with the pinctrl
		subsystem, in the sense that the pins can be used by other functions
		together with optional gpio feature.

		While the pin allocation is totally managed by the pin ctrl subsystem,
		gpio (under gpiolib) is still maintained by gpio drivers. It may happen
		that different pin ranges in a SoC is managed by different gpio drivers.

		This makes it logical to let gpio drivers announce their pin ranges to
		the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
		request the corresponding pin before any gpio usage.

		For this, the gpio controller can use a pinctrl phandle and pins to
		announce the pinrange to the pin ctrl subsystem. For example,

		qe_pio_e: gpio-controller@1460 {
		#gpio-cells = <2>;
		compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
		reg = <0x1460 0x18>;
		gpio-controller;
		gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;

		}

		where,
		&pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node.

		Next values specify the base pin and number of pins for the range
		handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
		pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
		by this gpio controller.

		The pinctrl node must have "#gpio-range-cells" property to show number of
		arguments to pass with phandle from gpio controllers node.

Documentation/gpio.txt

+42 −0

Original line number	Diff line number	Diff line
		@@ -439,6 +439,48 @@ slower clock delays the rising edge of SCK, and the I2C master adjusts its
		signaling rate accordingly.


		GPIO controllers and the pinctrl subsystem
		------------------------------------------

		A GPIO controller on a SOC might be tightly coupled with the pinctrl
		subsystem, in the sense that the pins can be used by other functions
		together with an optional gpio feature. We have already covered the
		case where e.g. a GPIO controller need to reserve a pin or set the
		direction of a pin by calling any of:

		pinctrl_request_gpio()
		pinctrl_free_gpio()
		pinctrl_gpio_direction_input()
		pinctrl_gpio_direction_output()

		But how does the pin control subsystem cross-correlate the GPIO
		numbers (which are a global business) to a certain pin on a certain
		pin controller?

		This is done by registering "ranges" of pins, which are essentially
		cross-reference tables. These are described in
		Documentation/pinctrl.txt

		While the pin allocation is totally managed by the pinctrl subsystem,
		gpio (under gpiolib) is still maintained by gpio drivers. It may happen
		that different pin ranges in a SoC is managed by different gpio drivers.

		This makes it logical to let gpio drivers announce their pin ranges to
		the pin ctrl subsystem before it will call 'pinctrl_request_gpio' in order
		to request the corresponding pin to be prepared by the pinctrl subsystem
		before any gpio usage.

		For this, the gpio controller can register its pin range with pinctrl
		subsystem. There are two ways of doing it currently: with or without DT.

		For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt.

		For non-DT support, user can call gpiochip_add_pin_range() with appropriate
		parameters to register a range of gpio pins with a pinctrl driver. For this
		exact name string of pinctrl device has to be passed as one of the
		argument to this routine.


		What do these conventions omit?
		===============================
		One of the biggest things these conventions omit is pin multiplexing, since

Documentation/pinctrl.txt

+6 −1

Original line number	Diff line number	Diff line
		@@ -364,6 +364,9 @@ will get an pin number into its handled number range. Further it is also passed
		the range ID value, so that the pin controller knows which range it should
		deal with.

		Calling pinctrl_add_gpio_range from pinctrl driver is DEPRECATED. Please see
		section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind
		pinctrl and gpio drivers.

		PINMUX interfaces
		=================
		@@ -1193,4 +1196,6 @@ foo_switch()
		...
		}

		The above has to be done from process context.
		The above has to be done from process context. The reservation of the pins
		will be done when the state is activated, so in effect one specific pin
		can be used by different functions at different times on a running system.

arch/arm/boot/dts/spear1310-evb.dts

+4 −0

Original line number	Diff line number	Diff line
		@@ -181,6 +181,10 @@
		status = "okay";
		};

		gpio@d8400000 {
		status = "okay";
		};

		i2c0: i2c@e0280000 {
		status = "okay";
		};

arch/arm/boot/dts/spear1310.dtsi

+27 −0

Original line number	Diff line number	Diff line
		@@ -70,6 +70,12 @@
		status = "disabled";
		};

		pinmux: pinmux@e0700000 {
		compatible = "st,spear1310-pinmux";
		reg = <0xe0700000 0x1000>;
		#gpio-range-cells = <2>;
		};

		spi1: spi@5d400000 {
		compatible = "arm,pl022", "arm,primecell";
		reg = <0x5d400000 0x1000>;
		@@ -179,6 +185,27 @@
		thermal@e07008c4 {
		st,thermal-flags = <0x7000>;
		};

		gpiopinctrl: gpio@d8400000 {
		compatible = "st,spear-plgpio";
		reg = <0xd8400000 0x1000>;
		interrupts = <0 100 0x4>;
		#interrupt-cells = <1>;
		interrupt-controller;
		gpio-controller;
		#gpio-cells = <2>;
		gpio-ranges = <&pinmux 0 246>;
		status = "disabled";

		st-plgpio,ngpio = <246>;
		st-plgpio,enb-reg = <0xd0>;
		st-plgpio,wdata-reg = <0x90>;
		st-plgpio,dir-reg = <0xb0>;
		st-plgpio,ie-reg = <0x30>;
		st-plgpio,rdata-reg = <0x70>;
		st-plgpio,mis-reg = <0x10>;
		st-plgpio,eit-reg = <0x50>;
		};
		};
		};
		};