[v6,2/8] dt-bindings: pinctrl: Add RZ/A1 bindings doc
diff mbox

Message ID 1498143276-7976-3-git-send-email-jacopo+renesas@jmondi.org
State New
Headers show

Commit Message

Jacopo Mondi June 22, 2017, 2:54 p.m. UTC
Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
controller.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 .../bindings/pinctrl/renesas,rza1-pinctrl.txt      | 221 +++++++++++++++++++++
 1 file changed, 221 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt

Comments

Rob Herring June 22, 2017, 9:09 p.m. UTC | #1
On Thu, Jun 22, 2017 at 04:54:30PM +0200, Jacopo Mondi wrote:
> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> controller.
> 
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
>  .../bindings/pinctrl/renesas,rza1-pinctrl.txt      | 221 +++++++++++++++++++++
>  1 file changed, 221 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt

Please add acks when posting new versions. It seems there are 2 more 
lines here, but I have no idea what changed. I'm assuming it was minor 
enough to retain my ack.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jacopo Mondi June 23, 2017, 8:05 a.m. UTC | #2
Hi Rob,

On Thu, Jun 22, 2017 at 04:09:17PM -0500, Rob Herring wrote:
> On Thu, Jun 22, 2017 at 04:54:30PM +0200, Jacopo Mondi wrote:
> > Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> > controller.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> >  .../bindings/pinctrl/renesas,rza1-pinctrl.txt      | 221 +++++++++++++++++++++
> >  1 file changed, 221 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
>
> Please add acks when posting new versions. It seems there are 2 more
> lines here, but I have no idea what changed. I'm assuming it was minor
> enough to retain my ack.

I have dropped your Acked-by in v4, as compared to the previous
versions bindings changed "significantly".
Quoting the v4 cover letter:

"The device tree bindings changed significantly, and as anticipated I
have not incorporated Rob's ack as I would like him to have a look there again."

Now that I look at bindings again, I guess I could have kept it
because all of the changes are related to pin controller subsystem
specificities and are not that "significant" in the end..

I'll list them here for your reference

- use "pinmux" in place of "renesas,pins" property
- use generic properties in place of pin mux flags
- a bit of shuffling on generic properties in v4->v6 transition

If none of these is relevant to you, we can add you Acked-by back when
sending pull-request (right Geert?)

Thanks
   j

>
> Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
new file mode 100644
index 0000000..43e21474
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
@@ -0,0 +1,221 @@ 
+Renesas RZ/A1 combined Pin and GPIO controller
+
+The Renesas SoCs of the RZ/A1 family feature a combined Pin and GPIO controller,
+named "Ports" in the hardware reference manual.
+Pin multiplexing and GPIO configuration is performed on a per-pin basis
+writing configuration values to per-port register sets.
+Each "port" features up to 16 pins, each of them configurable for GPIO
+function (port mode) or in alternate function mode.
+Up to 8 different alternate function modes exist for each single pin.
+
+Pin controller node
+-------------------
+
+Required properties:
+  - compatible
+    this shall be "renesas,r7s72100-ports".
+
+  - reg
+    address base and length of the memory area where the pin controller
+    hardware is mapped to.
+
+Example:
+Pin controller node for RZ/A1H SoC (r7s72100)
+
+pinctrl: pin-controller@fcfe3000 {
+	compatible = "renesas,r7s72100-ports";
+
+	reg = <0xfcfe3000 0x4230>;
+};
+
+Sub-nodes
+---------
+
+The child nodes of the pin controller node describe a pin multiplexing
+function or a GPIO controller alternatively.
+
+- Pin multiplexing sub-nodes:
+  A pin multiplexing sub-node describes how to configure a set of
+  (or a single) pin in some desired alternate function mode.
+  A single sub-node may define several pin configurations.
+  A few alternate function require special pin configuration flags to be
+  supplied along with the alternate function configuration number.
+  The hardware reference manual specifies when a pin function requires
+  "software IO driven" mode to be specified. To do so use the generic
+  properties from the <include/linux/pinctrl/pinconf_generic.h> header file
+  to instruct the pin controller to perform the desired pin configuration
+  operation.
+  Please refer to pinctrl-bindings.txt to get to know more on generic
+  pin properties usage.
+
+  The allowed generic formats for a pin multiplexing sub-node are the
+  following ones:
+
+  node-1 {
+      pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ;
+      GENERIC_PINCONFIG;
+  };
+
+  node-2 {
+      sub-node-1 {
+          pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ;
+          GENERIC_PINCONFIG;
+      };
+
+      sub-node-2 {
+          pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ;
+          GENERIC_PINCONFIG;
+      };
+
+      ...
+
+      sub-node-n {
+          pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ;
+          GENERIC_PINCONFIG;
+      };
+  };
+
+  Use the second format when pins part of the same logical group need to have
+  different generic pin configuration flags applied.
+
+  Client sub-nodes shall refer to pin multiplexing sub-nodes using the phandle
+  of the most external one.
+
+  Eg.
+
+  client-1 {
+      ...
+      pinctrl-0 = <&node-1>;
+      ...
+  };
+
+  client-2 {
+      ...
+      pinctrl-0 = <&node-2>;
+      ...
+  };
+
+  Required properties:
+    - pinmux:
+      integer array representing pin number and pin multiplexing configuration.
+      When a pin has to be configured in alternate function mode, use this
+      property to identify the pin by its global index, and provide its
+      alternate function configuration number along with it.
+      When multiple pins are required to be configured as part of the same
+      alternate function they shall be specified as members of the same
+      argument list of a single "pinmux" property.
+      Helper macros to ease assembling the pin index from its position
+      (port where it sits on and pin number) and alternate function identifier
+      are provided by the pin controller header file at:
+      <include/dt-bindings/pinctrl/r7s72100-pinctrl.h>
+      Integers values in "pinmux" argument list are assembled as:
+      ((PORT * 16 + PIN) | MUX_FUNC << 16)
+
+  Optional generic properties:
+    - input-enable:
+      enable input bufer for pins requiring software driven IO input
+      operations.
+    - output-high:
+      enable output buffer for pins requiring software driven IO output
+      operations. output-low can be used alternatively, as line value is
+      ignored by the driver.
+
+  The hardware reference manual specifies when a pin has to be configured to
+  work in bi-directional mode and when the IO direction has to be specified
+  by software. Bi-directional pins are managed by the pin controller driver
+  internally, while software driven IO direction has to be explicitly
+  selected when multiple options are available.
+
+  Example:
+  A serial communication interface with a TX output pin and an RX input pin.
+
+  &pinctrl {
+	scif2_pins: serial2 {
+		pinmux = <RZA1_PINMUX(3, 0, 6)>, <RZA1_PINMUX(3, 2, 4)>;
+	};
+  };
+
+  Pin #0 on port #3 is configured as alternate function #6.
+  Pin #2 on port #3 is configured as alternate function #4.
+
+  Example 2:
+  I2c master: both SDA and SCL pins need bi-directional operations
+
+  &pinctrl {
+	i2c2_pins: i2c2 {
+		pinmux = <RZA1_PINMUX(1, 4, 1)>, <RZA1_PINMUX(1, 5, 1)>;
+	};
+  };
+
+  Pin #4 on port #1 is configured as alternate function #1.
+  Pin #5 on port #1 is configured as alternate function #1.
+  Both need to work in bi-directional mode, the driver manages this internally.
+
+  Example 3:
+  Multi-function timer input and output compare pins.
+  Configure TIOC0A as software driven input and TIOC0B as software driven
+  output.
+
+  &pinctrl {
+	tioc0_pins: tioc0 {
+		tioc0_input_pins {
+			pinumx = <RZA1_PINMUX(4, 0, 2)>;
+			input-enable;
+		};
+
+		tioc0_output_pins {
+			pinmux = <RZA1_PINMUX(4, 1, 1)>;
+			output-enable;
+		};
+	};
+  };
+
+  &tioc0 {
+	...
+	pinctrl-0 = <&tioc0_pins>;
+	...
+  };
+
+  Pin #0 on port #4 is configured as alternate function #2 with IO direction
+  specified by software as input.
+  Pin #1 on port #4 is configured as alternate function #1 with IO direction
+  specified by software as output.
+
+- GPIO controller sub-nodes:
+  Each port of the r7s72100 pin controller hardware is itself a GPIO controller.
+  Different SoCs have different numbers of available pins per port, but
+  generally speaking, each of them can be configured in GPIO ("port") mode
+  on this hardware.
+  Describe GPIO controllers using sub-nodes with the following properties.
+
+  Required properties:
+    - gpio-controller
+      empty property as defined by the GPIO bindings documentation.
+    - #gpio-cells
+      number of cells required to identify and configure a GPIO.
+      Shall be 2.
+    - gpio-ranges
+      Describes a GPIO controller specifying its specific pin base, the pin
+      base in the global pin numbering space, and the number of controlled
+      pins, as defined by the GPIO bindings documentation. Refer to
+      Documentation/devicetree/bindings/gpio/gpio.txt file for a more detailed
+      description.
+
+  Example:
+  A GPIO controller node, controlling 16 pins indexed from 0.
+  The GPIO controller base in the global pin indexing space is pin 48, thus
+  pins [0 - 15] on this controller map to pins [48 - 63] in the global pin
+  indexing space.
+
+  port3: gpio-3 {
+	gpio-controller;
+	#gpio-cells = <2>;
+	gpio-ranges = <&pinctrl 0 48 16>;
+  };
+
+  A device node willing to use pins controlled by this GPIO controller, shall
+  refer to it as follows:
+
+  led1 {
+	gpios = <&port3 10 GPIO_ACTIVE_LOW>;
+  };