arm64: allwinner: Add support for TERES I laptop

arm64: allwinner: Add support for TERES I laptop

[Harald Geyer]

This series adds support for the TERES I open hardware laptop produced
by olimex. With these patches and a bootloader capable of setting up
simple framebuffer the laptop is quite useable.

Patches 1-4 add some pin descriptions and devices in the A64 dtsi, which
are useful to have on the teres.
Patch 5 finally adds the board dts itself.

best regards,
Harald

Harald Geyer (5):
  arm64: dts: allwinner: a64: Add i2c0 pins
  arm64: dts: allwinner: a64: Add watchdog
  arm64: dts: allwinner: a64: add simplefb for A64 SoC
  arm64: dts: allwinner: a64: Add pwm device
  arm64: allwinner: a64: Add support for TERES I laptop

 arch/arm64/boot/dts/allwinner/Makefile             |   1 +
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts      | 308 +++++++++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      |  44 +++
 3 files changed, 353 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts

-- 
2.11.0

[PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

[Harald Geyer]

Add the proper pin group node to reference in board files.

Signed-off-by: Harald Geyer <harald@ccbib.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b6dc31e7d91..64e452a758fa 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -309,6 +309,11 @@
 			interrupt-controller;
 			#interrupt-cells = <3>;
 
+			i2c0_pins: i2c0_pins {
+				pins = "PH0", "PH1";
+				function = "i2c0";
+			};
+
 			i2c1_pins: i2c1_pins {
 				pins = "PH2", "PH3";
 				function = "i2c1";
-- 
2.11.0

Re: [PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

[André Przywara]

On 12/03/18 16:10, Harald Geyer wrote:
> Add the proper pin group node to reference in board files.
> 
> Signed-off-by: Harald Geyer <harald@ccbib.org>

That looks correct to me, so:

Reviewed-by: Andre Przywara <andre.przywara@arm.com>

But out of curiosity, what is this used for? In patch 5/5 I see it being
used, but without a clue for what? Shouldn't enabling an I2C node be
accompanied by some child node, presenting the device on the bus?
I guess this I2C is not on some kind of "header" on that laptop?

Cheers,
Andre.

> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1b6dc31e7d91..64e452a758fa 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -309,6 +309,11 @@
>  			interrupt-controller;
>  			#interrupt-cells = <3>;
>  
> +			i2c0_pins: i2c0_pins {
> +				pins = "PH0", "PH1";
> +				function = "i2c0";
> +			};
> +
>  			i2c1_pins: i2c1_pins {
>  				pins = "PH2", "PH3";
>  				function = "i2c1";
> 

Re: [PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

[Harald Geyer]

André Przywara writes:
> On 12/03/18 16:10, Harald Geyer wrote:
> > Add the proper pin group node to reference in board files.
> > 
> > Signed-off-by: Harald Geyer <harald@ccbib.org>
> 
> That looks correct to me, so:
> 
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> 
> But out of curiosity, what is this used for? In patch 5/5 I see it being
> used, but without a clue for what? Shouldn't enabling an I2C node be
> accompanied by some child node, presenting the device on the bus?
> I guess this I2C is not on some kind of "header" on that laptop?

I enabled it because the ANX6345 eDP-bridge is on that bus. There is
no linux (mainline) driver for this chip at the moment, the bootloader
initializes it. However I'm using the i2c-dev driver to read (and maybe)
change some register values from user space.

i2cdetect sees devices at 0x38, 0x39 and 0x3d - all of which might
be the ANX6345. I haven't looked into this in detail.

Since you are asking: Actually the teres has a "header" with usb-otg,
spi, i2c1 and some gpios, but it isn't exposed on the exterior of the
case and nothing is connected to it. So I didn't bother with adding
nodes for this in DT. Curious what olimex are planning to do with that.

Thanks for your review,
Harald

> Cheers,
> Andre.
> 
> > ---
> >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 1b6dc31e7d91..64e452a758fa 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -309,6 +309,11 @@
> >  			interrupt-controller;
> >  			#interrupt-cells = <3>;
> >  
> > +			i2c0_pins: i2c0_pins {
> > +				pins = "PH0", "PH1";
> > +				function = "i2c0";
> > +			};
> > +
> >  			i2c1_pins: i2c1_pins {
> >  				pins = "PH2", "PH3";
> >  				function = "i2c1";
> > 
> 

-- 
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

Re: [PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

[Maxime Ripard]

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

On Tue, Mar 13, 2018 at 09:46:51AM +0100, Harald Geyer wrote:
> André Przywara writes:
> > On 12/03/18 16:10, Harald Geyer wrote:
> > > Add the proper pin group node to reference in board files.
> > > 
> > > Signed-off-by: Harald Geyer <harald@ccbib.org>
> > 
> > That looks correct to me, so:
> > 
> > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > 
> > But out of curiosity, what is this used for? In patch 5/5 I see it being
> > used, but without a clue for what? Shouldn't enabling an I2C node be
> > accompanied by some child node, presenting the device on the bus?
> > I guess this I2C is not on some kind of "header" on that laptop?
> 
> I enabled it because the ANX6345 eDP-bridge is on that bus. There is
> no linux (mainline) driver for this chip at the moment, the bootloader
> initializes it. However I'm using the i2c-dev driver to read (and maybe)
> change some register values from user space.
> 
> i2cdetect sees devices at 0x38, 0x39 and 0x3d - all of which might
> be the ANX6345. I haven't looked into this in detail.

That's alright then, just put a comment in the DT on what this bus is
used for.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

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

[PATCH 2/5] arm64: dts: allwinner: a64: Add watchdog

[Harald Geyer]

Add a watchdog node for the A64, automatically enabled on all boards.
Tested on Olimex Teres I.

Signed-off-by: Harald Geyer <harald@ccbib.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 64e452a758fa..ca1b365bc722 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -665,5 +665,11 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
+
+		wdt0: watchdog@1c20ca0 {
+			compatible = "allwinner,sun6i-a31-wdt";
+			reg = <0x01c20ca0 0x20>;
+			interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+		};
 	};
 };
-- 
2.11.0

Re: [PATCH 2/5] arm64: dts: allwinner: a64: Add watchdog

[André Przywara]

On 12/03/18 16:10, Harald Geyer wrote:

Hi,

> Add a watchdog node for the A64, automatically enabled on all boards.
> Tested on Olimex Teres I.
> 
> Signed-off-by: Harald Geyer <harald@ccbib.org>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 64e452a758fa..ca1b365bc722 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -665,5 +665,11 @@
>  			#address-cells = <1>;
>  			#size-cells = <0>;
>  		};
> +
> +		wdt0: watchdog@1c20ca0 {
> +			compatible = "allwinner,sun6i-a31-wdt";

Please use the recommended way, adding a specific compatible first:

			compatible = "allwinner,sun50i-a64-wdt",
				     "allwinner,sun6i-a31-wdt";

The rest looks correct.

I am just a bit puzzled what's the use of a watchdog on a laptop? I
would expect it being more used in embedded systems? Or is that patch
here actually independent from the Teres I?

Cheers,
Andre.

> +			reg = <0x01c20ca0 0x20>;
> +			interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> +		};
>  	};
>  };
> 

Re: [PATCH 2/5] arm64: dts: allwinner: a64: Add watchdog

[Harald Geyer]

Hi,

André Przywara writes:
> On 12/03/18 16:10, Harald Geyer wrote:
> > Add a watchdog node for the A64, automatically enabled on all boards.
> > Tested on Olimex Teres I.
> > 
> > Signed-off-by: Harald Geyer <harald@ccbib.org>
> > ---
> >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 64e452a758fa..ca1b365bc722 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -665,5 +665,11 @@
> >  			#address-cells = <1>;
> >  			#size-cells = <0>;
> >  		};
> > +
> > +		wdt0: watchdog@1c20ca0 {
> > +			compatible = "allwinner,sun6i-a31-wdt";
> 
> Please use the recommended way, adding a specific compatible first:
> 
> 			compatible = "allwinner,sun50i-a64-wdt",
> 				     "allwinner,sun6i-a31-wdt";

I tried to follow the style most commonly used in the rest of the file,
but I can add the new string to the binding documentation and use it here.

> The rest looks correct.
> 
> I am just a bit puzzled what's the use of a watchdog on a laptop?

I guess the same as the watchdog on my x86 PC - debugging/testing software
using watchdogs. ;)

> I
> would expect it being more used in embedded systems? Or is that patch
> here actually independent from the Teres I?

Yes, I could have sent it as independent patch, but I figured merging
is easier if there aren't independent patches touching the same file at
the same time.

I mostly added support for the watchdog because it was listed in the
wiki as untested and it cost me virtually no time to run a few tests while
working on the teres.

Thanks,
Harald

> Cheers,
> Andre.
> 
> > +			reg = <0x01c20ca0 0x20>;
> > +			interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> > +		};
> >  	};
> >  };
> > 
> 

-- 
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

[PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

[Harald Geyer]

The A64 SoC features two display pipelines, one has a LCD output, the
other has a HDMI output.

Add support for simplefb for the LCD output. Tested on Teres I.

This patch was inspired by work of Icenowy Zheng.

Signed-off-by: Harald Geyer <harald@ccbib.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index ca1b365bc722..05d5e8def68a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -52,6 +52,26 @@
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	chosen {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+/*
+ * The pipeline mixer0-lcd0 depends on clock CLK_MIXER0 from DE2 CCU.
+ * However there is no support for this clock on A64 yet, so we depend
+ * on the upstream clocks here to keep them (and thus CLK_MIXER0) up.
+ */
+		simplefb_lcd: framebuffer-lcd {
+			compatible = "allwinner,simple-framebuffer",
+				     "simple-framebuffer";
+			allwinner,pipeline = "mixer0-lcd0";
+			clocks = <&ccu CLK_TCON0>,
+				 <&ccu CLK_DE>, <&ccu CLK_BUS_DE>;
+			status = "disabled";
+		};
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.11.0

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

[Maxime Ripard]

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

On Mon, Mar 12, 2018 at 04:10:48PM +0000, Harald Geyer wrote:
> The A64 SoC features two display pipelines, one has a LCD output, the
> other has a HDMI output.
> 
> Add support for simplefb for the LCD output. Tested on Teres I.
> 
> This patch was inspired by work of Icenowy Zheng.
> 
> Signed-off-by: Harald Geyer <harald@ccbib.org>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index ca1b365bc722..05d5e8def68a 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -52,6 +52,26 @@
>  	#address-cells = <1>;
>  	#size-cells = <1>;
>  
> +	chosen {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +/*
> + * The pipeline mixer0-lcd0 depends on clock CLK_MIXER0 from DE2 CCU.
> + * However there is no support for this clock on A64 yet, so we depend
> + * on the upstream clocks here to keep them (and thus CLK_MIXER0) up.
> + */

There's definitely support for the CLK_MIXER0 clock in the DE2 CCU
driver, so I guess this would need to be amended / fixed

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

[Harald Geyer]

Maxime Ripard writes:
> On Mon, Mar 12, 2018 at 04:10:48PM +0000, Harald Geyer wrote:
>> The A64 SoC features two display pipelines, one has a LCD output, the
>> other has a HDMI output.
>>
>> Add support for simplefb for the LCD output. Tested on Teres I.
>>
>> This patch was inspired by work of Icenowy Zheng.
>>
>> Signed-off-by: Harald Geyer <harald@ccbib.org>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index ca1b365bc722..05d5e8def68a 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -52,6 +52,26 @@
>> 	#address-cells = <1>;
>> 	#size-cells = <1>;
>>
>> +	chosen {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +/*
>> + * The pipeline mixer0-lcd0 depends on clock CLK_MIXER0 from DE2 CCU.
>> + * However there is no support for this clock on A64 yet, so we depend
>> + * on the upstream clocks here to keep them (and thus CLK_MIXER0) up.
>> + */
> 
> There's definitely support for the CLK_MIXER0 clock in the DE2 CCU
> driver, so I guess this would need to be amended / fixed

AFAIK on the A64 a special sram quirk is necessary, that never got merged:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574303.html

I asked Icenowy if I should resubmit her patch as part of this series,
but was told further discussion is necessary. I'm sure she can better
explain the details than me.

Actually if it wasn't for the sram quirk, there is a simplefb patch by
her, that could have been merged long ago:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574304.html

Hope that explains,
Harald

> -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and
> Kernel engineering https://bootlin.com
> 
>>> application/pgp-signature attachment

-- 
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

[Maxime Ripard]

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

Hi,

On Tue, Mar 13, 2018 at 10:18:22AM +0100, Harald Geyer wrote:
> Maxime Ripard writes:
> > On Mon, Mar 12, 2018 at 04:10:48PM +0000, Harald Geyer wrote:
> >> The A64 SoC features two display pipelines, one has a LCD output, the
> >> other has a HDMI output.
> >>
> >> Add support for simplefb for the LCD output. Tested on Teres I.
> >>
> >> This patch was inspired by work of Icenowy Zheng.
> >>
> >> Signed-off-by: Harald Geyer <harald@ccbib.org>
> >> ---
> >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 ++++++++++++++++++++
> >> 1 file changed, 20 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> index ca1b365bc722..05d5e8def68a 100644
> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> @@ -52,6 +52,26 @@
> >> 	#address-cells = <1>;
> >> 	#size-cells = <1>;
> >>
> >> +	chosen {
> >> +		#address-cells = <1>;
> >> +		#size-cells = <1>;
> >> +		ranges;
> >> +
> >> +/*
> >> + * The pipeline mixer0-lcd0 depends on clock CLK_MIXER0 from DE2 CCU.
> >> + * However there is no support for this clock on A64 yet, so we depend
> >> + * on the upstream clocks here to keep them (and thus CLK_MIXER0) up.
> >> + */
> > 
> > There's definitely support for the CLK_MIXER0 clock in the DE2 CCU
> > driver, so I guess this would need to be amended / fixed
> 
> AFAIK on the A64 a special sram quirk is necessary, that never got merged:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574303.html
> 
> I asked Icenowy if I should resubmit her patch as part of this series,
> but was told further discussion is necessary. I'm sure she can better
> explain the details than me.
> 
> Actually if it wasn't for the sram quirk, there is a simplefb patch by
> her, that could have been merged long ago:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574304.html

The issue with your patch is that, as soon as that clock is
functional, the DT with the node you were introducing here will no
longer be.

And since people use their firmware DT or put them in NOR these days,
you can't really expect them to update them every release either.

I guess a proper solution would be to respin that patch.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

[Harald Geyer]

Maxime Ripard writes:
> Hi,
> 
> On Tue, Mar 13, 2018 at 10:18:22AM +0100, Harald Geyer wrote:
>> Maxime Ripard writes:
>>> On Mon, Mar 12, 2018 at 04:10:48PM +0000, Harald Geyer wrote:
>>>> The A64 SoC features two display pipelines, one has a LCD output, the
>>>> other has a HDMI output.
>>>>
>>>> Add support for simplefb for the LCD output. Tested on Teres I.
>>>>
>>>> This patch was inspired by work of Icenowy Zheng.
>>>>
>>>> Signed-off-by: Harald Geyer <harald@ccbib.org>
>>>> ---
>>>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 ++++++++++++++++++++
>>>> 1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> index ca1b365bc722..05d5e8def68a 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> @@ -52,6 +52,26 @@
>>>> 	#address-cells = <1>;
>>>> 	#size-cells = <1>;
>>>>
>>>> +	chosen {
>>>> +		#address-cells = <1>;
>>>> +		#size-cells = <1>;
>>>> +		ranges;
>>>> +
>>>> +/*
>>>> + * The pipeline mixer0-lcd0 depends on clock CLK_MIXER0 from DE2 CCU.
>>>> + * However there is no support for this clock on A64 yet, so we depend
>>>> + * on the upstream clocks here to keep them (and thus CLK_MIXER0) up.
>>>> + */
>>> 
>>> There's definitely support for the CLK_MIXER0 clock in the DE2 CCU
>>> driver, so I guess this would need to be amended / fixed
>> 
>> AFAIK on the A64 a special sram quirk is necessary, that never got merged:
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574303.html
>> 
>> I asked Icenowy if I should resubmit her patch as part of this series,
>> but was told further discussion is necessary. I'm sure she can better
>> explain the details than me.
>> 
>> Actually if it wasn't for the sram quirk, there is a simplefb patch by
>> her, that could have been merged long ago:
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574304.html
> 
> The issue with your patch is that, as soon as that clock is
> functional, the DT with the node you were introducing here will no
> longer be.
> 
> And since people use their firmware DT or put them in NOR these days,
> you can't really expect them to update them every release either.

How is this a problem? - The clock can't be functional without adding
a DT node for it's driver. So the breakage can only happen on DT update,
which means we can avoid it, by moving the clocks to the proper places
when we add the node actually using them for real.

> I guess a proper solution would be to respin that patch.

Sure, but as mentioned above I offered to do that and was told not to.

As a compromise I could also move the simple framebuffer node from the
A64 dtsi to the teres-i dts, where we know that the DT can be updated
easily?

Thanks for your consideration,
Harald

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

[Maxime Ripard]

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

On Tue, Mar 13, 2018 at 05:51:29PM +0100, Harald Geyer wrote:
> Maxime Ripard writes:
> > Hi,
> > 
> > On Tue, Mar 13, 2018 at 10:18:22AM +0100, Harald Geyer wrote:
> >> Maxime Ripard writes:
> >>> On Mon, Mar 12, 2018 at 04:10:48PM +0000, Harald Geyer wrote:
> >>>> The A64 SoC features two display pipelines, one has a LCD output, the
> >>>> other has a HDMI output.
> >>>>
> >>>> Add support for simplefb for the LCD output. Tested on Teres I.
> >>>>
> >>>> This patch was inspired by work of Icenowy Zheng.
> >>>>
> >>>> Signed-off-by: Harald Geyer <harald@ccbib.org>
> >>>> ---
> >>>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 ++++++++++++++++++++
> >>>> 1 file changed, 20 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>>> index ca1b365bc722..05d5e8def68a 100644
> >>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>>> @@ -52,6 +52,26 @@
> >>>> 	#address-cells = <1>;
> >>>> 	#size-cells = <1>;
> >>>>
> >>>> +	chosen {
> >>>> +		#address-cells = <1>;
> >>>> +		#size-cells = <1>;
> >>>> +		ranges;
> >>>> +
> >>>> +/*
> >>>> + * The pipeline mixer0-lcd0 depends on clock CLK_MIXER0 from DE2 CCU.
> >>>> + * However there is no support for this clock on A64 yet, so we depend
> >>>> + * on the upstream clocks here to keep them (and thus CLK_MIXER0) up.
> >>>> + */
> >>> 
> >>> There's definitely support for the CLK_MIXER0 clock in the DE2 CCU
> >>> driver, so I guess this would need to be amended / fixed
> >> 
> >> AFAIK on the A64 a special sram quirk is necessary, that never got merged:
> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574303.html
> >> 
> >> I asked Icenowy if I should resubmit her patch as part of this series,
> >> but was told further discussion is necessary. I'm sure she can better
> >> explain the details than me.
> >> 
> >> Actually if it wasn't for the sram quirk, there is a simplefb patch by
> >> her, that could have been merged long ago:
> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1574304.html
> > 
> > The issue with your patch is that, as soon as that clock is
> > functional, the DT with the node you were introducing here will no
> > longer be.
> > 
> > And since people use their firmware DT or put them in NOR these days,
> > you can't really expect them to update them every release either.
> 
> How is this a problem? - The clock can't be functional without adding
> a DT node for it's driver. So the breakage can only happen on DT update,
> which means we can avoid it, by moving the clocks to the proper places
> when we add the node actually using them for real.

Ah, sorry I missed it. Yeah, that would work.

> > I guess a proper solution would be to respin that patch.
> 
> Sure, but as mentioned above I offered to do that and was told not to.
> 
> As a compromise I could also move the simple framebuffer node from the
> A64 dtsi to the teres-i dts, where we know that the DT can be updated
> easily?

That's a matter of usecase, not only hardware, so this wouldn't work.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

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

[PATCH 4/5] arm64: dts: allwinner: a64: Add pwm device

[Harald Geyer]

This device is compatible with A13, so no new driver is needed.

Signed-off-by: Harald Geyer <harald@ccbib.org>
---
I saw that Andre Przywara has been working on A64 pwm too and has
submitted some patches a few days ago. I think his patches are functionally
equivalent to this one here, but clean up things a bit and thus are
preferable. See:

https://groups.google.com/forum/#!topic/linux-sunxi/hQFeteP591k

I'm including my patch here mostly to have a consistent series for others
to test. OTOH you might merge the device tree changes here and pick up
the cleanup patches from him. Either way should work fine.

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 05d5e8def68a..95d52f6aa07f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -364,6 +364,11 @@
 				bias-pull-up;
 			};
 
+			pwm_pin: pwm_pin {
+				pins = "PD22";
+				function = "pwm";
+			};
+
 			rmii_pins: rmii_pins {
 				pins = "PD10", "PD11", "PD13", "PD14", "PD17",
 				       "PD18", "PD19", "PD20", "PD22", "PD23";
@@ -629,6 +634,14 @@
 			#interrupt-cells = <3>;
 		};
 
+		pwm: pwm@1c21400 {
+			compatible = "allwinner,sun5i-a13-pwm";
+			reg = <0x01c21400 0x8>;
+			clocks = <&osc24M>;
+			#pwm-cells = <3>;
+			status = "disabled";
+		};
+
 		rtc: rtc@1f00000 {
 			compatible = "allwinner,sun6i-a31-rtc";
 			reg = <0x01f00000 0x54>;
-- 
2.11.0

Re: [PATCH 4/5] arm64: dts: allwinner: a64: Add pwm device

[Maxime Ripard]

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

On Mon, Mar 12, 2018 at 04:10:49PM +0000, Harald Geyer wrote:
> This device is compatible with A13, so no new driver is needed.
> 
> Signed-off-by: Harald Geyer <harald@ccbib.org>
> ---
> I saw that Andre Przywara has been working on A64 pwm too and has
> submitted some patches a few days ago. I think his patches are functionally
> equivalent to this one here, but clean up things a bit and thus are
> preferable. See:
> 
> https://groups.google.com/forum/#!topic/linux-sunxi/hQFeteP591k
> 
> I'm including my patch here mostly to have a consistent series for others
> to test. OTOH you might merge the device tree changes here and pick up
> the cleanup patches from him. Either way should work fine.
> 
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 05d5e8def68a..95d52f6aa07f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -364,6 +364,11 @@
>  				bias-pull-up;
>  			};
>  
> +			pwm_pin: pwm_pin {
> +				pins = "PD22";
> +				function = "pwm";
> +			};
> +
>  			rmii_pins: rmii_pins {
>  				pins = "PD10", "PD11", "PD13", "PD14", "PD17",
>  				       "PD18", "PD19", "PD20", "PD22", "PD23";
> @@ -629,6 +634,14 @@
>  			#interrupt-cells = <3>;
>  		};
>  
> +		pwm: pwm@1c21400 {
> +			compatible = "allwinner,sun5i-a13-pwm";

Just like for the watchdog, you should have an A64 compatible there.

> +			reg = <0x01c21400 0x8>;

And you should use the full memory range here.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

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

[PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop

[Harald Geyer]

The TERES I is an open hardware laptop built by Olimex using the
Allwinner A64 SoC.

Add the board specific .dts file, which includes the A64 .dtsi and
enables the peripherals that we support so far.

Signed-off-by: Harald Geyer <harald@ccbib.org>
---
 arch/arm64/boot/dts/allwinner/Makefile             |   1 +
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts      | 308 +++++++++++++++++++++
 2 files changed, 309 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index f505227b0250..5f073f7423b7 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
new file mode 100644
index 000000000000..0d42b5111f0f
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -0,0 +1,308 @@
+/*
+ * Copyright (C) Harald Geyer <harald@ccbib.org>
+ * based on sun50i-a64-olinuxino.dts by Jagan Teki <jteki@openedev.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+	model = "Olimex Teres I A64";
+	compatible = "olimex,a64-teres-i", "allwinner,sun50i-a64";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm 0 50000 0>;
+		brightness-levels = <0 10 20 30 40 50 60 70 100>;
+		default-brightness-level = <3>;
+		enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+
+		framebuffer-lcd {
+			eDP25-supply = <&reg_dldo2>;
+			eDP12-supply = <&reg_dldo3>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		lid-switch {
+			label = "Lid Switch";
+			gpios = <&r_pio 0 8 GPIO_ACTIVE_LOW>; /* PL8 */
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_LID>;
+		};
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+
+		led_capslock: capslock {
+			gpios = <&pio 2 7 GPIO_ACTIVE_HIGH>; /* PC7 */
+		};
+
+		led_numlock: numlock {
+			gpios = <&pio 2 4 GPIO_ACTIVE_HIGH>; /* PC4 */
+		};
+	};
+
+	reg_usb1_vbus: usb1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb1-vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
+		status = "okay";
+	};
+
+	wifi_pwrseq: wifi_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+	};
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	vmmc-supply = <&reg_aldo2>;
+	vqmmc-supply = <&reg_dldo4>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+
+	rtl8723bs: wifi@1 {
+		reg = <1>;
+		interrupt-parent = <&r_pio>;
+		interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
+		interrupt-names = "host-wake";
+	};
+};
+
+&mmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dcdc1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	status = "okay";
+};
+
+&pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm_pin>;
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&r_rsb {
+	status = "okay";
+
+	axp803: pmic@3a3 {
+		compatible = "x-powers,axp803";
+		reg = <0x3a3>;
+		interrupt-parent = <&r_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+		wakeup-source;
+	};
+};
+
+#include "axp803.dtsi"
+
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <2800000>;
+	regulator-max-microvolt = <2800000>;
+	regulator-name = "vcc-pe";
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pl";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1040000>;
+	regulator-max-microvolt = <1300000>;
+	regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1500000>;
+	regulator-max-microvolt = <1500000>;
+	regulator-name = "vcc-ddr3";
+};
+
+&reg_dcdc6 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dldo1 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-hdmi";
+};
+
+&reg_dldo2 {
+	regulator-min-microvolt = <2500000>;
+	regulator-max-microvolt = <2500000>;
+	regulator-name = "vcc-pd";
+};
+
+&reg_dldo3 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "eDP12";
+};
+
+&reg_dldo4 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi-io";
+};
+
+&reg_eldo1 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "cpvdd";
+};
+
+&reg_eldo2 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vcc-dvdd-csi";
+};
+
+&reg_fldo1 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-1v2-hsic";
+};
+
+/*
+ * The A64 chip cannot work without this regulator off, although
+ * it seems to be only driving the AR100 core.
+ * Maybe we don't still know well about CPUs domain.
+ */
+&reg_fldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpus";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&usbphy {
+	usb1_vbus-supply = <&reg_usb1_vbus>;
+	status = "okay";
+};
-- 
2.11.0

Re: [PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop

[Maxime Ripard]

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

Hi,

On Mon, Mar 12, 2018 at 04:10:50PM +0000, Harald Geyer wrote:
> The TERES I is an open hardware laptop built by Olimex using the
> Allwinner A64 SoC.
> 
> Add the board specific .dts file, which includes the A64 .dtsi and
> enables the peripherals that we support so far.
> 
> Signed-off-by: Harald Geyer <harald@ccbib.org>
> ---
>  arch/arm64/boot/dts/allwinner/Makefile             |   1 +
>  .../boot/dts/allwinner/sun50i-a64-teres-i.dts      | 308 +++++++++++++++++++++
>  2 files changed, 309 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index f505227b0250..5f073f7423b7 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> new file mode 100644
> index 000000000000..0d42b5111f0f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -0,0 +1,308 @@
> +/*
> + * Copyright (C) Harald Geyer <harald@ccbib.org>
> + * based on sun50i-a64-olinuxino.dts by Jagan Teki <jteki@openedev.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */

you should use an SPDX header here to define the license

> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pwm/pwm.h>
> +
> +/ {
> +	model = "Olimex Teres I A64";

It's called the Teres-I, there's no need for the A64 here

> +	compatible = "olimex,a64-teres-i", "allwinner,sun50i-a64";

Or in the compatible

> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm 0 50000 0>;
> +		brightness-levels = <0 10 20 30 40 50 60 70 100>;
> +		default-brightness-level = <3>;
> +		enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +
> +		framebuffer-lcd {
> +			eDP25-supply = <&reg_dldo2>;
> +			eDP12-supply = <&reg_dldo3>;
> +		};
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		lid-switch {
> +			label = "Lid Switch";
> +			gpios = <&r_pio 0 8 GPIO_ACTIVE_LOW>; /* PL8 */
> +			linux,input-type = <EV_SW>;
> +			linux,code = <SW_LID>;
> +		};
> +	};
> +
> +	leds: leds {

Do you need a label?

> +		compatible = "gpio-leds";
> +
> +		led_capslock: capslock {

Same thing here

> +			gpios = <&pio 2 7 GPIO_ACTIVE_HIGH>; /* PC7 */

Ideally you should have LED labels here, following the scheme
devicename:colour:function

> +		};
> +
> +		led_numlock: numlock {
> +			gpios = <&pio 2 4 GPIO_ACTIVE_HIGH>; /* PC4 */
> +		};
> +	};
> +
> +	reg_usb1_vbus: usb1-vbus {
> +		compatible = "regulator-fixed";
> +		regulator-name = "usb1-vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		enable-active-high;
> +		gpio = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> +		status = "okay";

I guess this one has a parent regulator too?

> +	};
> +
> +	wifi_pwrseq: wifi_pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> +	};
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0_pins>;
> +	status = "okay";
> +};

What is this used for?

Looks good otherwise, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: [PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop

[Harald Geyer]

Hi,

> Maxime Ripard writes:
> 
> Hi,
> 
> On Mon, Mar 12, 2018 at 04:10:50PM +0000, Harald Geyer wrote:
>> The TERES I is an open hardware laptop built by Olimex using the
>> Allwinner A64 SoC.
>> 
>> Add the board specific .dts file, which includes the A64 .dtsi and
>> enables the peripherals that we support so far.
>> 
>> Signed-off-by: Harald Geyer <harald@ccbib.org>
>> ---
>>  arch/arm64/boot/dts/allwinner/Makefile             |   1 +
>>  .../boot/dts/allwinner/sun50i-a64-teres-i.dts      | 308 +++++++++++++++++++++
>>  2 files changed, 309 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
>> 
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>> index f505227b0250..5f073f7423b7 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
>> new file mode 100644
>> index 000000000000..0d42b5111f0f
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
>> @@ -0,0 +1,308 @@
>> +/*
>> + * Copyright (C) Harald Geyer <harald@ccbib.org>
>> + * based on sun50i-a64-olinuxino.dts by Jagan Teki <jteki@openedev.com>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
> 
> you should use an SPDX header here to define the license

Ok, I will strip the actual text then. Nice.

>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pwm/pwm.h>
>> +
>> +/ {
>> +	model = "Olimex Teres I A64";
> 
> It's called the Teres-I, there's no need for the A64 here

Olimex said in the past they want the Teres to be very modular, with
boards for different SoCs compatible with each other on the level of
external pins. The PCBs we have right now are labled like
TERES_PCB1-A64-MAIN, TERES-PCB2-IO, etc. - I wouldn't be surprised if
they start selling TERES_PCB1-x86-MAIN to be put into your average Teres I,
so I felt this naming was safer.

However I specifically CCed them on this series, so they can comment on
issues such as this one...

>> +	compatible = "olimex,a64-teres-i", "allwinner,sun50i-a64";
> 
> Or in the compatible
> 
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +	};
>> +
>> +	backlight: backlight {
>> +		compatible = "pwm-backlight";
>> +		pwms = <&pwm 0 50000 0>;
>> +		brightness-levels = <0 10 20 30 40 50 60 70 100>;
>> +		default-brightness-level = <3>;
>> +		enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
>> +	};
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +
>> +		framebuffer-lcd {
>> +			eDP25-supply = <&reg_dldo2>;
>> +			eDP12-supply = <&reg_dldo3>;
>> +		};
>> +	};
>> +
>> +	gpio-keys {
>> +		compatible = "gpio-keys";
>> +
>> +		lid-switch {
>> +			label = "Lid Switch";
>> +			gpios = <&r_pio 0 8 GPIO_ACTIVE_LOW>; /* PL8 */
>> +			linux,input-type = <EV_SW>;
>> +			linux,code = <SW_LID>;
>> +		};
>> +	};
>> +
>> +	leds: leds {
> 
> Do you need a label?

Here probably not.

>> +		compatible = "gpio-leds";
>> +
>> +		led_capslock: capslock {
> 
> Same thing here

I was kind of hoping I could use it to link the led to the keyboard,
so that it goes on when the capslock key is pressed. But no such luck:
1) There seems to be no binding for external leds in the input subsystem.
2) The keyboard is a usb one and get enumerated automatically, so not DT
   node by default.

I guess I can remove it, but then I guess labels for the leds might be
helpful when further customizing the DT locally, so why not just keep them?

>> +			gpios = <&pio 2 7 GPIO_ACTIVE_HIGH>; /* PC7 */
> 
> Ideally you should have LED labels here, following the scheme
> devicename:colour:function

Okay.

>> +		};
>> +
>> +		led_numlock: numlock {
>> +			gpios = <&pio 2 4 GPIO_ACTIVE_HIGH>; /* PC4 */
>> +		};
>> +	};
>> +
>> +	reg_usb1_vbus: usb1-vbus {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "usb1-vbus";
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		enable-active-high;
>> +		gpio = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
>> +		status = "okay";
> 
> I guess this one has a parent regulator too?

Unless I failed to read the schematic correctly: No.
The step-up converter providing 5V power for the usb1-vbus is connected
directly to the IPS (intelligent power source) output of the PMIC and
enabled directly by the 3.3V supply. So technically of course there is
a parent regulator, but nothing we can control from software.

>> +	};
>> +
>> +	wifi_pwrseq: wifi_pwrseq {
>> +		compatible = "mmc-pwrseq-simple";
>> +		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>> +	};
>> +};
>> +
>> +&ehci1 {
>> +	status = "okay";
>> +};
>> +
>> +&i2c0 {
>> +	clock-frequency = <100000>;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&i2c0_pins>;
>> +	status = "okay";
>> +};
> 
> What is this used for?

As explained in the other message in more detail: The ANX6345 eDP-bridge.

Thanks for the review,
Harald

> Looks good otherwise, thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com

Re: [PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop

[Maxime Ripard]

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

On Tue, Mar 13, 2018 at 12:07:36PM +0100, Harald Geyer wrote:
> >> +/ {
> >> +	model = "Olimex Teres I A64";
> > 
> > It's called the Teres-I, there's no need for the A64 here
> 
> Olimex said in the past they want the Teres to be very modular, with
> boards for different SoCs compatible with each other on the level of
> external pins. The PCBs we have right now are labled like
> TERES_PCB1-A64-MAIN, TERES-PCB2-IO, etc. - I wouldn't be surprised if
> they start selling TERES_PCB1-x86-MAIN to be put into your average Teres I,
> so I felt this naming was safer.
> 
> However I specifically CCed them on this series, so they can comment on
> issues such as this one...

Then maybe call it A64 Teres-I to be consistent with the compatible?

> >> +		compatible = "gpio-leds";
> >> +
> >> +		led_capslock: capslock {
> > 
> > Same thing here
> 
> I was kind of hoping I could use it to link the led to the keyboard,
> so that it goes on when the capslock key is pressed. But no such luck:
> 1) There seems to be no binding for external leds in the input subsystem.
> 2) The keyboard is a usb one and get enumerated automatically, so not DT
>    node by default.
> 
> I guess I can remove it, but then I guess labels for the leds might be
> helpful when further customizing the DT locally, so why not just keep them?

I'm not sure that would be useful either. I'd expect someone modifying
the DT locally that they would modify the DT directly, and you already
have the node there.

> >> +	reg_usb1_vbus: usb1-vbus {
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "usb1-vbus";
> >> +		regulator-min-microvolt = <5000000>;
> >> +		regulator-max-microvolt = <5000000>;
> >> +		enable-active-high;
> >> +		gpio = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> >> +		status = "okay";
> > 
> > I guess this one has a parent regulator too?
> 
> Unless I failed to read the schematic correctly: No.
> The step-up converter providing 5V power for the usb1-vbus is connected
> directly to the IPS (intelligent power source) output of the PMIC and
> enabled directly by the 3.3V supply. So technically of course there is
> a parent regulator, but nothing we can control from software.

Ok

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: arm64: allwinner: Add support for TERES I laptop

[afzal mohammed]

Hi,

On Mon, Mar 12, 2018 at 04:10:45PM +0000, Harald Geyer wrote:
> This series adds support for the TERES I open hardware laptop produced
> by olimex. With these patches and a bootloader capable of setting up
> simple framebuffer the laptop is quite useable.

Thanks for the patches

w/ defconfig could reach to prompt via serial console using audio
jack.

And just by enabling PWM_SUN4I & FB_SIMPLE, laptop could function
standalone as well.

Suggestions (feel free to ignore):

1. seems currently only review comment pending is on simple
framebuffer, perhaps you can proceed removing just that so that a
basic bootable system can be achieved at the earliest (iiuc, anyway
drm would be the final solution for display)

2. in next revision (if), may be you can put keywords DIY and/or Open
Hardware (irrespective of whatever exactly that means) Laptop in the
subject itself, that might bring more interest/eyeballs, especially at
this time of ME & so on.

Regards
afzal

Re: arm64: allwinner: Add support for TERES I laptop

[afzal mohammed]

Hi,

On Thu, Mar 15, 2018 at 10:36:06PM +0530, afzal mohammed wrote:
> Thanks for the patches
> 
> w/ defconfig could reach to prompt via serial console using audio
> jack.
> 
> And just by enabling PWM_SUN4I & FB_SIMPLE, laptop could function
> standalone as well.
> 
> Suggestions (feel free to ignore):
> 
> 1. seems currently only review comment pending is on simple
> framebuffer, perhaps you can proceed removing just that so that a
> basic bootable system can be achieved at the earliest (iiuc, anyway
> drm would be the final solution for display)
> 
> 2. in next revision (if), may be you can put keywords DIY and/or Open
> Hardware (irrespective of whatever exactly that means) Laptop in the
> subject itself, that might bring more interest/eyeballs, especially at
> this time of ME & so on.

Realizing now that your v2 patches & above mail crossed.

afzal

Re: arm64: allwinner: Add support for TERES I laptop

[Harald Geyer]

Hi,

afzal mohammed writes:
> On Mon, Mar 12, 2018 at 04:10:45PM +0000, Harald Geyer wrote:
> > This series adds support for the TERES I open hardware laptop produced
> > by olimex. With these patches and a bootloader capable of setting up
> > simple framebuffer the laptop is quite useable.
> 
> Thanks for the patches
> 
> w/ defconfig could reach to prompt via serial console using audio
> jack.
> 
> And just by enabling PWM_SUN4I & FB_SIMPLE, laptop could function
> standalone as well.
> 
> Suggestions (feel free to ignore):
> 
> 1. seems currently only review comment pending is on simple
> framebuffer, perhaps you can proceed removing just that so that a
> basic bootable system can be achieved at the earliest (iiuc, anyway
> drm would be the final solution for display)

I'm under the impression that I addressed the concerns regarding simplefb
satisfactorily. But yes: I hope to get this merged in time for 4.17.
If simplefb is a problem for that, I'd rather drop it then postpone
the entire series.

Thanks for testing,
Harald