[RFC,v2,1/6] dt-bindings: pinctrl: starfive: Add JH8100 pinctrl

Message ID 20240220064246.467216-2-yuklin.soo@starfivetech.com
State New
Headers
Series Add Pinctrl driver for Starfive JH8100 SoC |

Commit Message

Alex Soo Feb. 20, 2024, 6:42 a.m. UTC
  Add documentation and header file for JH8100 pinctrl driver.

Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
---
 .../pinctrl/starfive,jh8100-aon-pinctrl.yaml  | 261 ++++++++++++++++++
 .../starfive,jh8100-sys-east-pinctrl.yaml     | 223 +++++++++++++++
 .../starfive,jh8100-sys-gmac-pinctrl.yaml     | 163 +++++++++++
 .../starfive,jh8100-sys-west-pinctrl.yaml     | 220 +++++++++++++++
 .../pinctrl/starfive,jh8100-pinctrl.h         | 103 +++++++
 5 files changed, 970 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh8100-aon-pinctrl.yaml
 create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-east-pinctrl.yaml
 create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-gmac-pinctrl.yaml
 create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-west-pinctrl.yaml
 create mode 100644 include/dt-bindings/pinctrl/starfive,jh8100-pinctrl.h
  

Comments

Krzysztof Kozlowski Feb. 20, 2024, 8:11 a.m. UTC | #1
On 20/02/2024 07:42, Alex Soo wrote:
> Add documentation and header file for JH8100 pinctrl driver.
> 
> Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
> ---


RFC? Why isn't this patch ready for review?

As requested, I will provide only brief review, not full one.
..

> +
> +properties:
> +  compatible:
> +    oneOf:

Drop

> +      - items:
> +          - const: starfive,jh8100-aon-pinctrl
> +          - const: syscon
> +          - const: simple-mfd
> +
> +  reg:
> +    maxItems: 1
> +
> +  resets:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  interrupt-controller: true
> +
> +  gpio-controller: true
> +
> +  '#gpio-cells':
> +    const: 2
> +
> +  gpio-ranges:
> +    maxItems: 1
> +
> +  wakeup-gpios:
> +    maxItems: 1
> +    description: GPIO pin to be used for waking up the system from sleep mode.
> +
> +  wakeup-source:
> +    maxItems: 1
> +    description: to indicate pinctrl has wakeup capability.
> +
> +patternProperties:
> +  '-grp$':
> +    type: object
> +    additionalProperties: false
> +    patternProperties:
> +      '-pins$':
> +        type: object
> +        description: |
> +          A pinctrl node should contain at least one subnode representing the
> +          pinctrl groups available in the domain. Each subnode will list the
> +          pins it needs, and how they should be configured, with regard to
> +          muxer configuration, bias, input enable/disable, input schmitt
> +          trigger enable/disable, slew-rate and drive strength.
> +        allOf:
> +          - $ref: /schemas/pinctrl/pincfg-node.yaml
> +          - $ref: /schemas/pinctrl/pinmux-node.yaml
> +        additionalProperties: false

NAK, nothing improved.


...

> diff --git a/include/dt-bindings/pinctrl/starfive,jh8100-pinctrl.h b/include/dt-bindings/pinctrl/starfive,jh8100-pinctrl.h
> new file mode 100644
> index 000000000000..055bac7eb2a6
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/starfive,jh8100-pinctrl.h
> @@ -0,0 +1,103 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> +/*
> + * Copyright (C) 2023-2024 StarFive Technology Co., Ltd.
> + */
> +
> +#ifndef __DT_BINDINGS_PINCTRL_STARFIVE_JH8100_H__
> +#define __DT_BINDINGS_PINCTRL_STARFIVE_JH8100_H__
> +
> +/* sys_iomux_west pins */
> +#define PAD_GPIO0_W				0
> +#define PAD_GPIO1_W				1

NAK, read my comments.

Best regards,
Krzysztof
  
Conor Dooley Feb. 20, 2024, 7:10 p.m. UTC | #2
On Tue, Feb 20, 2024 at 09:11:43AM +0100, Krzysztof Kozlowski wrote:
> On 20/02/2024 07:42, Alex Soo wrote:
> > Add documentation and header file for JH8100 pinctrl driver.
> > 
> > Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
> > ---
> 
> 
> RFC? Why isn't this patch ready for review?

The TL;DR is that Emil and I didn't want to apply the dts patches to
support a platform that hadn't actually been taped out yet. 
For an SoC in that state, at least the bindings for, clock and pinctrl
could be subject to changes before tapeou. I think putting RFC on those
patches is a good idea, but of course the rationale should be mentioned.

Cheers,
Conor.
  
Krzysztof Kozlowski Feb. 21, 2024, 7:24 a.m. UTC | #3
On 20/02/2024 20:10, Conor Dooley wrote:
> On Tue, Feb 20, 2024 at 09:11:43AM +0100, Krzysztof Kozlowski wrote:
>> On 20/02/2024 07:42, Alex Soo wrote:
>>> Add documentation and header file for JH8100 pinctrl driver.
>>>
>>> Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
>>> ---
>>
>>
>> RFC? Why isn't this patch ready for review?
> 
> The TL;DR is that Emil and I didn't want to apply the dts patches to
> support a platform that hadn't actually been taped out yet. 
> For an SoC in that state, at least the bindings for, clock and pinctrl
> could be subject to changes before tapeou. I think putting RFC on those
> patches is a good idea, but of course the rationale should be mentioned.

That would be useful information. We also could mark some bindings
unstable and accept breaking ABI under certain conditions, like that it
is early work without users for long time.

Best regards,
Krzysztof
  
Conor Dooley Feb. 21, 2024, 7:39 p.m. UTC | #4
On Wed, Feb 21, 2024 at 08:24:26AM +0100, Krzysztof Kozlowski wrote:
> On 20/02/2024 20:10, Conor Dooley wrote:
> > On Tue, Feb 20, 2024 at 09:11:43AM +0100, Krzysztof Kozlowski wrote:
> >> On 20/02/2024 07:42, Alex Soo wrote:
> >>> Add documentation and header file for JH8100 pinctrl driver.
> >>>
> >>> Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
> >>> ---
> >>
> >>
> >> RFC? Why isn't this patch ready for review?
> > 
> > The TL;DR is that Emil and I didn't want to apply the dts patches to
> > support a platform that hadn't actually been taped out yet. 
> > For an SoC in that state, at least the bindings for, clock and pinctrl
> > could be subject to changes before tapeou. I think putting RFC on those
> > patches is a good idea, but of course the rationale should be mentioned.
> 
> That would be useful information. We also could mark some bindings
> unstable and accept breaking ABI under certain conditions, like that it
> is early work without users for long time.

I don't want to discourage a vendor that's clearly doing a good job of
working on things before they've even taped things out, which is why I
suggested sending clocks/pinctrl as RFC until things are finalised.
I'm not sure what a good way to mention this in the bindings would be,
particularly for clock/pinctrl definitions where things could change
"behind the back" of a user - I'm thinking things like U-Boot here.
  
Rob Herring Feb. 23, 2024, 12:24 a.m. UTC | #5
On Wed, Feb 21, 2024 at 08:24:26AM +0100, Krzysztof Kozlowski wrote:
> On 20/02/2024 20:10, Conor Dooley wrote:
> > On Tue, Feb 20, 2024 at 09:11:43AM +0100, Krzysztof Kozlowski wrote:
> >> On 20/02/2024 07:42, Alex Soo wrote:
> >>> Add documentation and header file for JH8100 pinctrl driver.
> >>>
> >>> Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
> >>> ---
> >>
> >>
> >> RFC? Why isn't this patch ready for review?
> > 
> > The TL;DR is that Emil and I didn't want to apply the dts patches to
> > support a platform that hadn't actually been taped out yet. 
> > For an SoC in that state, at least the bindings for, clock and pinctrl
> > could be subject to changes before tapeou. I think putting RFC on those
> > patches is a good idea, but of course the rationale should be mentioned.
> 
> That would be useful information. We also could mark some bindings
> unstable and accept breaking ABI under certain conditions, like that it
> is early work without users for long time.

The challenge with that is when do things get marked stable? No one has 
any motivation to do that (unless users complain). For example, We have 
a couple of platforms that have an unstable bindings statement that has 
been there "forever".

I would like a solution though. The only idea I have is passing 
SystemReady cert, but that's an Arm thing.

Rob
  
Krzysztof Kozlowski Feb. 24, 2024, 8:46 a.m. UTC | #6
On 23/02/2024 01:24, Rob Herring wrote:
> On Wed, Feb 21, 2024 at 08:24:26AM +0100, Krzysztof Kozlowski wrote:
>> On 20/02/2024 20:10, Conor Dooley wrote:
>>> On Tue, Feb 20, 2024 at 09:11:43AM +0100, Krzysztof Kozlowski wrote:
>>>> On 20/02/2024 07:42, Alex Soo wrote:
>>>>> Add documentation and header file for JH8100 pinctrl driver.
>>>>>
>>>>> Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
>>>>> ---
>>>>
>>>>
>>>> RFC? Why isn't this patch ready for review?
>>>
>>> The TL;DR is that Emil and I didn't want to apply the dts patches to
>>> support a platform that hadn't actually been taped out yet. 
>>> For an SoC in that state, at least the bindings for, clock and pinctrl
>>> could be subject to changes before tapeou. I think putting RFC on those
>>> patches is a good idea, but of course the rationale should be mentioned.
>>
>> That would be useful information. We also could mark some bindings
>> unstable and accept breaking ABI under certain conditions, like that it
>> is early work without users for long time.
> 
> The challenge with that is when do things get marked stable? No one has 
> any motivation to do that (unless users complain). For example, We have 
> a couple of platforms that have an unstable bindings statement that has 
> been there "forever".

I see. Let's see what I can do for existing "unstable" platforms, but
your argument makes sense - rarely people remember to un-unstable
bindings and there aren't that many incentives for maintainer to do so.

> 
> I would like a solution though. The only idea I have is passing 
> SystemReady cert, but that's an Arm thing.


Best regards,
Krzysztof
  
Conor Dooley Feb. 24, 2024, 7:20 p.m. UTC | #7
On Sat, Feb 24, 2024 at 09:46:53AM +0100, Krzysztof Kozlowski wrote:
> > I would like a solution though. The only idea I have is passing 
> > SystemReady cert, but that's an Arm thing.

I don't know jack about SystemReady - I had it in my head that it was a
system level certification. I am wondering how you think that
SystemReady certification would apply to a whole binding (I can see it
being a per-compatible thing, but that would be a mess I am sure).
  
Rob Herring Feb. 28, 2024, 5:03 p.m. UTC | #8
On Sat, Feb 24, 2024 at 07:20:30PM +0000, Conor Dooley wrote:
> On Sat, Feb 24, 2024 at 09:46:53AM +0100, Krzysztof Kozlowski wrote:
> > > I would like a solution though. The only idea I have is passing 
> > > SystemReady cert, but that's an Arm thing.
> 
> I don't know jack about SystemReady

AIUI, Risc-V is working on something similar... 

The primary intent of it is to enable installing off-the-shelf OSs.

> - I had it in my head that it was a
> system level certification. I am wondering how you think that
> SystemReady certification would apply to a whole binding (I can see it
> being a per-compatible thing, but that would be a mess I am sure).

There's a lot of pieces, but I'll stick to the DT aspects (which is 
SystemReady IR band). Certification applies to a specific firmware build 
(which includes the DTB) on a specific board. The testing requirements 
at the moment (for 2.x) are every binding (compatible) must have a 
schema, but warnings are allowed. 

So a "stable" tag would apply to a DTS as a whole. That of course 
implies that everything within the DTS is stable too. 

One wrinkle is that SR has no direct requirement that the DTB come from 
anything upstream. Indirectly, the schemas must exist and be upstream 
(or acked on the lists) and various distro kernels have to actually 
boot. For that reason, if we had some tag, it would have to be 
distinct from SR.

Rob
  
Conor Dooley Feb. 28, 2024, 7:34 p.m. UTC | #9
On 28 February 2024 17:03:38 GMT, Rob Herring <robh@kernel.org> wrote:
>On Sat, Feb 24, 2024 at 07:20:30PM +0000, Conor Dooley wrote:
>> On Sat, Feb 24, 2024 at 09:46:53AM +0100, Krzysztof Kozlowski wrote:
>> > > I would like a solution though. The only idea I have is passing 
>> > > SystemReady cert, but that's an Arm thing.
>> 
>> I don't know jack about SystemReady
>
>AIUI, Risc-V is working on something similar... 

Probably, but there's a few other things they need to ratify first w.r.t. booting before they're at the point of implementing something like SR.
They still seem to think they need to invent their own discovery mechanism, so my hopes aren't super high for what they produce.

>
>The primary intent of it is to enable installing off-the-shelf OSs.
>
>> - I had it in my head that it was a
>> system level certification. I am wondering how you think that
>> SystemReady certification would apply to a whole binding (I can see it
>> being a per-compatible thing, but that would be a mess I am sure).
>
>There's a lot of pieces, but I'll stick to the DT aspects (which is 
>SystemReady IR band). Certification applies to a specific firmware build 
>(which includes the DTB) on a specific board. The testing requirements 
>at the moment (for 2.x) are every binding (compatible) must have a 
>schema, but warnings are allowed. 
>
>So a "stable" tag would apply to a DTS as a whole. That of course 
>implies that everything within the DTS is stable too. 

Right, so it would be on a per-compatible basis then. I guess not altogether different from marking a compatible deprecated.

>One wrinkle is that SR has no direct requirement that the DTB come from 
>anything upstream. Indirectly, the schemas must exist and be upstream 
>(or acked on the lists) and various distro kernels have to actually 
>boot. For that reason, if we had some tag, it would have to be 
>distinct from SR.

And for the reason that other architectures may want to use it I suppose!
  

Patch

diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-aon-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-aon-pinctrl.yaml
new file mode 100644
index 000000000000..ada40deca993
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-aon-pinctrl.yaml
@@ -0,0 +1,261 @@ 
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/starfive,jh8100-aon-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH8100 AON (always-on) Pin Controller
+
+description: |
+  Pinctrl bindings for JH8100 RISC-V SoC from StarFive Technology Ltd.
+
+  The JH8100 SoC has 4 pinctrl domains - sys_east, sys_west, sys_gmac, and aon.
+  This document provides an overview of the "aon" pinctrl domain.
+
+  The "aon" domain has a pin controller which provides
+  - I/O multiplexing for peripheral signals specific to this domain.
+  - GPIO pins which support external GPIO interrupts or external wake-up.
+  - syscon registers to configure device I/O reference voltage.
+
+  In the AON Pin Controller, the pins named PAD_RGPIO0 to PAD_GPIO15 can be
+  multiplexed and have configurable bias, drive strength, schmitt trigger etc.
+  Only peripherals in the AON domain can have their I/O go through the 16
+  "PAD_RGPIOs". This includes I2C, UART, watchdog, eMMC, SDIO0, XSPI etc.
+
+  All these peripherals can be connected to any of the 16 PAD_RGPIOs in such a way
+  that any iopad can be set up to be controlled by any of the peripherals.
+
+  The pin muxing is illustrated by the diagram below.
+                          _____________
+                         |             |
+    RGPIO0 --------------|             |--- PAD_RGPIO0
+    RGPIO1 --------------| AON I/O MUX |--- PAD_RGPIO1
+      ...                |             |       ...
+    I2C8 SDA interface --|             |--- PAD_RGPIO15
+                         |             |
+                          -------------
+
+  The AON Pin Controller provides syscon registers to configure
+
+  1.  reference voltage of
+     - eMMC I/O interface
+         supported voltage - 1.8V
+     - SDIO0 I/O interface
+         supported voltage - 3.3V, 1.8V
+     - PAD_RGPIO bank
+        - 16 PAD_RGPIOs (PAD_RGPIO0 to PAD_GPIO15)
+        - all devices attached to PAD_RGPIOs must use I/O voltage 3.3V.
+     - XSPI I/O interface
+         supported voltage level - 3.3V
+
+     Regulator supplies the device voltage, and each device has a corresponding syscon
+     register bit [1:0] that must be configured to indicate the device voltage level.
+
+     +--------+--------+-------------------+
+     | Bit[1] | Bit[0] | Reference Voltage |
+     +--------+--------+-------------------+
+     |   0    |   0    |     3.3 V         |
+     +--------+--------+-------------------+
+     |   0    |   1    |     2.5 V         |
+     +--------+--------+-------------------+
+     |   1    |   x    |     1.8 V         |
+     +--------+--------+-------------------+
+
+  2. reference voltage and slew rate of GMAC0
+
+     Voltage level on GMAC0 interface is dependent on the PHY that it is pairing with. The
+     supported voltage levels are 3.3V, 2.5V, and 1.8V.
+
+     GMAC0 has 2 set of syscon registers -
+
+     2.1 PAD_VREF_GMAC0_syscon - bit [1:0] must be configured to indicate the voltage level on
+     GMAC0 interface. The default setting is 3.3V.
+
+     +--------+--------+-----------------------------------+
+     | Bit[1] | Bit[0] | GMAC0 Interface Reference Voltage |
+     +--------+--------+-----------------------------------+
+     |   0    |   0    |        3.3V                       |
+     +--------+--------+-----------------------------------+
+     |   0    |   1    |        2.5V                       |
+     +--------+--------+-----------------------------------+
+     |   1    |   x    |        1.8V                       |
+     +--------+--------+-----------------------------------+
+
+     2.2 PAD_GMAC0_<SIGNAL_NAME>_syscon - each GMAC0 pad has a corresponding syscon bit [0] set
+     to 0 by default. When GMAC0 mode is RGMII and voltage level is 2.5V, the bit [0] must be
+     set to 1.
+
+     +-------------+-----------------------+---------+
+     | GMAC0 Mode  |  GMAC0 Voltage Level  |  Bit[0] |
+     +-------------+-----------------------+---------+
+     |             |        3.3V           |    0    |
+     |             |-----------------------+---------+
+     |   RGMII     |        2.5V           |    1    |
+     |             |-----------------------+---------+
+     |             |        1.8V           |    0    |
+     +-------------+-----------------------+---------+
+     |             |        3.3V           |    0    |
+     |             |-----------------------+---------+
+     |   RMII      |        2.5V           |    0    |
+     |             |-----------------------+---------+
+     |             |        1.8V           |    0    |
+     +-------------+-----------------------+---------+
+
+     the bit [2] can be used to configure GMAC0 signal slew rate,
+
+     +--------+-----------+
+     | Bit[2] | Slew Rate |
+     +--------+-----------+
+     |   0    |   Fast    |
+     +--------+-----------+
+     |   1    |   Slow    |
+     +--------+-----------+
+
+  Under any circumstances, the syscon register's reference voltage setting must not be
+  lower than the actual device voltage, otherwise, the device I/O pads will get damaged.
+
+  Follow the guidelines below when configure reference voltage -
+
+  To increase the device voltage, set bit [1:0] to the new operating state first before
+  raising the actual voltage to the higher operating point.
+
+  To decrease the device voltage, hold bit [1:0] to the current operating state until
+  the actual voltage has stabilized at the lower operating point before changing the
+  setting.
+
+  Alternatively, a device voltage change can always be initiated by first setting syscon
+  register bit [1:0] = 0, the safe 3.3V startup condition, before changing the device
+  voltage. Then once the actual voltage is changed and has stabilized at the new operating
+  point, bit [1:0] can be reset as appropriate.
+
+maintainers:
+  - Alex Soo <yuklin.soo@starfivetech.com>
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - const: starfive,jh8100-aon-pinctrl
+          - const: syscon
+          - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  interrupt-controller: true
+
+  gpio-controller: true
+
+  '#gpio-cells':
+    const: 2
+
+  gpio-ranges:
+    maxItems: 1
+
+  wakeup-gpios:
+    maxItems: 1
+    description: GPIO pin to be used for waking up the system from sleep mode.
+
+  wakeup-source:
+    maxItems: 1
+    description: to indicate pinctrl has wakeup capability.
+
+patternProperties:
+  '-grp$':
+    type: object
+    additionalProperties: false
+    patternProperties:
+      '-pins$':
+        type: object
+        description: |
+          A pinctrl node should contain at least one subnode representing the
+          pinctrl groups available in the domain. Each subnode will list the
+          pins it needs, and how they should be configured, with regard to
+          muxer configuration, bias, input enable/disable, input schmitt
+          trigger enable/disable, slew-rate and drive strength.
+        allOf:
+          - $ref: /schemas/pinctrl/pincfg-node.yaml
+          - $ref: /schemas/pinctrl/pinmux-node.yaml
+        additionalProperties: false
+
+        properties:
+          pinmux:
+            description: |
+              The list of GPIOs and their mux settings or function select.
+              The GPIOMUX and PINMUX macros are used to configure the
+              I/O multiplexing and function selection respectively.
+
+          bias-disable: true
+
+          bias-pull-up:
+            type: boolean
+
+          bias-pull-down:
+            type: boolean
+
+          drive-strength-microamp:
+            enum: [ 2000, 4000, 8000, 12000 ]
+
+          input-enable: true
+
+          input-disable: true
+
+          input-schmitt-enable: true
+
+          input-schmitt-disable: true
+
+          slew-rate:
+            enum: [ 0, 1 ]
+            default: 0
+            description: |
+                0: slow (half frequency)
+                1: fast
+
+required:
+  - compatible
+  - reg
+  - resets
+  - interrupts
+  - interrupt-controller
+  - gpio-controller
+  - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pinctrl_aon: pinctrl@1f300000 {
+            compatible = "starfive,jh8100-aon-pinctrl", "syscon", "simple-mfd";
+            reg = <0x0 0x1f300000 0x0 0x10000>;
+            resets = <&aoncrg 0>;
+            interrupts = <160>;
+            interrupt-controller;
+            gpio-controller;
+            #gpio-cells = <2>;
+            gpio-ranges = <&pinctrl_aon 0 0 16>;
+
+            i2c7_pins: i2c7-grp {
+                i2c7-scl-pins {
+                    pinmux = <0x23265409>;
+                    bias-pull-up;
+                    input-enable;
+                };
+
+                i2c7-sda-pins {
+                    pinmux = <0x2427580a>;
+                    bias-pull-up;
+                    input-enable;
+                };
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-east-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-east-pinctrl.yaml
new file mode 100644
index 000000000000..3ea336cb7563
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-east-pinctrl.yaml
@@ -0,0 +1,223 @@ 
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/starfive,jh8100-sys-east-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH8100 SYS_EAST Pin Controller
+
+description: |
+  Pinctrl bindings for JH8100 RISC-V SoC from StarFive Technology Ltd.
+
+  The JH8100 SoC has 4 pinctrl domains - sys_east, sys_west, sys_gmac, and aon.
+  This document provides an overview of the "sys_east" pinctrl domain.
+
+  The "sys_east" domain has a pin controller which provides
+  - I/O multiplexing for peripheral signals specific to this domain.
+  - function selection for GPIO pads.
+  - GPIO interrupt handling.
+  - syscon for device voltage reference.
+
+  In the SYS_EAST Pin Controller, the pins named PAD_GPIO0_E to PAD_GPIO47_E can
+  be multiplexed and have configurable bias, drive strength, schmitt trigger etc.
+  Only peripherals in the SYS_EAST domain can have their I/O go through the 48
+  "PAD_GPIOs". This includes CANs, I2Cs, I2Ss, SPIs, UARTs, PWMs, SMBUS0, SDIO1 etc.
+
+  All these peripherals can be connected to any of the 48 PAD_GPIOs in such a way
+  that any iopad can be set up to be controlled by any of the peripherals.
+
+  The pin muxing is illustrated by the diagram below.
+                                 __________________
+                                |                  |
+    GPIO0 ----------------------|                  |--- PAD_GPIO0_E
+    GPIO1 ----------------------| SYS_EAST I/O MUX |--- PAD_GPIO1_E
+    GPIO2 ----------------------|                  |--- PAD_GPIO2_E
+      ...                       |                  |      ...
+    I2C0 Clock interface -------|                  |--- PAD_GPIO9_E
+    I2C0 Data interface  -------|                  |--- PAD_GPIO10_E
+      ...                       |                  |      ...
+    UART0 transmit interface ---|                  |--- PAD_GPIO20_E
+    UART0 receive interface ----|                  |--- PAD_GPIO21_E
+      ...                       |                  |       ...
+    GPIO47 ---------------------|                  |--- PAD_GPIO47_E
+                                |                  |
+                                 ------------------
+
+  Alternatively, the "PAD_GPIOs" can be multiplexed to other peripherals through
+  function selection. Each iopad has a maximum of up to 3 functions - 0, 1, and 2.
+  Function 0 is the default function or peripheral signal of an iopad.
+  The function 1 and function 2 are other optional functions or peripheral signals
+  available to an iopad. The function selection can be carried out by writing the
+  function number to the iopad function select register.
+
+  The "sys_east" domain has 4 PAD_GPIO banks -
+  E0 - 16 PAD_GPIOs (PAD_GPIO0_E to PAD_GPIO15_E)
+  E1 - 16 PAD_GPIOs (PAD_GPIO16_E to PAD_GPIO31_E)
+  E2 -  8 PAD_GPIOs (PAD_GPIO32_E to PAD_GPIO39_E)
+  E3 -  8 PAD_GPIOs (PAD_GPIO40_E to PAD_GPIO47_E)
+
+  Each PAD_GPIO bank can be set to a voltage level 3.3V or 1.8V. All devices attached
+  to the PAD_GPIOs must use the same I/O voltage level as the bank voltage setting.
+  This allows user to select different I/O voltages for their devices. For instance,
+  the UART have 3.3V/1.8V requirement, the UART devices that use 1.8V are attached
+  to a PAD_GPIO bank which is configured to 1.8V.
+
+  Regulators supply voltages to the PAD_GPIO banks, and each PAD_GPIO bank has a corresponding
+  syscon bit [1:0] that must be configured to indicate its voltage level. The default setting
+  is 3.3V.
+
+  +--------+--------+-------------------+
+  | Bit[1] | Bit[0] | Reference Voltage |
+  +--------+--------+-------------------+
+  |   0    |   0    |     3.3 V         |
+  +--------+--------+-------------------+
+  |   1    |   x    |     1.8 V         |
+  +--------+--------+-------------------+
+
+  Under any circumstances, the syscon register's reference voltage setting must not be
+  lower than the actual device voltage, otherwise, the device I/O pads will get damaged.
+
+  Follow the guidelines below when configure reference voltage -
+
+  To increase the device voltage, set bit [1:0] to the new operating state first before
+  raising the actual voltage to the higher operating point.
+
+  To decrease the device voltage, hold bit [1:0] to the current operating state until
+  the actual voltage has stabilized at the lower operating point before changing the
+  setting.
+
+  Alternatively, a device voltage change can always be initiated by first setting syscon
+  register bit [1:0] = 0, the safe 3.3V startup condition, before changing the device
+  voltage. Then once the actual voltage is changed and has stabilized at the new operating
+  point, bit [1:0] can be reset as appropriate.
+
+maintainers:
+  - Alex Soo <yuklin.soo@starfivetech.com>
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - const: starfive,jh8100-sys-pinctrl-east
+          - const: syscon
+          - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  interrupt-controller: true
+
+  gpio-controller: true
+
+  '#gpio-cells':
+    const: 2
+
+  gpio-ranges:
+    maxItems: 1
+
+  gpio-line-names: true
+
+patternProperties:
+  '-grp$':
+    type: object
+    additionalProperties: false
+    patternProperties:
+      '-pins$':
+        type: object
+        description: |
+          A pinctrl node should contain at least one subnode representing the
+          pinctrl groups available in the domain. Each subnode will list the
+          pins it needs, and how they should be configured, with regard to
+          muxer configuration, bias, input enable/disable, input schmitt
+          trigger enable/disable, slew-rate and drive strength.
+        allOf:
+          - $ref: /schemas/pinctrl/pincfg-node.yaml
+          - $ref: /schemas/pinctrl/pinmux-node.yaml
+        additionalProperties: false
+
+        properties:
+          pinmux:
+            description: |
+              The list of GPIOs and their mux settings or function select.
+              The GPIOMUX and PINMUX macros are used to configure the
+              I/O multiplexing and function selection respectively.
+
+          bias-disable: true
+
+          bias-pull-up:
+            type: boolean
+
+          bias-pull-down:
+            type: boolean
+
+          drive-strength-microamp:
+            enum: [ 2000, 4000, 8000, 12000 ]
+
+          input-enable: true
+
+          input-disable: true
+
+          input-schmitt-enable: true
+
+          input-schmitt-disable: true
+
+          slew-rate:
+            enum: [ 0, 1 ]
+            default: 0
+            description: |
+                0: slow (half frequency)
+                1: fast
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+  - interrupts
+  - interrupt-controller
+  - gpio-controller
+  - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pinctrl_east: pinctrl@122d0000 {
+            compatible = "starfive,jh8100-sys-pinctrl-east", "syscon", "simple-mfd";
+            reg = <0x0 0x122d0000 0x0 0x10000>;
+            clocks = <&syscrg_ne 153>;
+            resets = <&syscrg_ne 48>;
+            interrupts = <182>;
+            interrupt-controller;
+            gpio-controller;
+            #gpio-cells = <2>;
+            gpio-ranges = <&pinctrl_east 0 0 48>;
+
+            smbus0_pins: smbus0-grp {
+                smbus0-scl-pins {
+                    pinmux = <0x1122480b>;
+                    bias-pull-up;
+                    input-enable;
+                };
+
+                smbus0-sda-pins {
+                    pinmux = <0x12234c0c>;
+                    bias-pull-up;
+                    input-enable;
+                };
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-gmac-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-gmac-pinctrl.yaml
new file mode 100644
index 000000000000..879b096f61f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-gmac-pinctrl.yaml
@@ -0,0 +1,163 @@ 
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/starfive,jh8100-sys-gmac-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH8100 SYS_GMAC Pin Controller
+
+description: |
+  Pinctrl bindings for JH8100 RISC-V SoC from StarFive Technology Ltd.
+
+  The JH8100 SoC has 4 pinctrl domains - sys_east, sys_west, sys_gmac, and aon.
+  This document provides an overview of the "sys_gmac" pinctrl domain.
+
+  The "sys_gmac" domain has a pin-controller which provides syscon registers to
+  configure device reference voltage and slew rate.
+
+  The SYS_GMAC Pin Controller does not have any PAD_GPIOs, therefore, it does not
+  support the GPIO pad I/O Multiplexing and interrupt handling.
+
+  The SYS_GMAC Pin Controller provides syscon registers to configure
+
+  1. reference voltage of SDIO1
+
+     The supported voltage levels are 3.3V and 1.8V
+
+     The bit [1:0] must be configured to indicate the SDIO1 voltage level.
+
+     +--------+--------+--------------------------+
+     | Bit[1] | Bit[0] |  SDIO1 Reference Voltage |
+     +--------+--------+--------------------------+
+     |   0    |   0    |       3.3 V              |
+     +--------+--------+--------------------------+
+     |   1    |   0    |       1.8 V              |
+     +--------+--------+--------------------------+
+
+  2. reference voltage and slew rate of GMAC1
+
+     Voltage level on GMAC1 interface is dependent on the PHY that it is pairing with. The
+     supported voltage levels are 3.3V, 2.5V, and 1.8V.
+
+     GMAC1 has 2 set of syscon registers -
+
+     2.1 PAD_VREF_GMAC1_syscon - bit [1:0] must be configured to indicate the voltage level on
+     GMAC1 interface. The default setting is 3.3V.
+
+     +--------+--------+-----------------------------------+
+     | Bit[1] | Bit[0] | GMAC1 Interface Reference Voltage |
+     +--------+--------+-----------------------------------+
+     |   0    |   0    |        3.3V                       |
+     +--------+--------+-----------------------------------+
+     |   0    |   1    |        2.5V                       |
+     +--------+--------+-----------------------------------+
+     |   1    |   x    |        1.8V                       |
+     +--------+--------+-----------------------------------+
+
+     2.2 PAD_GMAC1_<SIGNAL_NAME>_syscon - each GMAC1 pad has a corresponding syscon bit [0] set
+     to 0 by default. When GMAC1 mode is RGMII and voltage level is 2.5V, the bit [0] must be
+     set to 1.
+
+     +-------------+-----------------------+---------+
+     | GMAC1 Mode  |  GMAC1 Voltage Level  |  Bit[0] |
+     +-------------+-----------------------+---------+
+     |             |        3.3V           |    0    |
+     |             |-----------------------+---------+
+     |   RGMII     |        2.5V           |    1    |
+     |             |-----------------------+---------+
+     |             |        1.8V           |    0    |
+     +-------------+-----------------------+---------+
+     |             |        3.3V           |    0    |
+     |             |-----------------------+---------+
+     |   RMII      |        2.5V           |    0    |
+     |             |-----------------------+---------+
+     |             |        1.8V           |    0    |
+     +-------------+-----------------------+---------+
+
+     the bit [2] can be used to configure the GMAC1 signal slew rate,
+
+     +--------+-----------+
+     | Bit[2] | Slew Rate |
+     +--------+-----------+
+     |   0    |   Fast    |
+     +--------+-----------+
+     |   1    |   Slow    |
+     +--------+-----------+
+
+  Under any circumstances, the syscon register's reference voltage setting must not be
+  lower than the actual voltage, otherwise, the device I/O pads will get damaged.
+
+  Follow the guidelines below when configure reference voltage -
+
+  To increase the device voltage, set bit [1:0] to the new operating state first before
+  raising the actual voltage to the higher operating point.
+
+  To decrease the device voltage, hold bit [1:0] to the current operating state until
+  the actual voltage has stabilized at the lower operating point before changing the
+  setting.
+
+  Alternatively, a device voltage change can always be initiated by first setting syscon
+  register bit [1:0] = 0, the safe 3.3V startup condition, before changing the device
+  voltage. Then once the actual voltage is changed and has stabilized at the new operating
+  point, bit [1:0] can be reset as appropriate.
+
+maintainers:
+  - Alex Soo <yuklin.soo@starfivetech.com>
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - const: starfive,jh8100-sys-pinctrl-gmac
+          - const: syscon
+          - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+patternProperties:
+  '-grp$':
+    type: object
+    additionalProperties: false
+    patternProperties:
+      '-pins$':
+        type: object
+        description: |
+          A pinctrl node should contain at least one subnode representing the
+          pinctrl groups available in the domain. Each subnode will list the
+          pins it needs, and how they should be configured, with regard to
+          muxer configuration, bias, input enable/disable, input schmitt
+          trigger enable/disable, slew-rate and drive strength.
+        allOf:
+          - $ref: /schemas/pinctrl/pincfg-node.yaml
+          - $ref: /schemas/pinctrl/pinmux-node.yaml
+        additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pinctrl_gmac: pinctrl@12770000 {
+            compatible = "starfive,jh8100-sys-pinctrl-gmac", "syscon", "simple-mfd";
+            reg = <0x0 0x12770000 0x0 0x10000>;
+            clocks = <&gmac_sdio_crg 16>;
+            resets = <&gmac_sdio_crg 3>;
+        };
+
+    };
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-west-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-west-pinctrl.yaml
new file mode 100644
index 000000000000..431dd540d32c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh8100-sys-west-pinctrl.yaml
@@ -0,0 +1,220 @@ 
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/starfive,jh8100-sys-west-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH8100 SYS_WEST Pin Controller
+
+description: |
+  Pinctrl bindings for JH8100 RISC-V SoC from StarFive Technology Ltd.
+
+  The JH8100 SoC has 4 pinctrl domains - sys_east, sys_west, sys_gmac, and aon.
+  This document provides an overview of the "sys_west" pinctrl domain.
+
+  The "sys_west" domain has a pin-controller which provides
+  - I/O multiplexing for peripheral signals specific to this domain.
+  - function selection for GPIO pads.
+  - GPIO interrupt handling.
+  - syscon for device voltage reference.
+
+  In the SYS_WEST Pin Controller, the pins named PAD_GPIO0_W to PAD_GPIO15_W can
+  be multiplexed and have configurable bias, drive strength, schmitt trigger etc.
+  Only peripherals in the SYS_WEST domain can have their I/O go through the 16
+  "PAD_GPIOs". This includes I2Cs, HD_AUDIO, HIFI4, SPIs, UARTs, SMBUS1 etc.
+
+  All these peripherals can be connected to any of the 16 PAD_GPIOs in such a way
+  that any iopad can be set up to be controlled by any of the peripherals.
+
+  The pin muxing is illustrated by the diagram below.
+                                 __________________
+                                |                  |
+    GPIO0 ----------------------|                  |--- PAD_GPIO0_W
+    GPIO1 ----------------------| SYS_WEST I/O MUX |--- PAD_GPIO1_W
+    GPIO2 ----------------------|                  |--- PAD_GPIO2_W
+      ...                       |                  |      ...
+    HIFI4 JTAG TDO interface ---|                  |--- PAD_GPIO10_W
+    HIFI4 JTAG TDI interface ---|                  |--- PAD_GPIO11_W
+    SMBUS1 Data interface  -----|                  |--- PAD_GPIO12_W
+    SMBUS1 Clock interface -----|                  |--- PAD_GPIO13_W
+      ...                       |                  |      ...
+    GPIO14 ---------------------|                  |--- PAD_GPIO14_W
+    GPIO15 ---------------------|                  |--- PAD_GPIO15_W
+                                |                  |
+                                 ------------------
+
+  Alternatively, the "PAD_GPIOs" can be multiplexed to other peripherals through
+  function selection. Each iopad has a maximum of up to 3 functions - 0, 1, and 2.
+  Function 0 is the default function or peripheral signal of an iopad.
+  The function 1 and function 2 are other optional functions or peripheral signals
+  available to an iopad. The function selection can be carried out by writing the
+  function number to the iopad function select register.
+
+  The "sys_west" domain has one PAD_GPIO bank -
+  W0 - 16 PAD_GPIOs (PAD_GPIO0_W to PAD_GPIO15_W)
+
+  The PAD_GPIO bank can be set to voltage level 3.3V or 1.8V. All devices attached
+  to the PAD_GPIOs must use the same I/O voltage level as the bank voltage setting.
+  This allows user to select different I/O voltages for their devices. For instance,
+  the UART have 3.3V/1.8V requirement, the UART devices that use 1.8V are attached
+  to a PAD_GPIO bank which is configured to 1.8V.
+
+  Regulator supplies voltage to the PAD_GPIO bank, and the PAD_GPIO bank has a
+  corresponding syscon bit [1:0] that must be configured to indicate its voltage
+  level. The default voltage setting of each PAD_GPIO bank is 3.3V.
+
+  +--------+--------+-------------------+
+  | Bit[1] | Bit[0] | Reference Voltage |
+  +--------+--------+-------------------+
+  |   0    |   0    |     3.3 V         |
+  +--------+--------+-------------------+
+  |   1    |   x    |     1.8 V         |
+  +--------+--------+-------------------+
+
+  Under any circumstances, the syscon register's reference voltage setting must not be
+  lower than the actual device voltage, otherwise, the device I/O pads will get damaged.
+
+  Follow the guidelines below when configure reference voltage -
+
+  To increase the device voltage, set bit [1:0] to the new operating state first before
+  raising the actual voltage to the higher operating point.
+
+  To decrease the device voltage, hold bit [1:0] to the current operating state until
+  the actual voltage has stabilized at the lower operating point before changing the
+  setting.
+
+  Alternatively, a device voltage change can always be initiated by first setting syscon
+  register bit [1:0] = 0, the safe 3.3V startup condition, before changing the device
+  voltage. Then once the actual voltage is changed and has stabilized at the new operating
+  point, bit [1:0] can be reset as appropriate.
+
+maintainers:
+  - Alex Soo <yuklin.soo@starfivetech.com>
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - const: starfive,jh8100-sys-pinctrl-west
+          - const: syscon
+          - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  interrupt-controller: true
+
+  gpio-controller: true
+
+  '#gpio-cells':
+    const: 2
+
+  gpio-ranges:
+    maxItems: 1
+
+  gpio-line-names: true
+
+patternProperties:
+  '-grp$':
+    type: object
+    additionalProperties: false
+    patternProperties:
+      '-pins$':
+        type: object
+        description: |
+          A pinctrl node should contain at least one subnode representing the
+          pinctrl groups available in the domain. Each subnode will list the
+          pins it needs, and how they should be configured, with regard to
+          muxer configuration, bias, input enable/disable, input schmitt
+          trigger enable/disable, slew-rate and drive strength.
+        allOf:
+          - $ref: /schemas/pinctrl/pincfg-node.yaml
+          - $ref: /schemas/pinctrl/pinmux-node.yaml
+        additionalProperties: false
+
+        properties:
+          pinmux:
+            description: |
+              The list of GPIOs and their mux settings or function select.
+              The GPIOMUX and PINMUX macros are used to configure the
+              I/O multiplexing and function selection respectively.
+
+          bias-disable: true
+
+          bias-pull-up:
+            type: boolean
+
+          bias-pull-down:
+            type: boolean
+
+          drive-strength-microamp:
+            enum: [ 2000, 4000, 8000, 12000 ]
+
+          input-enable: true
+
+          input-disable: true
+
+          input-schmitt-enable: true
+
+          input-schmitt-disable: true
+
+          slew-rate:
+            enum: [ 0, 1 ]
+            default: 0
+            description: |
+                0: slow (half frequency)
+                1: fast
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+  - interrupts
+  - interrupt-controller
+  - gpio-controller
+  - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pinctrl_west: pinctrl@123e0000 {
+            compatible = "starfive,jh8100-sys-pinctrl-west", "syscon", "simple-mfd";
+            reg = <0x0 0x123e0000 0x0 0x10000>;
+            clocks = <&syscrg_nw 6>;
+            resets = <&syscrg_nw 1>;
+            interrupts = <183>;
+            interrupt-controller;
+            gpio-controller;
+            #gpio-cells = <2>;
+            gpio-ranges = <&pinctrl_west 0 0 16>;
+
+            smbus1_pins: smbus1-grp {
+                smbus1-scl-pins {
+                    pinmux = <0x1014300d>;
+                    bias-pull-up;
+                    input-enable;
+                };
+
+                smbus1-sda-pins {
+                    pinmux = <0x1115340c>;
+                    bias-pull-up;
+                    input-enable;
+                };
+            };
+        };
+    };
diff --git a/include/dt-bindings/pinctrl/starfive,jh8100-pinctrl.h b/include/dt-bindings/pinctrl/starfive,jh8100-pinctrl.h
new file mode 100644
index 000000000000..055bac7eb2a6
--- /dev/null
+++ b/include/dt-bindings/pinctrl/starfive,jh8100-pinctrl.h
@@ -0,0 +1,103 @@ 
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/*
+ * Copyright (C) 2023-2024 StarFive Technology Co., Ltd.
+ */
+
+#ifndef __DT_BINDINGS_PINCTRL_STARFIVE_JH8100_H__
+#define __DT_BINDINGS_PINCTRL_STARFIVE_JH8100_H__
+
+/* sys_iomux_west pins */
+#define PAD_GPIO0_W				0
+#define PAD_GPIO1_W				1
+#define PAD_GPIO2_W				2
+#define PAD_GPIO3_W				3
+#define PAD_GPIO4_W				4
+#define PAD_GPIO5_W				5
+#define PAD_GPIO6_W				6
+#define PAD_GPIO7_W				7
+#define PAD_GPIO8_W				8
+#define PAD_GPIO9_W				9
+#define PAD_GPIO10_W				10
+#define PAD_GPIO11_W				11
+#define PAD_GPIO12_W				12
+#define PAD_GPIO13_W				13
+#define PAD_GPIO14_W				14
+#define PAD_GPIO15_W				15
+
+/* sys_iomux_east pins */
+#define PAD_GPIO0_E				0
+#define PAD_GPIO1_E				1
+#define PAD_GPIO2_E				2
+#define PAD_GPIO3_E				3
+#define PAD_GPIO4_E				4
+#define PAD_GPIO5_E				5
+#define PAD_GPIO6_E				6
+#define PAD_GPIO7_E				7
+#define PAD_GPIO8_E				8
+#define PAD_GPIO9_E				9
+#define PAD_GPIO10_E				10
+#define PAD_GPIO11_E				11
+#define PAD_GPIO12_E				12
+#define PAD_GPIO13_E				13
+#define PAD_GPIO14_E				14
+#define PAD_GPIO15_E				15
+#define PAD_GPIO16_E				16
+#define PAD_GPIO17_E				17
+#define PAD_GPIO18_E				18
+#define PAD_GPIO19_E				19
+#define PAD_GPIO20_E				20
+#define PAD_GPIO21_E				21
+#define PAD_GPIO22_E				22
+#define PAD_GPIO23_E				23
+#define PAD_GPIO24_E				24
+#define PAD_GPIO25_E				25
+#define PAD_GPIO26_E				26
+#define PAD_GPIO27_E				27
+#define PAD_GPIO28_E				28
+#define PAD_GPIO29_E				29
+#define PAD_GPIO30_E				30
+#define PAD_GPIO31_E				31
+#define PAD_GPIO32_E				32
+#define PAD_GPIO33_E				33
+#define PAD_GPIO34_E				34
+#define PAD_GPIO35_E				35
+#define PAD_GPIO36_E				36
+#define PAD_GPIO37_E				37
+#define PAD_GPIO38_E				38
+#define PAD_GPIO39_E				39
+#define PAD_GPIO40_E				40
+#define PAD_GPIO41_E				41
+#define PAD_GPIO42_E				42
+#define PAD_GPIO43_E				43
+#define PAD_GPIO44_E				44
+#define PAD_GPIO45_E				45
+#define PAD_GPIO46_E				46
+#define PAD_GPIO47_E				47
+
+/* aon_iomux pins */
+#define PAD_RGPIO0				0
+#define PAD_RGPIO1				1
+#define PAD_RGPIO2				2
+#define PAD_RGPIO3				3
+#define PAD_RGPIO4				4
+#define PAD_RGPIO5				5
+#define PAD_RGPIO6				6
+#define PAD_RGPIO7				7
+#define PAD_RGPIO8				8
+#define PAD_RGPIO9				9
+#define PAD_RGPIO10				10
+#define PAD_RGPIO11				11
+#define PAD_RGPIO12				12
+#define PAD_RGPIO13				13
+#define PAD_RGPIO14				14
+#define PAD_RGPIO15				15
+
+#define GPOUT_LOW				0
+#define GPOUT_HIGH				1
+
+#define GPOEN_ENABLE				0
+#define GPOEN_DISABLE				1
+
+#define GPI_NONE				255
+
+#endif