[PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Andre Przywara]

The AXP305 PMIC used in AXP805 seems to be fully compatible to the
AXP805 PMIC, so add the proper chain of compatible strings.

Also at least on one board (Orangepi Zero2) there is no interrupt line
connected to the CPU, so make the "interrupts" property optional.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 4991a6415796..4fd748101e3c 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -26,10 +26,10 @@ Required properties:
     * "x-powers,axp803"
     * "x-powers,axp806"
     * "x-powers,axp805", "x-powers,axp806"
+    * "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"
     * "x-powers,axp809"
     * "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
-- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
 - #interrupt-cells: Should be set to 1
 
@@ -43,6 +43,7 @@ more information:
 			AXP20x/LDO3: software-based implementation
 
 Optional properties:
+- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
 		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
 		      AXP22X/8XX: range: 1800-4050, Default: 3   MHz
-- 
2.17.5

Re: [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Rob Herring]

On Wed, May 19, 2021 at 11:41:36AM +0100, Andre Przywara wrote:
> The AXP305 PMIC used in AXP805 seems to be fully compatible to the
> AXP805 PMIC, so add the proper chain of compatible strings.
> 
> Also at least on one board (Orangepi Zero2) there is no interrupt line
> connected to the CPU, so make the "interrupts" property optional.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Don't you want to convert this to schema? It's one of the last warnings 
for sunxi IIRC.

Acked-by: Rob Herring <robh@kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 4991a6415796..4fd748101e3c 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -26,10 +26,10 @@ Required properties:
>      * "x-powers,axp803"
>      * "x-powers,axp806"
>      * "x-powers,axp805", "x-powers,axp806"
> +    * "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"
>      * "x-powers,axp809"
>      * "x-powers,axp813"
>  - reg: The I2C slave address or RSB hardware address for the AXP chip
> -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - interrupt-controller: The PMIC has its own internal IRQs
>  - #interrupt-cells: Should be set to 1
>  
> @@ -43,6 +43,7 @@ more information:
>  			AXP20x/LDO3: software-based implementation
>  
>  Optional properties:
> +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
>  		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
>  		      AXP22X/8XX: range: 1800-4050, Default: 3   MHz
> -- 
> 2.17.5
> 

Re: [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Samuel Holland]

On 5/19/21 5:41 AM, Andre Przywara wrote:
> The AXP305 PMIC used in AXP805 seems to be fully compatible to the
                  ^^^^^^^^^^^^^^
Typo? Do you mean "used with the H616 SoC"?

> AXP805 PMIC, so add the proper chain of compatible strings.
> 
> Also at least on one board (Orangepi Zero2) there is no interrupt line
> connected to the CPU, so make the "interrupts" property optional.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 4991a6415796..4fd748101e3c 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -26,10 +26,10 @@ Required properties:
>      * "x-powers,axp803"
>      * "x-powers,axp806"
>      * "x-powers,axp805", "x-powers,axp806"
> +    * "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"
                   ^^^^^^
This should be x-powers,axp305.

Regards,
Samuel

>      * "x-powers,axp809"
>      * "x-powers,axp813"
>  - reg: The I2C slave address or RSB hardware address for the AXP chip
> -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - interrupt-controller: The PMIC has its own internal IRQs
>  - #interrupt-cells: Should be set to 1
>  
> @@ -43,6 +43,7 @@ more information:
>  			AXP20x/LDO3: software-based implementation
>  
>  Optional properties:
> +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
>  		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
>  		      AXP22X/8XX: range: 1800-4050, Default: 3   MHz
> 

Re: [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Andre Przywara]

On Sat, 22 May 2021 09:46:23 -0500
Samuel Holland <samuel@sholland.org> wrote:

> On 5/19/21 5:41 AM, Andre Przywara wrote:
> > The AXP305 PMIC used in AXP805 seems to be fully compatible to the  
>                   ^^^^^^^^^^^^^^
> Typo? Do you mean "used with the H616 SoC"?

Ouch, yes. And even more embarrassingly Chen-Yu pointed that out already
in the previous version. Same for the compatible string.

Thanks for having a look!

Cheers,
Andre

> 
> > AXP805 PMIC, so add the proper chain of compatible strings.
> > 
> > Also at least on one board (Orangepi Zero2) there is no interrupt line
> > connected to the CPU, so make the "interrupts" property optional.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> > index 4991a6415796..4fd748101e3c 100644
> > --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> > +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> > @@ -26,10 +26,10 @@ Required properties:
> >      * "x-powers,axp803"
> >      * "x-powers,axp806"
> >      * "x-powers,axp805", "x-powers,axp806"
> > +    * "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"  
>                    ^^^^^^
> This should be x-powers,axp305.
> 
> Regards,
> Samuel
> 
> >      * "x-powers,axp809"
> >      * "x-powers,axp813"
> >  - reg: The I2C slave address or RSB hardware address for the AXP chip
> > -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> >  - interrupt-controller: The PMIC has its own internal IRQs
> >  - #interrupt-cells: Should be set to 1
> >  
> > @@ -43,6 +43,7 @@ more information:
> >  			AXP20x/LDO3: software-based implementation
> >  
> >  Optional properties:
> > +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> >  - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
> >  		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
> >  		      AXP22X/8XX: range: 1800-4050, Default: 3   MHz
> >   
> 
> 

[PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing RTC binding.
The actual RTC part of the device uses a different day/month/year
storage scheme, so it's not compatible with the previous devices.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index b1b0ee769b71..178c955f88bf 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -26,6 +26,7 @@ properties:
           - const: allwinner,sun50i-a64-rtc
           - const: allwinner,sun8i-h3-rtc
       - const: allwinner,sun50i-h6-rtc
+      - const: allwinner,sun50i-h616-rtc
 
   reg:
     maxItems: 1
@@ -97,7 +98,9 @@ allOf:
       properties:
         compatible:
           contains:
-            const: allwinner,sun50i-h6-rtc
+            enum:
+              - allwinner,sun50i-h6-rtc
+              - allwinner,sun50i-h616-rtc
 
     then:
       properties:
-- 
2.17.5

Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Rob Herring]

On Wed, 19 May 2021 11:41:38 +0100, Andre Przywara wrote:
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Samuel Holland]

Andre,

On 5/19/21 5:41 AM, Andre Przywara wrote:
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> index b1b0ee769b71..178c955f88bf 100644
> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> @@ -26,6 +26,7 @@ properties:
>            - const: allwinner,sun50i-a64-rtc
>            - const: allwinner,sun8i-h3-rtc
>        - const: allwinner,sun50i-h6-rtc
> +      - const: allwinner,sun50i-h616-rtc
>  
>    reg:
>      maxItems: 1
> @@ -97,7 +98,9 @@ allOf:
>        properties:
>          compatible:
>            contains:
> -            const: allwinner,sun50i-h6-rtc
> +            enum:
> +              - allwinner,sun50i-h6-rtc
> +              - allwinner,sun50i-h616-rtc
>  
>      then:
>        properties:
> 

This binding is missing a clock reference for the pll-periph0-2x input
to the 32kHz clock fanout.

It is also missing a clock reference to the RTC register gate (and that
clock is in turn missing from the r_ccu driver).

Regards,
Samuel

Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Thu, 20 May 2021 21:37:34 -0500
Samuel Holland <samuel@sholland.org> wrote:

Hi,

> On 5/19/21 5:41 AM, Andre Przywara wrote:
> > Add the obvious compatible name to the existing RTC binding.
> > The actual RTC part of the device uses a different day/month/year
> > storage scheme, so it's not compatible with the previous devices.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > index b1b0ee769b71..178c955f88bf 100644
> > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > @@ -26,6 +26,7 @@ properties:
> >            - const: allwinner,sun50i-a64-rtc
> >            - const: allwinner,sun8i-h3-rtc
> >        - const: allwinner,sun50i-h6-rtc
> > +      - const: allwinner,sun50i-h616-rtc
> >  
> >    reg:
> >      maxItems: 1
> > @@ -97,7 +98,9 @@ allOf:
> >        properties:
> >          compatible:
> >            contains:
> > -            const: allwinner,sun50i-h6-rtc
> > +            enum:
> > +              - allwinner,sun50i-h6-rtc
> > +              - allwinner,sun50i-h616-rtc
> >  
> >      then:
> >        properties:
> >   
> 
> This binding is missing a clock reference for the pll-periph0-2x input
> to the 32kHz clock fanout.

Right. So do I get this correctly that we don't model the OSC24M input
explicitly so far in the DT? I only see one possible input clock, which
is for an optional 32K crystal oscillator.
And this means we need to change some code also? Because at the moment
a clock specified is assumed to be the 32K OSC, and having this clock
means we switch to the external 32K OSC.
And who would decide which clock source to use? What would be the
reason to use PLL_PERIPH(2x) over the RC16M based clock or the
divided down 24MHz?

So shall we ignore the PLL based input clock for now, put "0 input
clocks" in the current binding, then later on extend this to allow
choosing the PLL? And have it that way that having the PLL reference
means we use it?

> It is also missing a clock reference to the RTC register gate (and that
> clock is in turn missing from the r_ccu driver).

Do you mean a gate bit somewhere in the PRCM? Do you have any
pointer/documentation for that?

Cheers,
Andre

Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Samuel Holland]

On 6/7/21 7:59 AM, Andre Przywara wrote:
> On Thu, 20 May 2021 21:37:34 -0500
> Samuel Holland <samuel@sholland.org> wrote:
> 
> Hi,
> 
>> On 5/19/21 5:41 AM, Andre Przywara wrote:
>>> Add the obvious compatible name to the existing RTC binding.
>>> The actual RTC part of the device uses a different day/month/year
>>> storage scheme, so it's not compatible with the previous devices.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> index b1b0ee769b71..178c955f88bf 100644
>>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> @@ -26,6 +26,7 @@ properties:
>>>            - const: allwinner,sun50i-a64-rtc
>>>            - const: allwinner,sun8i-h3-rtc
>>>        - const: allwinner,sun50i-h6-rtc
>>> +      - const: allwinner,sun50i-h616-rtc
>>>  
>>>    reg:
>>>      maxItems: 1
>>> @@ -97,7 +98,9 @@ allOf:
>>>        properties:
>>>          compatible:
>>>            contains:
>>> -            const: allwinner,sun50i-h6-rtc
>>> +            enum:
>>> +              - allwinner,sun50i-h6-rtc
>>> +              - allwinner,sun50i-h616-rtc
>>>  
>>>      then:
>>>        properties:
>>>   
>>
>> This binding is missing a clock reference for the pll-periph0-2x input
>> to the 32kHz clock fanout.
> 
> Right. So do I get this correctly that we don't model the OSC24M input
> explicitly so far in the DT? I only see one possible input clock, which
> is for an optional 32K crystal oscillator.
> And this means we need to change some code also? Because at the moment
> a clock specified is assumed to be the 32K OSC, and having this clock
> means we switch to the external 32K OSC.

Right. The code would need updates to follow the binding.

> And who would decide which clock source to use? What would be the
> reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> divided down 24MHz?

Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
expects 32768 Hz.

> So shall we ignore the PLL based input clock for now, put "0 input
> clocks" in the current binding, then later on extend this to allow
> choosing the PLL? And have it that way that having the PLL reference
> means we use it?

No, the device tree represents the hardware, not whatever happens to be
used by Linux drivers at the time. It should be in the binding
regardless of what the driver does with it.

Though the circular dependency between the clock providers does cause
problems. We cannot get a clk_hw for the PLL-based clock, so we would
have to hardcode a global name for it, which means we aren't really
using the device tree.

We already see this "not really using the binding" with the other CCUs:
the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
"dcxo24M" for the same clock. So moving that clock into the RTC clock
provider would require using both names in one clk_hw simultaneously (or
rather fixing the CCU drivers to get a clk_hw from the DT instead of
referencing by name).

And trying to deal with optional clocks by index is only going to get
more painful over time. For example, with the R329 and D1, the RTC has
the following inputs:
 * DCXO24M (unless you model it inside the RTC)
 * External OSC32k (optional!)
 * The RTC bus gate/reset from the PRCM
 * R-AHB from the PRCM for the RTC SPI clock domain

So it seems time to start using clock-names in the RTC binding.

>> It is also missing a clock reference to the RTC register gate (and that
>> clock is in turn missing from the r_ccu driver).
> 
> Do you mean a gate bit somewhere in the PRCM? Do you have any
> pointer/documentation for that?

Yes, it's bit 0 of PRCM+0x20c, documented in the BSP[1], used in
mainline[2], and verified by experiment.

[1]:
https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/clk/sunxi/clk-sun50iw9.h#L169
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c#n129

> Cheers,
> Andre

Regards,
Samuel

Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Mon, 7 Jun 2021 23:23:04 -0500
Samuel Holland <samuel@sholland.org> wrote:

Hi Samuel,

> On 6/7/21 7:59 AM, Andre Przywara wrote:
> > On Thu, 20 May 2021 21:37:34 -0500
> > Samuel Holland <samuel@sholland.org> wrote:
> > 
> > Hi,
> >   
> >> On 5/19/21 5:41 AM, Andre Przywara wrote:  
> >>> Add the obvious compatible name to the existing RTC binding.
> >>> The actual RTC part of the device uses a different day/month/year
> >>> storage scheme, so it's not compatible with the previous devices.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>> ---
> >>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> index b1b0ee769b71..178c955f88bf 100644
> >>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> @@ -26,6 +26,7 @@ properties:
> >>>            - const: allwinner,sun50i-a64-rtc
> >>>            - const: allwinner,sun8i-h3-rtc
> >>>        - const: allwinner,sun50i-h6-rtc
> >>> +      - const: allwinner,sun50i-h616-rtc
> >>>  
> >>>    reg:
> >>>      maxItems: 1
> >>> @@ -97,7 +98,9 @@ allOf:
> >>>        properties:
> >>>          compatible:
> >>>            contains:
> >>> -            const: allwinner,sun50i-h6-rtc
> >>> +            enum:
> >>> +              - allwinner,sun50i-h6-rtc
> >>> +              - allwinner,sun50i-h616-rtc
> >>>  
> >>>      then:
> >>>        properties:
> >>>     
> >>
> >> This binding is missing a clock reference for the pll-periph0-2x input
> >> to the 32kHz clock fanout.  
> > 
> > Right. So do I get this correctly that we don't model the OSC24M input
> > explicitly so far in the DT? I only see one possible input clock, which
> > is for an optional 32K crystal oscillator.
> > And this means we need to change some code also? Because at the moment
> > a clock specified is assumed to be the 32K OSC, and having this clock
> > means we switch to the external 32K OSC.  
> 
> Right. The code would need updates to follow the binding.

I changed the binding for now to not allow any clock, and the code to
ignore any clocks when the H616 compatible is used. This way we can
extend this later without breaking anything.

> > And who would decide which clock source to use? What would be the
> > reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> > divided down 24MHz?  
> 
> Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
> expects 32768 Hz.

I thought about this as well, but this means there is no reason to not
use the PLL? At least not for Linux (normal operation with PLLs
running anyway)? This situation is different for the other SoCs, because
boards *might* have a separate and more precise 32K crystal.
So we could code this similar to the other SoCs: If we have a clock
property defined, we assume it's pointing to the PLL and switch to use
it?

But, looking at the diagram in the manual (and assuming it's
correct), the PLL based clock can only be routed to the pad, but cannot
be used for the RTC. That seems to be also the case for the T5, which
has an external LOSC pin.
 
> > So shall we ignore the PLL based input clock for now, put "0 input
> > clocks" in the current binding, then later on extend this to allow
> > choosing the PLL? And have it that way that having the PLL reference
> > means we use it?  
> 
> No, the device tree represents the hardware, not whatever happens to be
> used by Linux drivers at the time. It should be in the binding
> regardless of what the driver does with it.

I understand that very well, but was just looking for a solution where
we can go ahead with an easier solution *now*. I am afraid implementing
this annoying RTC special snowflake properly will just delay the whole
series.
In the long run your "D1 & friends" extra RTC clock driver looks the
right way out, but it will probably take some more time to get this
merged.
 
> Though the circular dependency between the clock providers does cause
> problems. We cannot get a clk_hw for the PLL-based clock, so we would
> have to hardcode a global name for it, which means we aren't really
> using the device tree.

I start to wonder how much business Linux really has in controlling all
those RTC details. The current code happens to work, because everything
is setup correctly already, on reset.

> We already see this "not really using the binding" with the other CCUs:
> the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
> "dcxo24M" for the same clock. So moving that clock into the RTC clock
> provider would require using both names in one clk_hw simultaneously (or
> rather fixing the CCU drivers to get a clk_hw from the DT instead of
> referencing by name).
> 
> And trying to deal with optional clocks by index is only going to get
> more painful over time. For example, with the R329 and D1, the RTC has
> the following inputs:
>  * DCXO24M (unless you model it inside the RTC)
>  * External OSC32k (optional!)
>  * The RTC bus gate/reset from the PRCM
>  * R-AHB from the PRCM for the RTC SPI clock domain
> 
> So it seems time to start using clock-names in the RTC binding.

Yes, that sounds reasonable. It's just a shame that we keep changing
the RTC bindings, and so creating a lot of incompatibility on the way.

> >> It is also missing a clock reference to the RTC register gate (and that
> >> clock is in turn missing from the r_ccu driver).  
> > 
> > Do you mean a gate bit somewhere in the PRCM? Do you have any
> > pointer/documentation for that?  
> 
> Yes, it's bit 0 of PRCM+0x20c, documented in the BSP[1], used in
> mainline[2], and verified by experiment.

I can confirm this, also by experimentation. And the H6 seems to have
the same bit.
But what purpose would this bit solve? I don't see a good reason to
describe this in the DT, it's more like a turn-off bit for firmware?

Cheers,
Andre

 
> [1]:
> https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/clk/sunxi/clk-sun50iw9.h#L169
> [2]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c#n129
> 
> > Cheers,
> > Andre  
> 
> Regards,
> Samuel

Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Maxime Ripard]

Hi,

On Tue, Jun 15, 2021 at 01:24:40PM +0100, Andre Przywara wrote:
> > On 6/7/21 7:59 AM, Andre Przywara wrote:
> > > On Thu, 20 May 2021 21:37:34 -0500
> > > Samuel Holland <samuel@sholland.org> wrote:
> > > 
> > > Hi,
> > >   
> > >> On 5/19/21 5:41 AM, Andre Przywara wrote:  
> > >>> Add the obvious compatible name to the existing RTC binding.
> > >>> The actual RTC part of the device uses a different day/month/year
> > >>> storage scheme, so it's not compatible with the previous devices.
> > >>>
> > >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > >>> ---
> > >>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
> > >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > >>> index b1b0ee769b71..178c955f88bf 100644
> > >>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > >>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > >>> @@ -26,6 +26,7 @@ properties:
> > >>>            - const: allwinner,sun50i-a64-rtc
> > >>>            - const: allwinner,sun8i-h3-rtc
> > >>>        - const: allwinner,sun50i-h6-rtc
> > >>> +      - const: allwinner,sun50i-h616-rtc
> > >>>  
> > >>>    reg:
> > >>>      maxItems: 1
> > >>> @@ -97,7 +98,9 @@ allOf:
> > >>>        properties:
> > >>>          compatible:
> > >>>            contains:
> > >>> -            const: allwinner,sun50i-h6-rtc
> > >>> +            enum:
> > >>> +              - allwinner,sun50i-h6-rtc
> > >>> +              - allwinner,sun50i-h616-rtc
> > >>>  
> > >>>      then:
> > >>>        properties:
> > >>>     
> > >>
> > >> This binding is missing a clock reference for the pll-periph0-2x input
> > >> to the 32kHz clock fanout.  
> > > 
> > > Right. So do I get this correctly that we don't model the OSC24M input
> > > explicitly so far in the DT? I only see one possible input clock, which
> > > is for an optional 32K crystal oscillator.
> > > And this means we need to change some code also? Because at the moment
> > > a clock specified is assumed to be the 32K OSC, and having this clock
> > > means we switch to the external 32K OSC.  
> > 
> > Right. The code would need updates to follow the binding.
> 
> I changed the binding for now to not allow any clock, and the code to
> ignore any clocks when the H616 compatible is used. This way we can
> extend this later without breaking anything.

I'm not really a fan of this: it just creates one more special case that
we'll have to take into account later on, complicating further the logic
that is already way too complicated.

> > > And who would decide which clock source to use? What would be the
> > > reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> > > divided down 24MHz?  
> > 
> > Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
> > expects 32768 Hz.
> 
> I thought about this as well, but this means there is no reason to not
> use the PLL? At least not for Linux (normal operation with PLLs
> running anyway)? This situation is different for the other SoCs, because
> boards *might* have a separate and more precise 32K crystal.
> So we could code this similar to the other SoCs: If we have a clock
> property defined, we assume it's pointing to the PLL and switch to use
> it?

We have another option though: list all the clocks that could be
available for a 32khz source, call clk_get_accuracy on them, and then
use the clock with the best accuracy. We already have the accuracy
requirements in the datasheet for each crystal, so it shouldn't be too
hard to support.

> But, looking at the diagram in the manual (and assuming it's
> correct), the PLL based clock can only be routed to the pad, but cannot
> be used for the RTC. That seems to be also the case for the T5, which
> has an external LOSC pin.
>  
> > > So shall we ignore the PLL based input clock for now, put "0 input
> > > clocks" in the current binding, then later on extend this to allow
> > > choosing the PLL? And have it that way that having the PLL reference
> > > means we use it?  
> > 
> > No, the device tree represents the hardware, not whatever happens to be
> > used by Linux drivers at the time. It should be in the binding
> > regardless of what the driver does with it.
> 
> I understand that very well, but was just looking for a solution where
> we can go ahead with an easier solution *now*. I am afraid implementing
> this annoying RTC special snowflake properly will just delay the whole
> series.
> In the long run your "D1 & friends" extra RTC clock driver looks the
> right way out, but it will probably take some more time to get this
> merged.

To be honest, I'm not entirely sure why we need the rtc in the first
place. If your plan is to figure it out later anyway, why not just model
the 32kHz clock as a fixed clock, and change it later once it's been
entirely figured out?

> > Though the circular dependency between the clock providers does cause
> > problems. We cannot get a clk_hw for the PLL-based clock, so we would
> > have to hardcode a global name for it, which means we aren't really
> > using the device tree.
> 
> I start to wonder how much business Linux really has in controlling all
> those RTC details. The current code happens to work, because everything
> is setup correctly already, on reset.

That's not true for all the SoCs.

> > We already see this "not really using the binding" with the other CCUs:
> > the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
> > "dcxo24M" for the same clock. So moving that clock into the RTC clock
> > provider would require using both names in one clk_hw simultaneously (or
> > rather fixing the CCU drivers to get a clk_hw from the DT instead of
> > referencing by name).
> > 
> > And trying to deal with optional clocks by index is only going to get
> > more painful over time. For example, with the R329 and D1, the RTC has
> > the following inputs:
> >  * DCXO24M (unless you model it inside the RTC)
> >  * External OSC32k (optional!)
> >  * The RTC bus gate/reset from the PRCM
> >  * R-AHB from the PRCM for the RTC SPI clock domain
> > 
> > So it seems time to start using clock-names in the RTC binding.
> 
> Yes, that sounds reasonable. It's just a shame that we keep changing
> the RTC bindings, and so creating a lot of incompatibility on the way.

I mean, we keep changing it because the hardware keeps changing. The RTC
on the A20 had no clock at all. The A31 later on got only a single clock
input, and a single output. If your point is that we should have known
better 9 years ago what the current SoCs would look like, that's a bit
absurd, don't you think?

Maxime

Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Wed, 16 Jun 2021 11:07:00 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

Hi,

> On Tue, Jun 15, 2021 at 01:24:40PM +0100, Andre Przywara wrote:
> > > On 6/7/21 7:59 AM, Andre Przywara wrote:  
> > > > On Thu, 20 May 2021 21:37:34 -0500
> > > > Samuel Holland <samuel@sholland.org> wrote:
> > > > 
> > > > Hi,
> > > >     
> > > >> On 5/19/21 5:41 AM, Andre Przywara wrote:    
> > > >>> Add the obvious compatible name to the existing RTC binding.
> > > >>> The actual RTC part of the device uses a different day/month/year
> > > >>> storage scheme, so it's not compatible with the previous devices.
> > > >>>
> > > >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > >>> ---
> > > >>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
> > > >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> index b1b0ee769b71..178c955f88bf 100644
> > > >>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> @@ -26,6 +26,7 @@ properties:
> > > >>>            - const: allwinner,sun50i-a64-rtc
> > > >>>            - const: allwinner,sun8i-h3-rtc
> > > >>>        - const: allwinner,sun50i-h6-rtc
> > > >>> +      - const: allwinner,sun50i-h616-rtc
> > > >>>  
> > > >>>    reg:
> > > >>>      maxItems: 1
> > > >>> @@ -97,7 +98,9 @@ allOf:
> > > >>>        properties:
> > > >>>          compatible:
> > > >>>            contains:
> > > >>> -            const: allwinner,sun50i-h6-rtc
> > > >>> +            enum:
> > > >>> +              - allwinner,sun50i-h6-rtc
> > > >>> +              - allwinner,sun50i-h616-rtc
> > > >>>  
> > > >>>      then:
> > > >>>        properties:
> > > >>>       
> > > >>
> > > >> This binding is missing a clock reference for the pll-periph0-2x input
> > > >> to the 32kHz clock fanout.    
> > > > 
> > > > Right. So do I get this correctly that we don't model the OSC24M input
> > > > explicitly so far in the DT? I only see one possible input clock, which
> > > > is for an optional 32K crystal oscillator.
> > > > And this means we need to change some code also? Because at the moment
> > > > a clock specified is assumed to be the 32K OSC, and having this clock
> > > > means we switch to the external 32K OSC.    
> > > 
> > > Right. The code would need updates to follow the binding.  
> > 
> > I changed the binding for now to not allow any clock, and the code to
> > ignore any clocks when the H616 compatible is used. This way we can
> > extend this later without breaking anything.  
> 
> I'm not really a fan of this: it just creates one more special case that
> we'll have to take into account later on, complicating further the logic
> that is already way too complicated.

I see your point, but that's why I made it a no-clock choice: we can
add clocks any time later, older kernels finding them in newer DTs will
ignore them, older DTs on newer kernels wouldn't instantiate them in
the first place.

> 
> > > > And who would decide which clock source to use? What would be the
> > > > reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> > > > divided down 24MHz?    
> > > 
> > > Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
> > > expects 32768 Hz.  
> > 
> > I thought about this as well, but this means there is no reason to not
> > use the PLL? At least not for Linux (normal operation with PLLs
> > running anyway)? This situation is different for the other SoCs, because
> > boards *might* have a separate and more precise 32K crystal.
> > So we could code this similar to the other SoCs: If we have a clock
> > property defined, we assume it's pointing to the PLL and switch to use
> > it?  
> 
> We have another option though: list all the clocks that could be
> available for a 32khz source, call clk_get_accuracy on them, and then
> use the clock with the best accuracy. We already have the accuracy
> requirements in the datasheet for each crystal, so it shouldn't be too
> hard to support.

That would possibly be an option, yes. What makes this further
complicated though is that there are several LOSC outputs: one going
to the RTC, one going to other peripherals, one going to the pad. And
they can have different sources, at least on the H616: the RTC and
system clock can't be driven by the PLL or divided down HOSC, just by
the RC oscillator. But all three of them can supply the clock to the
pad. I guess another reason to separate clock and actual RTC.

> > But, looking at the diagram in the manual (and assuming it's
> > correct), the PLL based clock can only be routed to the pad, but cannot
> > be used for the RTC. That seems to be also the case for the T5, which
> > has an external LOSC pin.
> >    
> > > > So shall we ignore the PLL based input clock for now, put "0 input
> > > > clocks" in the current binding, then later on extend this to allow
> > > > choosing the PLL? And have it that way that having the PLL reference
> > > > means we use it?    
> > > 
> > > No, the device tree represents the hardware, not whatever happens to be
> > > used by Linux drivers at the time. It should be in the binding
> > > regardless of what the driver does with it.  
> > 
> > I understand that very well, but was just looking for a solution where
> > we can go ahead with an easier solution *now*. I am afraid implementing
> > this annoying RTC special snowflake properly will just delay the whole
> > series.
> > In the long run your "D1 & friends" extra RTC clock driver looks the
> > right way out, but it will probably take some more time to get this
> > merged.  
> 
> To be honest, I'm not entirely sure why we need the rtc in the first
> place. If your plan is to figure it out later anyway, why not just model
> the 32kHz clock as a fixed clock, and change it later once it's been
> entirely figured out?

This would be a way out, at the cost of making newer DTs not work on
this kernel (the H616 RTC compatible wouldn't be recognised). I have to
check how fatal this is, IIRC pinctrl and CCU still work somehow (it's
only needed for debounce, which is optional?)
But if this is the price to pay to get it into 5.14 ... 
 
> > > Though the circular dependency between the clock providers does cause
> > > problems. We cannot get a clk_hw for the PLL-based clock, so we would
> > > have to hardcode a global name for it, which means we aren't really
> > > using the device tree.  
> > 
> > I start to wonder how much business Linux really has in controlling all
> > those RTC details. The current code happens to work, because everything
> > is setup correctly already, on reset.  
> 
> That's not true for all the SoCs.

Yes, this was not meant to be an universal statement, but as you
mention above, we get pretty far with ignoring the RTC completely, even.
 
> > > We already see this "not really using the binding" with the other CCUs:
> > > the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
> > > "dcxo24M" for the same clock. So moving that clock into the RTC clock
> > > provider would require using both names in one clk_hw simultaneously (or
> > > rather fixing the CCU drivers to get a clk_hw from the DT instead of
> > > referencing by name).
> > > 
> > > And trying to deal with optional clocks by index is only going to get
> > > more painful over time. For example, with the R329 and D1, the RTC has
> > > the following inputs:
> > >  * DCXO24M (unless you model it inside the RTC)
> > >  * External OSC32k (optional!)
> > >  * The RTC bus gate/reset from the PRCM
> > >  * R-AHB from the PRCM for the RTC SPI clock domain
> > > 
> > > So it seems time to start using clock-names in the RTC binding.  
> > 
> > Yes, that sounds reasonable. It's just a shame that we keep changing
> > the RTC bindings, and so creating a lot of incompatibility on the way.  
> 
> I mean, we keep changing it because the hardware keeps changing. The RTC
> on the A20 had no clock at all. The A31 later on got only a single clock
> input, and a single output. If your point is that we should have known
> better 9 years ago what the current SoCs would look like, that's a bit
> absurd, don't you think?

I don't mean changing the binding between SoCs, this is of course not
very reasonable, especially if dealing with Allwinner, who apparently
have little regard to something like "compatibility" and like to spread
new bits around various peripherals that happens to have free space.

I was referring to changing existing bindings for one particular SoC,
like we did in the past when adding the <&rtc 2> clock output.
And I am just afraid this will happen again if we start to support the
RTC "properly" now, for instance for the H6.

Cheers,
Andre

[PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing EMAC binding, and pair
it with the existing A64 fallback compatible string, as the devices are
compatible.

On the way use enums to group the compatible devices together.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml    | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 7f2578d48e3f..0ccdab103f59 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -19,7 +19,9 @@ properties:
       - const: allwinner,sun8i-v3s-emac
       - const: allwinner,sun50i-a64-emac
       - items:
-          - const: allwinner,sun50i-h6-emac
+          - enum:
+              - allwinner,sun50i-h6-emac
+              - allwinner,sun50i-h616-emac
           - const: allwinner,sun50i-a64-emac
 
   reg:
-- 
2.17.5

Re: [PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string

[Rob Herring]

On Wed, 19 May 2021 11:41:41 +0100, Andre Przywara wrote:
> Add the obvious compatible name to the existing EMAC binding, and pair
> it with the existing A64 fallback compatible string, as the devices are
> compatible.
> 
> On the way use enums to group the compatible devices together.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml    | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string

[Andre Przywara]

The H616 has four PHYs as the H3, along with their respective clock
gates and resets, so the property description is identical.

However the PHYs itself need some special bits, so we need a new
compatible string for it.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
index f80431060803..e288450e0844 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
@@ -15,7 +15,9 @@ properties:
     const: 1
 
   compatible:
-    const: allwinner,sun8i-h3-usb-phy
+    enum:
+      - allwinner,sun8i-h3-usb-phy
+      - allwinner,sun50i-h616-usb-phy
 
   reg:
     items:
-- 
2.17.5

Re: [PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string

[Rob Herring]

On Wed, 19 May 2021 11:41:43 +0100, Andre Przywara wrote:
> The H616 has four PHYs as the H3, along with their respective clock
> gates and resets, so the property description is identical.
> 
> However the PHYs itself need some special bits, so we need a new
> compatible string for it.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml   | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v6 09/17] dt-bindings: usb: sunxi-musb: Add H616 compatible string

[Andre Przywara]

The H616 MUSB peripheral is compatible to the H3 one (8 endpoints).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
---
 .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml      | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
index 0f520f17735e..933fa356d2ce 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
@@ -22,6 +22,9 @@ properties:
               - allwinner,sun8i-a83t-musb
               - allwinner,sun50i-h6-musb
           - const: allwinner,sun8i-a33-musb
+      - items:
+          - const: allwinner,sun50i-h616-musb
+          - const: allwinner,sun8i-h3-musb
 
   reg:
     maxItems: 1
-- 
2.17.5

Re: [PATCH v6 09/17] dt-bindings: usb: sunxi-musb: Add H616 compatible string

[Rob Herring]

On Wed, 19 May 2021 11:41:44 +0100, Andre Przywara wrote:
> The H616 MUSB peripheral is compatible to the H3 one (8 endpoints).
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Maxime Ripard <mripard@kernel.org>
> ---
>  .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml      | 3 +++
>  1 file changed, 3 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Andre Przywara]

This (relatively) new SoC is similar to the H6, but drops the (broken)
PCIe support and the USB 3.0 controller. It also gets the management
controller removed, which in turn removes *some*, but not all of the
devices formerly dedicated to the ARISC (CPUS).
And while there is still the extra sunxi interrupt controller, the
package lacks the corresponding NMI pin, so no interrupts for the PMIC.

USB is a bit tricky: host controller 0, 1 and 3 depend on some help from
controller and PHY 2, so we need to include one reset line and one
clock gate from HCI 2 into every other HCI node, plus need some nasty
quirk.

The reserved memory node is actually handled by Trusted Firmware now,
but U-Boot fails to propagate this to a separately loaded DTB, so we
keep it in here for now, until U-Boot learns to do this properly.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 747 ++++++++++++++++++
 1 file changed, 747 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
new file mode 100644
index 000000000000..30195e4779de
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -0,0 +1,747 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Arm Ltd.
+// based on the H6 dtsi, which is:
+//   Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun50i-h616-ccu.h>
+#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
+#include <dt-bindings/reset/sun50i-h616-ccu.h>
+#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			compatible = "arm,cortex-a53";
+			device_type = "cpu";
+			reg = <0>;
+			enable-method = "psci";
+			clocks = <&ccu CLK_CPUX>;
+		};
+
+		cpu1: cpu@1 {
+			compatible = "arm,cortex-a53";
+			device_type = "cpu";
+			reg = <1>;
+			enable-method = "psci";
+			clocks = <&ccu CLK_CPUX>;
+		};
+
+		cpu2: cpu@2 {
+			compatible = "arm,cortex-a53";
+			device_type = "cpu";
+			reg = <2>;
+			enable-method = "psci";
+			clocks = <&ccu CLK_CPUX>;
+		};
+
+		cpu3: cpu@3 {
+			compatible = "arm,cortex-a53";
+			device_type = "cpu";
+			reg = <3>;
+			enable-method = "psci";
+			clocks = <&ccu CLK_CPUX>;
+		};
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/* 512KiB reserved for ARM Trusted Firmware (BL31) */
+		secmon_reserved: secmon@40000000 {
+			reg = <0x0 0x40000000 0x0 0x80000>;
+			no-map;
+		};
+	};
+
+	osc24M: osc24M_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		clock-output-names = "osc24M";
+	};
+
+	pmu {
+		compatible = "arm,cortex-a53-pmu";
+		interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		arm,no-tick-in-suspend;
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0x0 0x40000000>;
+
+		syscon: syscon@3000000 {
+			compatible = "allwinner,sun50i-h616-system-control";
+			reg = <0x03000000 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			sram_c: sram@28000 {
+				compatible = "mmio-sram";
+				reg = <0x00028000 0x30000>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x00028000 0x30000>;
+			};
+		};
+
+		ccu: clock@3001000 {
+			compatible = "allwinner,sun50i-h616-ccu";
+			reg = <0x03001000 0x1000>;
+			clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
+			clock-names = "hosc", "losc", "iosc";
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+		};
+
+		watchdog: watchdog@30090a0 {
+			compatible = "allwinner,sun50i-h616-wdt",
+				     "allwinner,sun6i-a31-wdt";
+			reg = <0x030090a0 0x20>;
+			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&osc24M>;
+			status = "okay";
+		};
+
+		pio: pinctrl@300b000 {
+			compatible = "allwinner,sun50i-h616-pinctrl";
+			reg = <0x0300b000 0x400>;
+			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc 0>;
+			clock-names = "apb", "hosc", "losc";
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+
+			ext_rgmii_pins: rgmii-pins {
+				pins = "PI0", "PI1", "PI2", "PI3", "PI4",
+				       "PI5", "PI7", "PI8", "PI9", "PI10",
+				       "PI11", "PI12", "PI13", "PI14", "PI15",
+				       "PI16";
+				function = "emac0";
+				drive-strength = <40>;
+			};
+
+			i2c0_pins: i2c0-pins {
+				pins = "PI6", "PI7";
+				function = "i2c0";
+			};
+
+			i2c3_ph_pins: i2c3-ph-pins {
+				pins = "PH4", "PH5";
+				function = "i2c3";
+			};
+
+			ir_rx_pin: ir-rx-pin {
+				pins = "PH10";
+				function = "ir_rx";
+			};
+
+			mmc0_pins: mmc0-pins {
+				pins = "PF0", "PF1", "PF2", "PF3",
+				       "PF4", "PF5";
+				function = "mmc0";
+				drive-strength = <30>;
+				bias-pull-up;
+			};
+
+			mmc1_pins: mmc1-pins {
+				pins = "PG0", "PG1", "PG2", "PG3",
+				       "PG4", "PG5";
+				function = "mmc1";
+				drive-strength = <30>;
+				bias-pull-up;
+			};
+
+			mmc2_pins: mmc2-pins {
+				pins = "PC0", "PC1", "PC5", "PC6",
+				       "PC8", "PC9", "PC10", "PC11",
+				       "PC13", "PC14", "PC15", "PC16";
+				function = "mmc2";
+				drive-strength = <30>;
+				bias-pull-up;
+			};
+
+			spi0_pins: spi0-pins {
+				pins = "PC0", "PC2", "PC3", "PC4";
+				function = "spi0";
+			};
+
+			spi1_pins: spi1-pins {
+				pins = "PH6", "PH7", "PH8";
+				function = "spi1";
+			};
+
+			spi1_cs_pin: spi1-cs-pin {
+				pins = "PH5";
+				function = "spi1";
+			};
+
+			uart0_ph_pins: uart0-ph-pins {
+				pins = "PH0", "PH1";
+				function = "uart0";
+			};
+
+			uart1_pins: uart1-pins {
+				pins = "PG6", "PG7";
+				function = "uart1";
+			};
+
+			uart1_rts_cts_pins: uart1-rts-cts-pins {
+				pins = "PG8", "PG9";
+				function = "uart1";
+			};
+		};
+
+		gic: interrupt-controller@3021000 {
+			compatible = "arm,gic-400";
+			reg = <0x03021000 0x1000>,
+			      <0x03022000 0x2000>,
+			      <0x03024000 0x2000>,
+			      <0x03026000 0x2000>;
+			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+
+		mmc0: mmc@4020000 {
+			compatible = "allwinner,sun50i-h616-mmc",
+				     "allwinner,sun50i-a100-mmc";
+			reg = <0x04020000 0x1000>;
+			clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
+			clock-names = "ahb", "mmc";
+			resets = <&ccu RST_BUS_MMC0>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&mmc0_pins>;
+			status = "disabled";
+			max-frequency = <150000000>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			mmc-ddr-3_3v;
+			mmc-ddr-1_8v;
+			cap-sdio-irq;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc1: mmc@4021000 {
+			compatible = "allwinner,sun50i-h616-mmc",
+				     "allwinner,sun50i-a100-mmc";
+			reg = <0x04021000 0x1000>;
+			clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
+			clock-names = "ahb", "mmc";
+			resets = <&ccu RST_BUS_MMC1>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&mmc1_pins>;
+			status = "disabled";
+			max-frequency = <150000000>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			mmc-ddr-3_3v;
+			mmc-ddr-1_8v;
+			cap-sdio-irq;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc2: mmc@4022000 {
+			compatible = "allwinner,sun50i-h616-emmc",
+				     "allwinner,sun50i-a100-emmc";
+			reg = <0x04022000 0x1000>;
+			clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
+			clock-names = "ahb", "mmc";
+			resets = <&ccu RST_BUS_MMC2>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&mmc2_pins>;
+			status = "disabled";
+			max-frequency = <150000000>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			mmc-ddr-3_3v;
+			mmc-ddr-1_8v;
+			cap-sdio-irq;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		uart0: serial@5000000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x05000000 0x400>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_BUS_UART0>;
+			resets = <&ccu RST_BUS_UART0>;
+			status = "disabled";
+		};
+
+		uart1: serial@5000400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x05000400 0x400>;
+			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_BUS_UART1>;
+			resets = <&ccu RST_BUS_UART1>;
+			status = "disabled";
+		};
+
+		uart2: serial@5000800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x05000800 0x400>;
+			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_BUS_UART2>;
+			resets = <&ccu RST_BUS_UART2>;
+			status = "disabled";
+		};
+
+		uart3: serial@5000c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x05000c00 0x400>;
+			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_BUS_UART3>;
+			resets = <&ccu RST_BUS_UART3>;
+			status = "disabled";
+		};
+
+		uart4: serial@5001000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x05001000 0x400>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_BUS_UART4>;
+			resets = <&ccu RST_BUS_UART4>;
+			status = "disabled";
+		};
+
+		uart5: serial@5001400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x05001400 0x400>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_BUS_UART5>;
+			resets = <&ccu RST_BUS_UART5>;
+			status = "disabled";
+		};
+
+		i2c0: i2c@5002000 {
+			compatible = "allwinner,sun50i-h616-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x05002000 0x400>;
+			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_I2C0>;
+			resets = <&ccu RST_BUS_I2C0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&i2c0_pins>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c1: i2c@5002400 {
+			compatible = "allwinner,sun50i-h616-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x05002400 0x400>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_I2C1>;
+			resets = <&ccu RST_BUS_I2C1>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c2: i2c@5002800 {
+			compatible = "allwinner,sun50i-h616-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x05002800 0x400>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_I2C2>;
+			resets = <&ccu RST_BUS_I2C2>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c3: i2c@5002c00 {
+			compatible = "allwinner,sun50i-h616-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x05002c00 0x400>;
+			interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_I2C3>;
+			resets = <&ccu RST_BUS_I2C3>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c4: i2c@5003000 {
+			compatible = "allwinner,sun50i-h616-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x05003000 0x400>;
+			interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_I2C4>;
+			resets = <&ccu RST_BUS_I2C4>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		spi0: spi@5010000 {
+			compatible = "allwinner,sun50i-h616-spi",
+				     "allwinner,sun8i-h3-spi";
+			reg = <0x05010000 0x1000>;
+			interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;
+			clock-names = "ahb", "mod";
+			resets = <&ccu RST_BUS_SPI0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&spi0_pins>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		spi1: spi@5011000 {
+			compatible = "allwinner,sun50i-h616-spi",
+				     "allwinner,sun8i-h3-spi";
+			reg = <0x05011000 0x1000>;
+			interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_SPI1>, <&ccu CLK_SPI1>;
+			clock-names = "ahb", "mod";
+			resets = <&ccu RST_BUS_SPI1>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&spi1_pins>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		emac0: ethernet@5020000 {
+			compatible = "allwinner,sun50i-h616-emac",
+				     "allwinner,sun50i-a64-emac";
+			syscon = <&syscon>;
+			reg = <0x05020000 0x10000>;
+			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			resets = <&ccu RST_BUS_EMAC0>;
+			reset-names = "stmmaceth";
+			clocks = <&ccu CLK_BUS_EMAC0>;
+			clock-names = "stmmaceth";
+			status = "disabled";
+
+			mdio0: mdio {
+				compatible = "snps,dwmac-mdio";
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+		};
+
+		usbotg: usb@5100000 {
+			compatible = "allwinner,sun50i-h616-musb",
+				     "allwinner,sun8i-h3-musb";
+			reg = <0x05100000 0x0400>;
+			clocks = <&ccu CLK_BUS_OTG>;
+			resets = <&ccu RST_BUS_OTG>;
+			interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "mc";
+			phys = <&usbphy 0>;
+			phy-names = "usb";
+			extcon = <&usbphy 0>;
+			status = "disabled";
+		};
+
+		usbphy: phy@5100400 {
+			compatible = "allwinner,sun50i-h616-usb-phy";
+			reg = <0x05100400 0x24>,
+			      <0x05101800 0x14>,
+			      <0x05200800 0x14>,
+			      <0x05310800 0x14>,
+			      <0x05311800 0x14>;
+			reg-names = "phy_ctrl",
+				    "pmu0",
+				    "pmu1",
+				    "pmu2",
+				    "pmu3";
+			clocks = <&ccu CLK_USB_PHY0>,
+				 <&ccu CLK_USB_PHY1>,
+				 <&ccu CLK_USB_PHY2>,
+				 <&ccu CLK_USB_PHY3>,
+				 <&ccu CLK_BUS_EHCI2>;
+			clock-names = "usb0_phy",
+				      "usb1_phy",
+				      "usb2_phy",
+				      "usb3_phy",
+				      "pmu2_clk";
+			resets = <&ccu RST_USB_PHY0>,
+				 <&ccu RST_USB_PHY1>,
+				 <&ccu RST_USB_PHY2>,
+				 <&ccu RST_USB_PHY3>;
+			reset-names = "usb0_reset",
+				      "usb1_reset",
+				      "usb2_reset",
+				      "usb3_reset";
+			status = "disabled";
+			#phy-cells = <1>;
+		};
+
+		ehci0: usb@5101000 {
+			compatible = "allwinner,sun50i-h616-ehci",
+				     "generic-ehci";
+			reg = <0x05101000 0x100>;
+			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI0>,
+				 <&ccu CLK_BUS_EHCI0>,
+				 <&ccu CLK_USB_OHCI0>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI0>,
+				 <&ccu RST_BUS_EHCI0>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 0>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ohci0: usb@5101400 {
+			compatible = "allwinner,sun50i-h616-ohci",
+				     "generic-ohci";
+			reg = <0x05101400 0x100>;
+			interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI0>,
+				 <&ccu CLK_USB_OHCI0>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI0>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 0>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ehci1: usb@5200000 {
+			compatible = "allwinner,sun50i-h616-ehci",
+				     "generic-ehci";
+			reg = <0x05200000 0x100>;
+			interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI1>,
+				 <&ccu CLK_BUS_EHCI1>,
+				 <&ccu CLK_USB_OHCI1>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI1>,
+				 <&ccu RST_BUS_EHCI1>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 1>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ohci1: usb@5200400 {
+			compatible = "allwinner,sun50i-h616-ohci",
+				     "generic-ohci";
+			reg = <0x05200400 0x100>;
+			interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI1>,
+				 <&ccu CLK_USB_OHCI1>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI1>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 1>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ehci2: usb@5310000 {
+			compatible = "allwinner,sun50i-h616-ehci",
+				     "generic-ehci";
+			reg = <0x05310000 0x100>;
+			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI2>,
+				 <&ccu CLK_BUS_EHCI2>,
+				 <&ccu CLK_USB_OHCI2>;
+			resets = <&ccu RST_BUS_OHCI2>,
+				 <&ccu RST_BUS_EHCI2>;
+			phys = <&usbphy 2>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ohci2: usb@5310400 {
+			compatible = "allwinner,sun50i-h616-ohci",
+				     "generic-ohci";
+			reg = <0x05310400 0x100>;
+			interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI2>,
+				 <&ccu CLK_USB_OHCI2>;
+			resets = <&ccu RST_BUS_OHCI2>;
+			phys = <&usbphy 2>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ehci3: usb@5311000 {
+			compatible = "allwinner,sun50i-h616-ehci",
+				     "generic-ehci";
+			reg = <0x05311000 0x100>;
+			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI3>,
+				 <&ccu CLK_BUS_EHCI3>,
+				 <&ccu CLK_USB_OHCI3>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI3>,
+				 <&ccu RST_BUS_EHCI3>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 3>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ohci3: usb@5311400 {
+			compatible = "allwinner,sun50i-h616-ohci",
+				     "generic-ohci";
+			reg = <0x05311400 0x100>;
+			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI3>,
+				 <&ccu CLK_USB_OHCI3>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI3>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 3>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		rtc: rtc@7000000 {
+			compatible = "allwinner,sun50i-h616-rtc";
+			reg = <0x07000000 0x400>;
+			interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+			clock-output-names = "osc32k", "osc32k-out", "iosc";
+			#clock-cells = <1>;
+		};
+
+		r_ccu: clock@7010000 {
+			compatible = "allwinner,sun50i-h616-r-ccu";
+			reg = <0x07010000 0x210>;
+			clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
+				 <&ccu CLK_PLL_PERIPH0>;
+			clock-names = "hosc", "losc", "iosc", "pll-periph";
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+		};
+
+		r_pio: pinctrl@7022000 {
+			compatible = "allwinner,sun50i-h616-r-pinctrl";
+			reg = <0x07022000 0x400>;
+			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&r_ccu CLK_R_APB1>, <&osc24M>, <&rtc 0>;
+			clock-names = "apb", "hosc", "losc";
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+
+			r_i2c_pins: r-i2c-pins {
+				pins = "PL0", "PL1";
+				function = "s_i2c";
+			};
+
+			r_rsb_pins: r-rsb-pins {
+				pins = "PL0", "PL1";
+				function = "s_rsb";
+			};
+		};
+
+		ir: ir@7040000 {
+				compatible = "allwinner,sun50i-h616-ir",
+					     "allwinner,sun6i-a31-ir";
+				reg = <0x07040000 0x400>;
+				interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&r_ccu CLK_R_APB1_IR>,
+					 <&r_ccu CLK_IR>;
+				clock-names = "apb", "ir";
+				resets = <&r_ccu RST_R_APB1_IR>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&ir_rx_pin>;
+				status = "disabled";
+		};
+
+		r_i2c: i2c@7081400 {
+			compatible = "allwinner,sun50i-h616-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x07081400 0x400>;
+			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&r_ccu CLK_R_APB2_I2C>;
+			resets = <&r_ccu RST_R_APB2_I2C>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		r_rsb: rsb@7083000 {
+			compatible = "allwinner,sun50i-h616-rsb",
+				     "allwinner,sun8i-a23-rsb";
+			reg = <0x07083000 0x400>;
+			interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&r_ccu CLK_R_APB2_RSB>;
+			clock-frequency = <3000000>;
+			resets = <&r_ccu RST_R_APB2_RSB>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&r_rsb_pins>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+};
-- 
2.17.5

Re: [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

Hi,

On Wed, May 19, 2021 at 11:41:49AM +0100, Andre Przywara wrote:
> This (relatively) new SoC is similar to the H6, but drops the (broken)
> PCIe support and the USB 3.0 controller. It also gets the management
> controller removed, which in turn removes *some*, but not all of the
> devices formerly dedicated to the ARISC (CPUS).
> And while there is still the extra sunxi interrupt controller, the
> package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> 
> USB is a bit tricky: host controller 0, 1 and 3 depend on some help from
> controller and PHY 2, so we need to include one reset line and one
> clock gate from HCI 2 into every other HCI node, plus need some nasty
> quirk.
> 
> The reserved memory node is actually handled by Trusted Firmware now,
> but U-Boot fails to propagate this to a separately loaded DTB, so we
> keep it in here for now, until U-Boot learns to do this properly.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

As far as I can see, the IOMMU hasn't changed between the H6 and the
H616, so it would be worth enabling

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Andre Przywara]

On Mon, 24 May 2021 14:02:20 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

> Hi,
> 
> On Wed, May 19, 2021 at 11:41:49AM +0100, Andre Przywara wrote:
> > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > PCIe support and the USB 3.0 controller. It also gets the management
> > controller removed, which in turn removes *some*, but not all of the
> > devices formerly dedicated to the ARISC (CPUS).
> > And while there is still the extra sunxi interrupt controller, the
> > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> > 
> > USB is a bit tricky: host controller 0, 1 and 3 depend on some help from
> > controller and PHY 2, so we need to include one reset line and one
> > clock gate from HCI 2 into every other HCI node, plus need some nasty
> > quirk.
> > 
> > The reserved memory node is actually handled by Trusted Firmware now,
> > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > keep it in here for now, until U-Boot learns to do this properly.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>  
> 
> As far as I can see, the IOMMU hasn't changed between the H6 and the
> H616, so it would be worth enabling

I would rather not include anything that can't be tested at this point.
IIUC the IOMMU is still only for the video devices, which I omitted at
all so far - the display engine definitely needs code changes (Jernej
has something in the making).
So I'd like to wait for the IOMMU nodes till we get DE or VE support.

Cheers,
Andre

[PATCH v6 15/17] dt-bindings: arm: sunxi: Add OrangePi Zero 2 binding

[Andre Przywara]

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index ac750025a2eb..1ca550062a85 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -937,4 +937,9 @@ properties:
           - const: xunlong,orangepi-zero-plus2-h3
           - const: allwinner,sun8i-h3
 
+      - description: Xunlong OrangePi Zero 2
+        items:
+          - const: xunlong,orangepi-zero2
+          - const: allwinner,sun50i-h616
+
 additionalProperties: true
-- 
2.17.5

[PATCH v6 16/17] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support

[Andre Przywara]

The OrangePi Zero 2 is a development board with the new H616 SoC. It
comes with the following features:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 512MiB/1GiB DDR3 DRAM
  - AXP305 PMIC
  - Raspberry-Pi-1 compatible GPIO header
  - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
  - 1 USB 2.0 host port
  - 1 USB 2.0 type C port (power supply + OTG)
  - MicroSD slot
  - on-board 2MiB bootable SPI NOR flash
  - 1Gbps Ethernet port (via RTL8211F PHY)
  - micro-HDMI port
  - unsupported Allwinner WiFi/BT chip

For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 245 ++++++++++++++++++
 2 files changed, 246 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 41ce680e5f8d..9ba4b5d92657 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -36,3 +36,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
new file mode 100644
index 000000000000..a26201288872
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "OrangePi Zero2";
+	compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
+
+	aliases {
+		ethernet0 = &emac0;
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			function = LED_FUNCTION_POWER;
+			color = <LED_COLOR_ID_RED>;
+			gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+			default-state = "on";
+		};
+
+		led-1 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_GREEN>;
+			gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+		};
+	};
+
+	reg_vcc5v: vcc5v {
+		/* board wide 5V supply directly from the USB-C socket */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_usb1_vbus: usb1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb1-vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&reg_vcc5v>;
+		enable-active-high;
+		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
+		status = "okay";
+	};
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+/* USB 2 & 3 are on headers only. */
+
+&emac0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ext_rgmii_pins>;
+	phy-mode = "rgmii";
+	phy-handle = <&ext_rgmii_phy>;
+	phy-supply = <&reg_dcdce>;
+	allwinner,rx-delay-ps = <3100>;
+	allwinner,tx-delay-ps = <700>;
+	status = "okay";
+};
+
+&mdio0 {
+	ext_rgmii_phy: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
+&mmc0 {
+	vmmc-supply = <&reg_dcdce>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
+	bus-width = <4>;
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&r_rsb {
+	status = "okay";
+
+	axp305: pmic@745 {
+		compatible = "x-powers,axp305", "x-powers,axp805",
+			     "x-powers,axp806";
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		reg = <0x745>;
+
+		x-powers,self-working-mode;
+		vina-supply = <&reg_vcc5v>;
+		vinb-supply = <&reg_vcc5v>;
+		vinc-supply = <&reg_vcc5v>;
+		vind-supply = <&reg_vcc5v>;
+		vine-supply = <&reg_vcc5v>;
+		aldoin-supply = <&reg_vcc5v>;
+		bldoin-supply = <&reg_vcc5v>;
+		cldoin-supply = <&reg_vcc5v>;
+
+		regulators {
+			reg_aldo1: aldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-sys";
+			};
+
+			reg_aldo2: aldo2 {	/* 3.3V on headers */
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc3v3-ext";
+			};
+
+			reg_aldo3: aldo3 {	/* 3.3V on headers */
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc3v3-ext2";
+			};
+
+			reg_bldo1: bldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8";
+			};
+
+			bldo2 {
+				/* unused */
+			};
+
+			bldo3 {
+				/* unused */
+			};
+
+			bldo4 {
+				/* unused */
+			};
+
+			cldo1 {
+				/* reserved */
+			};
+
+			cldo2 {
+				/* unused */
+			};
+
+			cldo3 {
+				/* unused */
+			};
+
+			reg_dcdca: dcdca {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1080000>;
+				regulator-name = "vdd-cpu";
+			};
+
+			reg_dcdcc: dcdcc {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1080000>;
+				regulator-name = "vdd-gpu-sys";
+			};
+
+			reg_dcdcd: dcdcd {
+				regulator-always-on;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-name = "vdd-dram";
+			};
+
+			reg_dcdce: dcdce {
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-eth-mmc";
+			};
+
+			sw {
+				/* unused */
+			};
+		};
+	};
+};
+
+&spi0  {
+	status = "okay";
+
+	flash@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_ph_pins>;
+	status = "okay";
+};
+
+&usbotg {
+	/*
+	 * PHY0 pins are connected to a USB-C socket, but a role switch
+	 * is not implemented: both CC pins are pulled to GND.
+	 * The VBUS pins power the device, so a fixed peripheral mode
+	 * is the best choice.
+	 * The board can be powered via GPIOs, in this case port0 *can*
+	 * act as a host (with a cable/adapter ignoring CC), as VBUS is
+	 * then provided by the GPIOs. Any user of this setup would
+	 * need to adjust the DT accordingly: dr_mode set to "host",
+	 * enabling OHCI0 and EHCI0.
+	 */
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usbphy {
+	usb1_vbus-supply = <&reg_usb1_vbus>;
+	status = "okay";
+};
-- 
2.17.5

[PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support

[Andre Przywara]

The X96 Mate is an Allwinner H616 based TV box, featuring:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 2GiB/4GiB RAM (fully usable!)
  - 16/32/64GiB eMMC
  - 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
  - Unsupported Allwinner WiFi chip
  - 2 x USB 2.0 host ports
  - HDMI port
  - IR receiver
  - 5V/2A DC power supply via barrel plug

For more information see: https://linux-sunxi.org/X96_Mate

Add a basic devicetree for it, with SD card, eMMC and USB working, as
well as serial and the essential peripherals, like the AXP PMIC.

This DT is somewhat minimal, and should work on many other similar TV
boxes with the Allwinner H616 chip.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../dts/allwinner/sun50i-h616-x96-mate.dts    | 201 ++++++++++++++++++
 2 files changed, 202 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 9ba4b5d92657..370d24ebaacf 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -37,3 +37,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
new file mode 100644
index 000000000000..b960bb310289
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2021 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "X96 Mate";
+	compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	reg_vcc5v: vcc5v {
+		/* board wide 5V supply directly from the DC input */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci2 {
+	status = "okay";
+};
+
+&ir {
+	status = "okay";
+};
+
+&mmc0 {
+	vmmc-supply = <&reg_dcdce>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dcdce>;
+	vqmmc-supply = <&reg_bldo1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci2 {
+	status = "okay";
+};
+
+&r_rsb {
+	status = "okay";
+
+	axp305: pmic@745 {
+		compatible = "x-powers,axp305", "x-powers,axp805",
+			     "x-powers,axp806";
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		reg = <0x745>;
+
+		x-powers,self-working-mode;
+		vina-supply = <&reg_vcc5v>;
+		vinb-supply = <&reg_vcc5v>;
+		vinc-supply = <&reg_vcc5v>;
+		vind-supply = <&reg_vcc5v>;
+		vine-supply = <&reg_vcc5v>;
+		aldoin-supply = <&reg_vcc5v>;
+		bldoin-supply = <&reg_vcc5v>;
+		cldoin-supply = <&reg_vcc5v>;
+
+		regulators {
+			reg_aldo1: aldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-sys";
+			};
+
+			/* Enabled by the Android BSP */
+			reg_aldo2: aldo2 {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc3v3-ext";
+				status = "disabled";
+			};
+
+			/* Enabled by the Android BSP */
+			reg_aldo3: aldo3 {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc3v3-ext2";
+				status = "disabled";
+			};
+
+			reg_bldo1: bldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8";
+			};
+
+			/* Enabled by the Android BSP */
+			reg_bldo2: bldo2 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8-2";
+				status = "disabled";
+			};
+
+			bldo3 {
+				/* unused */
+			};
+
+			bldo4 {
+				/* unused */
+			};
+
+			cldo1 {
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-name = "vcc2v5";
+			};
+
+			cldo2 {
+				/* unused */
+			};
+
+			cldo3 {
+				/* unused */
+			};
+
+			reg_dcdca: dcdca {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1080000>;
+				regulator-name = "vdd-cpu";
+			};
+
+			reg_dcdcc: dcdcc {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1080000>;
+				regulator-name = "vdd-gpu-sys";
+			};
+
+			reg_dcdcd: dcdcd {
+				regulator-always-on;
+				regulator-min-microvolt = <1360000>;
+				regulator-max-microvolt = <1360000>;
+				regulator-name = "vdd-dram";
+			};
+
+			reg_dcdce: dcdce {
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-eth-mmc";
+			};
+
+			sw {
+				/* unused */
+			};
+		};
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_ph_pins>;
+	status = "okay";
+};
+
+&usbotg {
+	dr_mode = "host";	/* USB A type receptable */
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
-- 
2.17.5

Re: [PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support

[Jernej Škrabec]

Hi Andre!

Dne sreda, 19. maj 2021 ob 12:41:52 CEST je Andre Przywara napisal(a):
> The X96 Mate is an Allwinner H616 based TV box, featuring:
>   - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
>   - 2GiB/4GiB RAM (fully usable!)
>   - 16/32/64GiB eMMC
>   - 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
>   - Unsupported Allwinner WiFi chip
>   - 2 x USB 2.0 host ports
>   - HDMI port
>   - IR receiver
>   - 5V/2A DC power supply via barrel plug
> 
> For more information see: https://linux-sunxi.org/X96_Mate
> 
> Add a basic devicetree for it, with SD card, eMMC and USB working, as
> well as serial and the essential peripherals, like the AXP PMIC.
> 
> This DT is somewhat minimal, and should work on many other similar TV
> boxes with the Allwinner H616 chip.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>  .../dts/allwinner/sun50i-h616-x96-mate.dts    | 201 ++++++++++++++++++
>  2 files changed, 202 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
allwinner/Makefile
> index 9ba4b5d92657..370d24ebaacf 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -37,3 +37,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts b/arch/
arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
> new file mode 100644
> index 000000000000..b960bb310289
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
> @@ -0,0 +1,201 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2021 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	model = "X96 Mate";
> +	compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";

Please document compatible.

Best regards,
Jernej

> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	reg_vcc5v: vcc5v {
> +		/* board wide 5V supply directly from the DC input */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-5v";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-always-on;
> +	};
> +};
> +
> +&ehci0 {
> +	status = "okay";
> +};
> +
> +&ehci2 {
> +	status = "okay";
> +};
> +
> +&ir {
> +	status = "okay";
> +};
> +
> +&mmc0 {
> +	vmmc-supply = <&reg_dcdce>;
> +	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
> +	bus-width = <4>;
> +	status = "okay";
> +};
> +
> +&mmc2 {
> +	vmmc-supply = <&reg_dcdce>;
> +	vqmmc-supply = <&reg_bldo1>;
> +	bus-width = <8>;
> +	non-removable;
> +	cap-mmc-hw-reset;
> +	mmc-hs200-1_8v;
> +	status = "okay";
> +};
> +
> +&ohci0 {
> +	status = "okay";
> +};
> +
> +&ohci2 {
> +	status = "okay";
> +};
> +
> +&r_rsb {
> +	status = "okay";
> +
> +	axp305: pmic@745 {
> +		compatible = "x-powers,axp305", "x-powers,axp805",
> +			     "x-powers,axp806";
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +		reg = <0x745>;
> +
> +		x-powers,self-working-mode;
> +		vina-supply = <&reg_vcc5v>;
> +		vinb-supply = <&reg_vcc5v>;
> +		vinc-supply = <&reg_vcc5v>;
> +		vind-supply = <&reg_vcc5v>;
> +		vine-supply = <&reg_vcc5v>;
> +		aldoin-supply = <&reg_vcc5v>;
> +		bldoin-supply = <&reg_vcc5v>;
> +		cldoin-supply = <&reg_vcc5v>;
> +
> +		regulators {
> +			reg_aldo1: aldo1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<3300000>;
> +				regulator-max-microvolt = 
<3300000>;
> +				regulator-name = "vcc-sys";
> +			};
> +
> +			/* Enabled by the Android BSP */
> +			reg_aldo2: aldo2 {
> +				regulator-min-microvolt = 
<3300000>;
> +				regulator-max-microvolt = 
<3300000>;
> +				regulator-name = "vcc3v3-ext";
> +				status = "disabled";
> +			};
> +
> +			/* Enabled by the Android BSP */
> +			reg_aldo3: aldo3 {
> +				regulator-min-microvolt = 
<3300000>;
> +				regulator-max-microvolt = 
<3300000>;
> +				regulator-name = "vcc3v3-ext2";
> +				status = "disabled";
> +			};
> +
> +			reg_bldo1: bldo1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<1800000>;
> +				regulator-max-microvolt = 
<1800000>;
> +				regulator-name = "vcc1v8";
> +			};
> +
> +			/* Enabled by the Android BSP */
> +			reg_bldo2: bldo2 {
> +				regulator-min-microvolt = 
<1800000>;
> +				regulator-max-microvolt = 
<1800000>;
> +				regulator-name = "vcc1v8-2";
> +				status = "disabled";
> +			};
> +
> +			bldo3 {
> +				/* unused */
> +			};
> +
> +			bldo4 {
> +				/* unused */
> +			};
> +
> +			cldo1 {
> +				regulator-min-microvolt = 
<2500000>;
> +				regulator-max-microvolt = 
<2500000>;
> +				regulator-name = "vcc2v5";
> +			};
> +
> +			cldo2 {
> +				/* unused */
> +			};
> +
> +			cldo3 {
> +				/* unused */
> +			};
> +
> +			reg_dcdca: dcdca {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<810000>;
> +				regulator-max-microvolt = 
<1080000>;
> +				regulator-name = "vdd-cpu";
> +			};
> +
> +			reg_dcdcc: dcdcc {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<810000>;
> +				regulator-max-microvolt = 
<1080000>;
> +				regulator-name = "vdd-gpu-sys";
> +			};
> +
> +			reg_dcdcd: dcdcd {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<1360000>;
> +				regulator-max-microvolt = 
<1360000>;
> +				regulator-name = "vdd-dram";
> +			};
> +
> +			reg_dcdce: dcdce {
> +				regulator-boot-on;
> +				regulator-min-microvolt = 
<3300000>;
> +				regulator-max-microvolt = 
<3300000>;
> +				regulator-name = "vcc-eth-mmc";
> +			};
> +
> +			sw {
> +				/* unused */
> +			};
> +		};
> +	};
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_ph_pins>;
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	dr_mode = "host";	/* USB A type receptable */
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	status = "okay";
> +};
> -- 
> 2.17.5
> 
>