[PATCH 0/3] Switch PineTab DT LCD panel to retail one

[PATCH 0/3] Switch PineTab DT LCD panel to retail one

[Icenowy Zheng]

Retail PineTabs switched to K101-IM2BYL02 panel.

This patchset tries to reflect this change, and add a DT for samples
that still have K101-IM2BA02.

Icenowy Zheng (3):
  arm64: allwinner: dts: a64: pinetab: switch LCD panel to production
    one
  dt-bindings: arm: sunxi: add PineTab developer sample DT binding
  arm64: allwinner: dts: a64: add DT for PineTab developer sample

 .../devicetree/bindings/arm/sunxi.yaml        |  5 ++++
 arch/arm64/boot/dts/allwinner/Makefile        |  1 +
 .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28 +++++++++++++++++++
 .../boot/dts/allwinner/sun50i-a64-pinetab.dts |  8 ++----
 4 files changed, 37 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts

-- 
2.28.0

[PATCH 1/3] arm64: allwinner: dts: a64: pinetab: switch LCD panel to production one

[Icenowy Zheng]

All retail PineTabs use the new panel. Devices with the old panel are
only available to several developers as sample.

Switch the main PineTab DT to use the new panel, as it should reflect
what the retail device uses. Another DT for developers' sample will be
added later.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index 0494bfaf2ffa..d91a019301bf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -150,12 +150,10 @@ &dsi {
 	status = "okay";
 
 	panel@0 {
-		compatible = "feixin,k101-im2ba02";
+		compatible = "feixin,k101-im2byl02";
 		reg = <0>;
-		avdd-supply = <&reg_dc1sw>;
-		dvdd-supply = <&reg_dc1sw>;
-		cvdd-supply = <&reg_ldo_io1>;
-		reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+		power-supply = <&reg_dc1sw>;
+		reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
 		backlight = <&backlight>;
 	};
 };
-- 
2.28.0

[PATCH 2/3] dt-bindings: arm: sunxi: add PineTab developer sample DT binding

[Icenowy Zheng]

Some developer samples of PineTab are distributed with the old and
incompatible LCD panel.

Add a device tree binding for this version of PineTab.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 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 ea07f57379d3..9cc5990dc311 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -682,6 +682,11 @@ properties:
           - const: pine64,pinetab
           - const: allwinner,sun50i-a64
 
+      - description: Pine64 PineTab (Developer sample with the old LCD panel)
+        items:
+          - const: pine64,pinetab-dev
+          - const: allwinner,sun50i-a64
+
       - description: Pine64 SoPine Baseboard
         items:
           - const: pine64,sopine-baseboard
-- 
2.28.0

[PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Icenowy Zheng]

Some developers received PineTab samples that used an old LCD panel.

Add device tree for these samples.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 arch/arm64/boot/dts/allwinner/Makefile        |  1 +
 .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28 +++++++++++++++++++
 2 files changed, 29 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..a221dcebfad4 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
new file mode 100644
index 000000000000..3a4153890f3e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng <icenowy@aosc.io>
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+	model = "PineTab Developer Sample";
+	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
+};
+
+&dsi {
+	/delete-node/ panel@0;
+
+	panel@0 {
+		compatible = "feixin,k101-im2ba02";
+		reg = <0>;
+		avdd-supply = <&reg_dc1sw>;
+		dvdd-supply = <&reg_dc1sw>;
+		cvdd-supply = <&reg_ldo_io1>;
+		reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+		backlight = <&backlight>;
+	};
+};
-- 
2.28.0

Re: [PATCH 2/3] dt-bindings: arm: sunxi: add PineTab developer sample DT binding

[Rob Herring]

On Sat, 07 Nov 2020 20:52:33 +0800, Icenowy Zheng wrote:
> Some developer samples of PineTab are distributed with the old and
> incompatible LCD panel.
> 
> Add a device tree binding for this version of PineTab.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 

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

Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Maxime Ripard]

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

On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
> Some developers received PineTab samples that used an old LCD panel.
> 
> Add device tree for these samples.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
>  arch/arm64/boot/dts/allwinner/Makefile        |  1 +
>  .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28 +++++++++++++++++++
>  2 files changed, 29 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 211d1e9d4701..a221dcebfad4 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> new file mode 100644
> index 000000000000..3a4153890f3e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2020 Icenowy Zheng <icenowy@aosc.io>
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64-pinetab.dts"
> +
> +/ {
> +	model = "PineTab Developer Sample";
> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
> +};

Changing the DT and the compatible half-way through it isn't ok. Please
add a new DT with the newer revision like we did for the pinephone

Maxime

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

Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Icenowy Zheng]

于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard <maxime@cerno.tech> 写到:
>On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> Some developers received PineTab samples that used an old LCD panel.
>> 
>> Add device tree for these samples.
>> 
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>>  arch/arm64/boot/dts/allwinner/Makefile        |  1 +
>>  .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28
>+++++++++++++++++++
>>  2 files changed, 29 insertions(+)
>>  create mode 100644
>arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> 
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>b/arch/arm64/boot/dts/allwinner/Makefile
>> index 211d1e9d4701..a221dcebfad4 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>sun50i-a64-pinephone-1.0.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> new file mode 100644
>> index 000000000000..3a4153890f3e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> @@ -0,0 +1,28 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (C) 2020 Icenowy Zheng <icenowy@aosc.io>
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64-pinetab.dts"
>> +
>> +/ {
>> +	model = "PineTab Developer Sample";
>> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> +};
>
>Changing the DT and the compatible half-way through it isn't ok. Please
>add a new DT with the newer revision like we did for the pinephone

We did this on Pine H64.

>
>Maxime

Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Maxime Ripard]

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

On Tue, Nov 10, 2020 at 06:41:37PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard <maxime@cerno.tech> 写到:
> >On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
> >> Some developers received PineTab samples that used an old LCD panel.
> >> 
> >> Add device tree for these samples.
> >> 
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> ---
> >>  arch/arm64/boot/dts/allwinner/Makefile        |  1 +
> >>  .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28
> >+++++++++++++++++++
> >>  2 files changed, 29 insertions(+)
> >>  create mode 100644
> >arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> >> 
> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >b/arch/arm64/boot/dts/allwinner/Makefile
> >> index 211d1e9d4701..a221dcebfad4 100644
> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
> >sun50i-a64-pinephone-1.0.dtb
> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> >> new file mode 100644
> >> index 000000000000..3a4153890f3e
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> >> @@ -0,0 +1,28 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> +/*
> >> + * Copyright (C) 2020 Icenowy Zheng <icenowy@aosc.io>
> >> + *
> >> + */
> >> +
> >> +/dts-v1/;
> >> +
> >> +#include "sun50i-a64-pinetab.dts"
> >> +
> >> +/ {
> >> +	model = "PineTab Developer Sample";
> >> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
> >> +};
> >
> >Changing the DT and the compatible half-way through it isn't ok. Please
> >add a new DT with the newer revision like we did for the pinephone
> 
> We did this on Pine H64.

What are you referring to? I couldn't find a commit where we did what
you suggested in that patch to the pine H64.

Maxime

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

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Icenowy Zheng]

于 2020年11月16日 GMT+08:00 下午11:55:08, Maxime Ripard <maxime@cerno.tech> 写到:
>On Tue, Nov 10, 2020 at 06:41:37PM +0800, Icenowy Zheng wrote:
>> 
>> 
>> 于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard <maxime@cerno.tech>
>写到:
>> >On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> >> Some developers received PineTab samples that used an old LCD
>panel.
>> >> 
>> >> Add device tree for these samples.
>> >> 
>> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >> ---
>> >>  arch/arm64/boot/dts/allwinner/Makefile        |  1 +
>> >>  .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28
>> >+++++++++++++++++++
>> >>  2 files changed, 29 insertions(+)
>> >>  create mode 100644
>> >arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> 
>> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >b/arch/arm64/boot/dts/allwinner/Makefile
>> >> index 211d1e9d4701..a221dcebfad4 100644
>> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>> >sun50i-a64-pinephone-1.0.dtb
>> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> >> diff --git
>a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> new file mode 100644
>> >> index 000000000000..3a4153890f3e
>> >> --- /dev/null
>> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> @@ -0,0 +1,28 @@
>> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> >> +/*
>> >> + * Copyright (C) 2020 Icenowy Zheng <icenowy@aosc.io>
>> >> + *
>> >> + */
>> >> +
>> >> +/dts-v1/;
>> >> +
>> >> +#include "sun50i-a64-pinetab.dts"
>> >> +
>> >> +/ {
>> >> +	model = "PineTab Developer Sample";
>> >> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >> +};
>> >
>> >Changing the DT and the compatible half-way through it isn't ok.
>Please
>> >add a new DT with the newer revision like we did for the pinephone
>> 
>> We did this on Pine H64.
>
>What are you referring to? I couldn't find a commit where we did what
>you suggested in that patch to the pine H64.

Oh the situation is complex. On Pine H64, we didn't specify anything at
start (which is the same here), the DT is originally version-neutral
but then transitioned to model B, then reverted to model A. Here the DT is always
for the sample.

However, for Pine H64 there's model A/B names, but for PineTab there's no
any samples that are sold, thus except who got the samples, all PineTab
owners simply owns a "PineTab", not a "PineTab xxx version".

>
>Maxime

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Maxime Ripard]

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

On Tue, Nov 17, 2020 at 02:36:48AM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2020年11月16日 GMT+08:00 下午11:55:08, Maxime Ripard <maxime@cerno.tech> 写到:
> >On Tue, Nov 10, 2020 at 06:41:37PM +0800, Icenowy Zheng wrote:
> >> 
> >> 
> >> 于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard <maxime@cerno.tech>
> >写到:
> >> >On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
> >> >> Some developers received PineTab samples that used an old LCD
> >panel.
> >> >> 
> >> >> Add device tree for these samples.
> >> >> 
> >> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> >> ---
> >> >>  arch/arm64/boot/dts/allwinner/Makefile        |  1 +
> >> >>  .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28
> >> >+++++++++++++++++++
> >> >>  2 files changed, 29 insertions(+)
> >> >>  create mode 100644
> >> >arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> >> >> 
> >> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> >b/arch/arm64/boot/dts/allwinner/Makefile
> >> >> index 211d1e9d4701..a221dcebfad4 100644
> >> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
> >> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> >> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
> >> >sun50i-a64-pinephone-1.0.dtb
> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
> >> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> >> >> diff --git
> >a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> >> >> new file mode 100644
> >> >> index 000000000000..3a4153890f3e
> >> >> --- /dev/null
> >> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
> >> >> @@ -0,0 +1,28 @@
> >> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> >> +/*
> >> >> + * Copyright (C) 2020 Icenowy Zheng <icenowy@aosc.io>
> >> >> + *
> >> >> + */
> >> >> +
> >> >> +/dts-v1/;
> >> >> +
> >> >> +#include "sun50i-a64-pinetab.dts"
> >> >> +
> >> >> +/ {
> >> >> +	model = "PineTab Developer Sample";
> >> >> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
> >> >> +};
> >> >
> >> >Changing the DT and the compatible half-way through it isn't ok.
> >Please
> >> >add a new DT with the newer revision like we did for the pinephone
> >> 
> >> We did this on Pine H64.
> >
> >What are you referring to? I couldn't find a commit where we did what
> >you suggested in that patch to the pine H64.
> 
> Oh the situation is complex. On Pine H64, we didn't specify anything at
> start (which is the same here), the DT is originally version-neutral
> but then transitioned to model B, then reverted to model A. Here the DT is always
> for the sample.
> 
> However, for Pine H64 there's model A/B names, but for PineTab there's no
> any samples that are sold, thus except who got the samples, all PineTab
> owners simply owns a "PineTab", not a "PineTab xxx version".

It's fairly simple really, we can't really predict the future, so any DT
submitted is for the current version of whatever board there is. This is
what we (somewhat messily) did for the PineH64, for the pinephone, or
really any other board that has several revisions

Maxime

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

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Icenowy Zheng]

于 2020年11月20日 GMT+08:00 下午11:59:39, Maxime Ripard <maxime@cerno.tech> 写到:
>On Tue, Nov 17, 2020 at 02:36:48AM +0800, Icenowy Zheng wrote:
>> 
>> 
>> 于 2020年11月16日 GMT+08:00 下午11:55:08, Maxime Ripard <maxime@cerno.tech>
>写到:
>> >On Tue, Nov 10, 2020 at 06:41:37PM +0800, Icenowy Zheng wrote:
>> >> 
>> >> 
>> >> 于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard
><maxime@cerno.tech>
>> >写到:
>> >> >On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> >> >> Some developers received PineTab samples that used an old LCD
>> >panel.
>> >> >> 
>> >> >> Add device tree for these samples.
>> >> >> 
>> >> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >> >> ---
>> >> >>  arch/arm64/boot/dts/allwinner/Makefile        |  1 +
>> >> >>  .../dts/allwinner/sun50i-a64-pinetab-dev.dts  | 28
>> >> >+++++++++++++++++++
>> >> >>  2 files changed, 29 insertions(+)
>> >> >>  create mode 100644
>> >> >arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >> 
>> >> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> index 211d1e9d4701..a221dcebfad4 100644
>> >> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>> >> >sun50i-a64-pinephone-1.0.dtb
>> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> >> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> >> >>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> >> >> diff --git
>> >a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >> new file mode 100644
>> >> >> index 000000000000..3a4153890f3e
>> >> >> --- /dev/null
>> >> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >> @@ -0,0 +1,28 @@
>> >> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> >> >> +/*
>> >> >> + * Copyright (C) 2020 Icenowy Zheng <icenowy@aosc.io>
>> >> >> + *
>> >> >> + */
>> >> >> +
>> >> >> +/dts-v1/;
>> >> >> +
>> >> >> +#include "sun50i-a64-pinetab.dts"
>> >> >> +
>> >> >> +/ {
>> >> >> +	model = "PineTab Developer Sample";
>> >> >> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >> >> +};
>> >> >
>> >> >Changing the DT and the compatible half-way through it isn't ok.
>> >Please
>> >> >add a new DT with the newer revision like we did for the
>pinephone
>> >> 
>> >> We did this on Pine H64.
>> >
>> >What are you referring to? I couldn't find a commit where we did
>what
>> >you suggested in that patch to the pine H64.
>> 
>> Oh the situation is complex. On Pine H64, we didn't specify anything
>at
>> start (which is the same here), the DT is originally version-neutral
>> but then transitioned to model B, then reverted to model A. Here the
>DT is always
>> for the sample.
>> 
>> However, for Pine H64 there's model A/B names, but for PineTab
>there's no
>> any samples that are sold, thus except who got the samples, all
>PineTab
>> owners simply owns a "PineTab", not a "PineTab xxx version".
>
>It's fairly simple really, we can't really predict the future, so any
>DT
>submitted is for the current version of whatever board there is. This
>is
>what we (somewhat messily) did for the PineH64, for the pinephone, or
>really any other board that has several revisions

Okay. But I'm not satisfied with a non-public sample occupies
the pinetab name. Is rename it to pinetab-dev and add a
pinetab-retail okay?

>
>Maxime

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Samuel Holland]

Maxime,

On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>>>>>>> +/ {
>>>>>>> +	model = "PineTab Developer Sample";
>>>>>>> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>>>>>>> +};
>>>>>>
>>>>>> Changing the DT and the compatible half-way through it isn't ok. Please
>>>>>> add a new DT with the newer revision like we did for the pinephone
>>>>>
>>>>> We did this on Pine H64.
>>>>
>>>> What are you referring to? I couldn't find a commit where we did what
>>>> you suggested in that patch to the pine H64.
>>>
>>> Oh the situation is complex. On Pine H64, we didn't specify anything at
>>> start (which is the same here), the DT is originally version-neutral
>>> but then transitioned to model B, then reverted to model A. Here the DT is always
>>> for the sample.
>>>
>>> However, for Pine H64 there's model A/B names, but for PineTab there's no
>>> any samples that are sold, thus except who got the samples, all PineTab
>>> owners simply owns a "PineTab", not a "PineTab xxx version".
>>
>> It's fairly simple really, we can't really predict the future, so any DT
>> submitted is for the current version of whatever board there is. This is

I don't think that was the intention at all. The DT was submitted for a
future product, whatever that future product ends up being at the time
of its release. Since there are necessarily no users until the product
ships, there is no chance of breaking users by modifying the DT.

>> what we (somewhat messily) did for the PineH64, for the pinephone, or
>> really any other board that has several revisions

Surely a non-public prototype doesn't count as a separate revision! This
sort of policy strongly discourages ever shipping a board with
out-of-the-box mainline Linux support. Because if there any hardware
bugs fixed between initial upstreaming and production, the manufacture
must come up with a new DT name.

This is hostile to the users as well, because the "canonical" DT name no
longer matches the "canonical" (read: the only one ever available)
version of the hardware.

Do you want manufacturers to submit their initial board DT as
"$BOARD-prototype.dts", just in case they have to make a change before
production? And only after the board is shipped (with out-of-tree
patches, of course, to use $BOARD.dts, since the shipped board is *not*
the prototype) submit a "$BOARD.dts" to mainline?

Maxime, can you clarify specifically what the line is where a device
tree is "locked down" and further changes to the hardware require a new
name? First sample leaves the factory? $NUMBER units produced? First
sold to the public for money?

Without some guidance, or a change in policy, this problem is going to
keep coming up again and again.

You'll note that so far it has mostly affected Pine devices, and I don't
think that's because they make more board revisions than other
manufacturers. It's because they're actively involved in getting their
boards supported upstream. For other manufacturers, it's some user
sending in a device tree months after the hardware ships to the public
-- of course the hardware is more stable at that point. I think Pine's
behavior is something we want to encourage, not penalize.

> Okay. But I'm not satisfied with a non-public sample occupies
> the pinetab name. Is rename it to pinetab-dev and add a
> pinetab-retail okay?
To me, naming the production version anything but "pinetab" isn't
satisfying either.

Samuel

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Maxime Ripard]

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

Hi!

On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
> >>>>>>> +/ {
> >>>>>>> +	model = "PineTab Developer Sample";
> >>>>>>> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
> >>>>>>> +};
> >>>>>>
> >>>>>> Changing the DT and the compatible half-way through it isn't ok. Please
> >>>>>> add a new DT with the newer revision like we did for the pinephone
> >>>>>
> >>>>> We did this on Pine H64.
> >>>>
> >>>> What are you referring to? I couldn't find a commit where we did what
> >>>> you suggested in that patch to the pine H64.
> >>>
> >>> Oh the situation is complex. On Pine H64, we didn't specify anything at
> >>> start (which is the same here), the DT is originally version-neutral
> >>> but then transitioned to model B, then reverted to model A. Here the DT is always
> >>> for the sample.
> >>>
> >>> However, for Pine H64 there's model A/B names, but for PineTab there's no
> >>> any samples that are sold, thus except who got the samples, all PineTab
> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
> >>
> >> It's fairly simple really, we can't really predict the future, so any DT
> >> submitted is for the current version of whatever board there is. This is
> 
> I don't think that was the intention at all. The DT was submitted for a
> future product, whatever that future product ends up being at the time
> of its release. Since there are necessarily no users until the product
> ships, there is no chance of breaking users by modifying the DT.

There was no indication of that in the commit though

> >> what we (somewhat messily) did for the PineH64, for the pinephone, or
> >> really any other board that has several revisions
> 
> Surely a non-public prototype doesn't count as a separate revision! This
> sort of policy strongly discourages ever shipping a board with
> out-of-the-box mainline Linux support. Because if there any hardware
> bugs fixed between initial upstreaming and production, the manufacture
> must come up with a new DT name.
> 
> This is hostile to the users as well, because the "canonical" DT name no
> longer matches the "canonical" (read: the only one ever available)
> version of the hardware.
> 
> Do you want manufacturers to submit their initial board DT as
> "$BOARD-prototype.dts", just in case they have to make a change before
> production? And only after the board is shipped (with out-of-tree
> patches, of course, to use $BOARD.dts, since the shipped board is *not*
> the prototype) submit a "$BOARD.dts" to mainline?
> 
> Maxime, can you clarify specifically what the line is where a device
> tree is "locked down" and further changes to the hardware require a new
> name? First sample leaves the factory? $NUMBER units produced? First
> sold to the public for money?

The first board that is shipped to a user. From the wiki, the version
supported here (I guess?) has been shipped to around 100 people, so it
doesn't really qualify for the "non-public prototype". We still have to
support these users, whether we like it or not.

> Without some guidance, or a change in policy, this problem is going to
> keep coming up again and again.

There's a few things that are interleaved here. First, there's two hard
rules: never change the DT name and never change the compatible of a
board.

The former would break any build system, boot script or documentation,
and the latter would break the DT compatibility.

Aside from this, things get a bit blurrier since it's mostly about the
intent. I'm fine with having a DT for a non-public prototype if it's
clear from day one that it is. In this particular case, the DT just
stated that support for the pinetab was added. I guess anyone would make
the assumption without any context that this would be for the (or a)
final design.

Finally, I'd also advise against submitting the parts that are still not
finalized though, because this is also fairly bad for the users. Let's
take the current situation as the example: from what I understand, the
screen changed half-way through the process, and the first one was
upstreamed. This means that any user that would use a kernel with that
bugfix would have the display working, while rolling back to 5.9 would
break the display, even though everyone claimed it was supported
out-of-the-box in mainline. This is a worse situation than not
supporting the display in the first place here.

> You'll note that so far it has mostly affected Pine devices, and I don't
> think that's because they make more board revisions than other
> manufacturers.

Yes definitely. Pine devices may be worse though because of their policy
of making their prototypes public. I guess most of the issues we had
also were due to poor communication: context on what were the Pine
intentions were missing, and thus we couldn't catch things that turned
out to be bad later on during review.

> It's because they're actively involved in getting their
> boards supported upstream. For other manufacturers, it's some user
> sending in a device tree months after the hardware ships to the public
> -- of course the hardware is more stable at that point.

I mean, it's not black and white either. One could very well send the DT
once the final design is done and that would still be upstreamed way
before reaching the first user.

> I think Pine's behavior is something we want to encourage, not
> penalize.

For the DT in particular, yes

> > Okay. But I'm not satisfied with a non-public sample occupies
> > the pinetab name. Is rename it to pinetab-dev and add a
> > pinetab-retail okay?
>
> To me, naming the production version anything but "pinetab" isn't
> satisfying either.

I understand where you're coming from, but the point I was making my
previous mail is precisely that it's not really possible.

You want to name the early adopter version _the_ production version.
Let's assume the hardware changes again between the early adopter and
mass-production version. Which one will be _the_ production version? The
early-adopter or the mass-produced one?

There's really no good answer here, and both would suck in their own
way. The only way to deal with this is to simply avoid defining one
version as the one true board, and just loading the proper DT in u-boot
based on whatever clue we have of the hardware revision.

Maxime

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

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Icenowy Zheng]

于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard <maxime@cerno.tech> 写到:
>Hi!
>
>On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
>> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>> >>>>>>> +/ {
>> >>>>>>> +	model = "PineTab Developer Sample";
>> >>>>>>> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >>>>>>> +};
>> >>>>>>
>> >>>>>> Changing the DT and the compatible half-way through it isn't
>ok. Please
>> >>>>>> add a new DT with the newer revision like we did for the
>pinephone
>> >>>>>
>> >>>>> We did this on Pine H64.
>> >>>>
>> >>>> What are you referring to? I couldn't find a commit where we did
>what
>> >>>> you suggested in that patch to the pine H64.
>> >>>
>> >>> Oh the situation is complex. On Pine H64, we didn't specify
>anything at
>> >>> start (which is the same here), the DT is originally
>version-neutral
>> >>> but then transitioned to model B, then reverted to model A. Here
>the DT is always
>> >>> for the sample.
>> >>>
>> >>> However, for Pine H64 there's model A/B names, but for PineTab
>there's no
>> >>> any samples that are sold, thus except who got the samples, all
>PineTab
>> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
>> >>
>> >> It's fairly simple really, we can't really predict the future, so
>any DT
>> >> submitted is for the current version of whatever board there is.
>This is
>> 
>> I don't think that was the intention at all. The DT was submitted for
>a
>> future product, whatever that future product ends up being at the
>time
>> of its release. Since there are necessarily no users until the
>product
>> ships, there is no chance of breaking users by modifying the DT.
>
>There was no indication of that in the commit though
>
>> >> what we (somewhat messily) did for the PineH64, for the pinephone,
>or
>> >> really any other board that has several revisions
>> 
>> Surely a non-public prototype doesn't count as a separate revision!
>This
>> sort of policy strongly discourages ever shipping a board with
>> out-of-the-box mainline Linux support. Because if there any hardware
>> bugs fixed between initial upstreaming and production, the
>manufacture
>> must come up with a new DT name.
>> 
>> This is hostile to the users as well, because the "canonical" DT name
>no
>> longer matches the "canonical" (read: the only one ever available)
>> version of the hardware.
>> 
>> Do you want manufacturers to submit their initial board DT as
>> "$BOARD-prototype.dts", just in case they have to make a change
>before
>> production? And only after the board is shipped (with out-of-tree
>> patches, of course, to use $BOARD.dts, since the shipped board is
>*not*
>> the prototype) submit a "$BOARD.dts" to mainline?
>> 
>> Maxime, can you clarify specifically what the line is where a device
>> tree is "locked down" and further changes to the hardware require a
>new
>> name? First sample leaves the factory? $NUMBER units produced? First
>> sold to the public for money?
>
>The first board that is shipped to a user. From the wiki, the version
>supported here (I guess?) has been shipped to around 100 people, so it
>doesn't really qualify for the "non-public prototype". We still have to
>support these users, whether we like it or not.
>
>> Without some guidance, or a change in policy, this problem is going
>to
>> keep coming up again and again.
>
>There's a few things that are interleaved here. First, there's two hard
>rules: never change the DT name and never change the compatible of a
>board.
>
>The former would break any build system, boot script or documentation,
>and the latter would break the DT compatibility.
>
>Aside from this, things get a bit blurrier since it's mostly about the
>intent. I'm fine with having a DT for a non-public prototype if it's
>clear from day one that it is. In this particular case, the DT just
>stated that support for the pinetab was added. I guess anyone would
>make
>the assumption without any context that this would be for the (or a)
>final design.
>
>Finally, I'd also advise against submitting the parts that are still
>not
>finalized though, because this is also fairly bad for the users. Let's
>take the current situation as the example: from what I understand, the
>screen changed half-way through the process, and the first one was
>upstreamed. This means that any user that would use a kernel with that
>bugfix would have the display working, while rolling back to 5.9 would
>break the display, even though everyone claimed it was supported
>out-of-the-box in mainline. This is a worse situation than not
>supporting the display in the first place here.
>
>> You'll note that so far it has mostly affected Pine devices, and I
>don't
>> think that's because they make more board revisions than other
>> manufacturers.
>
>Yes definitely. Pine devices may be worse though because of their
>policy
>of making their prototypes public. I guess most of the issues we had
>also were due to poor communication: context on what were the Pine
>intentions were missing, and thus we couldn't catch things that turned
>out to be bad later on during review.
>
>> It's because they're actively involved in getting their
>> boards supported upstream. For other manufacturers, it's some user
>> sending in a device tree months after the hardware ships to the
>public
>> -- of course the hardware is more stable at that point.
>
>I mean, it's not black and white either. One could very well send the
>DT
>once the final design is done and that would still be upstreamed way
>before reaching the first user.
>
>> I think Pine's behavior is something we want to encourage, not
>> penalize.
>
>For the DT in particular, yes
>
>> > Okay. But I'm not satisfied with a non-public sample occupies
>> > the pinetab name. Is rename it to pinetab-dev and add a
>> > pinetab-retail okay?
>>
>> To me, naming the production version anything but "pinetab" isn't
>> satisfying either.
>
>I understand where you're coming from, but the point I was making my
>previous mail is precisely that it's not really possible.
>
>You want to name the early adopter version _the_ production version.
>Let's assume the hardware changes again between the early adopter and
>mass-production version. Which one will be _the_ production version?
>The
>early-adopter or the mass-produced one?
>
>There's really no good answer here, and both would suck in their own
>way. The only way to deal with this is to simply avoid defining one
>version as the one true board, and just loading the proper DT in u-boot
>based on whatever clue we have of the hardware revision.


Then will it be okay to rename current pinetab DT to pinetab-sample and
then introduce new DTs all with suffixes?

>
>Maxime

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Maxime Ripard]

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

On Mon, Nov 23, 2020 at 07:25:47PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard <maxime@cerno.tech> 写到:
> >Hi!
> >
> >On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
> >> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
> >> >>>>>>> +/ {
> >> >>>>>>> +	model = "PineTab Developer Sample";
> >> >>>>>>> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
> >> >>>>>>> +};
> >> >>>>>>
> >> >>>>>> Changing the DT and the compatible half-way through it isn't
> >ok. Please
> >> >>>>>> add a new DT with the newer revision like we did for the
> >pinephone
> >> >>>>>
> >> >>>>> We did this on Pine H64.
> >> >>>>
> >> >>>> What are you referring to? I couldn't find a commit where we did
> >what
> >> >>>> you suggested in that patch to the pine H64.
> >> >>>
> >> >>> Oh the situation is complex. On Pine H64, we didn't specify
> >anything at
> >> >>> start (which is the same here), the DT is originally
> >version-neutral
> >> >>> but then transitioned to model B, then reverted to model A. Here
> >the DT is always
> >> >>> for the sample.
> >> >>>
> >> >>> However, for Pine H64 there's model A/B names, but for PineTab
> >there's no
> >> >>> any samples that are sold, thus except who got the samples, all
> >PineTab
> >> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
> >> >>
> >> >> It's fairly simple really, we can't really predict the future, so
> >any DT
> >> >> submitted is for the current version of whatever board there is.
> >This is
> >> 
> >> I don't think that was the intention at all. The DT was submitted for
> >a
> >> future product, whatever that future product ends up being at the
> >time
> >> of its release. Since there are necessarily no users until the
> >product
> >> ships, there is no chance of breaking users by modifying the DT.
> >
> >There was no indication of that in the commit though
> >
> >> >> what we (somewhat messily) did for the PineH64, for the pinephone,
> >or
> >> >> really any other board that has several revisions
> >> 
> >> Surely a non-public prototype doesn't count as a separate revision!
> >This
> >> sort of policy strongly discourages ever shipping a board with
> >> out-of-the-box mainline Linux support. Because if there any hardware
> >> bugs fixed between initial upstreaming and production, the
> >manufacture
> >> must come up with a new DT name.
> >> 
> >> This is hostile to the users as well, because the "canonical" DT name
> >no
> >> longer matches the "canonical" (read: the only one ever available)
> >> version of the hardware.
> >> 
> >> Do you want manufacturers to submit their initial board DT as
> >> "$BOARD-prototype.dts", just in case they have to make a change
> >before
> >> production? And only after the board is shipped (with out-of-tree
> >> patches, of course, to use $BOARD.dts, since the shipped board is
> >*not*
> >> the prototype) submit a "$BOARD.dts" to mainline?
> >> 
> >> Maxime, can you clarify specifically what the line is where a device
> >> tree is "locked down" and further changes to the hardware require a
> >new
> >> name? First sample leaves the factory? $NUMBER units produced? First
> >> sold to the public for money?
> >
> >The first board that is shipped to a user. From the wiki, the version
> >supported here (I guess?) has been shipped to around 100 people, so it
> >doesn't really qualify for the "non-public prototype". We still have to
> >support these users, whether we like it or not.
> >
> >> Without some guidance, or a change in policy, this problem is going
> >to
> >> keep coming up again and again.
> >
> >There's a few things that are interleaved here. First, there's two hard
> >rules: never change the DT name and never change the compatible of a
> >board.
> >
> >The former would break any build system, boot script or documentation,
> >and the latter would break the DT compatibility.
> >
> >Aside from this, things get a bit blurrier since it's mostly about the
> >intent. I'm fine with having a DT for a non-public prototype if it's
> >clear from day one that it is. In this particular case, the DT just
> >stated that support for the pinetab was added. I guess anyone would
> >make
> >the assumption without any context that this would be for the (or a)
> >final design.
> >
> >Finally, I'd also advise against submitting the parts that are still
> >not
> >finalized though, because this is also fairly bad for the users. Let's
> >take the current situation as the example: from what I understand, the
> >screen changed half-way through the process, and the first one was
> >upstreamed. This means that any user that would use a kernel with that
> >bugfix would have the display working, while rolling back to 5.9 would
> >break the display, even though everyone claimed it was supported
> >out-of-the-box in mainline. This is a worse situation than not
> >supporting the display in the first place here.
> >
> >> You'll note that so far it has mostly affected Pine devices, and I
> >don't
> >> think that's because they make more board revisions than other
> >> manufacturers.
> >
> >Yes definitely. Pine devices may be worse though because of their
> >policy
> >of making their prototypes public. I guess most of the issues we had
> >also were due to poor communication: context on what were the Pine
> >intentions were missing, and thus we couldn't catch things that turned
> >out to be bad later on during review.
> >
> >> It's because they're actively involved in getting their
> >> boards supported upstream. For other manufacturers, it's some user
> >> sending in a device tree months after the hardware ships to the
> >public
> >> -- of course the hardware is more stable at that point.
> >
> >I mean, it's not black and white either. One could very well send the
> >DT
> >once the final design is done and that would still be upstreamed way
> >before reaching the first user.
> >
> >> I think Pine's behavior is something we want to encourage, not
> >> penalize.
> >
> >For the DT in particular, yes
> >
> >> > Okay. But I'm not satisfied with a non-public sample occupies
> >> > the pinetab name. Is rename it to pinetab-dev and add a
> >> > pinetab-retail okay?
> >>
> >> To me, naming the production version anything but "pinetab" isn't
> >> satisfying either.
> >
> >I understand where you're coming from, but the point I was making my
> >previous mail is precisely that it's not really possible.
> >
> >You want to name the early adopter version _the_ production version.
> >Let's assume the hardware changes again between the early adopter and
> >mass-production version. Which one will be _the_ production version?
> >The
> >early-adopter or the mass-produced one?
> >
> >There's really no good answer here, and both would suck in their own
> >way. The only way to deal with this is to simply avoid defining one
> >version as the one true board, and just loading the proper DT in u-boot
> >based on whatever clue we have of the hardware revision.
> 
> Then will it be okay to rename current pinetab DT to pinetab-sample and
> then introduce new DTs all with suffixes?

No. From my previous mail:

> > there's two hard rules: never change the DT name and never change
> > the compatible of a board.
> >
> > The former would break any build system, boot script or
> > documentation, and the latter would break the DT compatibility.

Maxime

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

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Icenowy Zheng]

于 2020年11月23日 GMT+08:00 下午8:53:32, Maxime Ripard <maxime@cerno.tech> 写到:
>On Mon, Nov 23, 2020 at 07:25:47PM +0800, Icenowy Zheng wrote:
>> 
>> 
>> 于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard <maxime@cerno.tech>
>写到:
>> >Hi!
>> >
>> >On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
>> >> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>> >> >>>>>>> +/ {
>> >> >>>>>>> +	model = "PineTab Developer Sample";
>> >> >>>>>>> +	compatible = "pine64,pinetab-dev",
>"allwinner,sun50i-a64";
>> >> >>>>>>> +};
>> >> >>>>>>
>> >> >>>>>> Changing the DT and the compatible half-way through it
>isn't
>> >ok. Please
>> >> >>>>>> add a new DT with the newer revision like we did for the
>> >pinephone
>> >> >>>>>
>> >> >>>>> We did this on Pine H64.
>> >> >>>>
>> >> >>>> What are you referring to? I couldn't find a commit where we
>did
>> >what
>> >> >>>> you suggested in that patch to the pine H64.
>> >> >>>
>> >> >>> Oh the situation is complex. On Pine H64, we didn't specify
>> >anything at
>> >> >>> start (which is the same here), the DT is originally
>> >version-neutral
>> >> >>> but then transitioned to model B, then reverted to model A.
>Here
>> >the DT is always
>> >> >>> for the sample.
>> >> >>>
>> >> >>> However, for Pine H64 there's model A/B names, but for PineTab
>> >there's no
>> >> >>> any samples that are sold, thus except who got the samples,
>all
>> >PineTab
>> >> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
>> >> >>
>> >> >> It's fairly simple really, we can't really predict the future,
>so
>> >any DT
>> >> >> submitted is for the current version of whatever board there
>is.
>> >This is
>> >> 
>> >> I don't think that was the intention at all. The DT was submitted
>for
>> >a
>> >> future product, whatever that future product ends up being at the
>> >time
>> >> of its release. Since there are necessarily no users until the
>> >product
>> >> ships, there is no chance of breaking users by modifying the DT.
>> >
>> >There was no indication of that in the commit though
>> >
>> >> >> what we (somewhat messily) did for the PineH64, for the
>pinephone,
>> >or
>> >> >> really any other board that has several revisions
>> >> 
>> >> Surely a non-public prototype doesn't count as a separate
>revision!
>> >This
>> >> sort of policy strongly discourages ever shipping a board with
>> >> out-of-the-box mainline Linux support. Because if there any
>hardware
>> >> bugs fixed between initial upstreaming and production, the
>> >manufacture
>> >> must come up with a new DT name.
>> >> 
>> >> This is hostile to the users as well, because the "canonical" DT
>name
>> >no
>> >> longer matches the "canonical" (read: the only one ever available)
>> >> version of the hardware.
>> >> 
>> >> Do you want manufacturers to submit their initial board DT as
>> >> "$BOARD-prototype.dts", just in case they have to make a change
>> >before
>> >> production? And only after the board is shipped (with out-of-tree
>> >> patches, of course, to use $BOARD.dts, since the shipped board is
>> >*not*
>> >> the prototype) submit a "$BOARD.dts" to mainline?
>> >> 
>> >> Maxime, can you clarify specifically what the line is where a
>device
>> >> tree is "locked down" and further changes to the hardware require
>a
>> >new
>> >> name? First sample leaves the factory? $NUMBER units produced?
>First
>> >> sold to the public for money?
>> >
>> >The first board that is shipped to a user. From the wiki, the
>version
>> >supported here (I guess?) has been shipped to around 100 people, so
>it
>> >doesn't really qualify for the "non-public prototype". We still have
>to
>> >support these users, whether we like it or not.
>> >
>> >> Without some guidance, or a change in policy, this problem is
>going
>> >to
>> >> keep coming up again and again.
>> >
>> >There's a few things that are interleaved here. First, there's two
>hard
>> >rules: never change the DT name and never change the compatible of a
>> >board.
>> >
>> >The former would break any build system, boot script or
>documentation,
>> >and the latter would break the DT compatibility.
>> >
>> >Aside from this, things get a bit blurrier since it's mostly about
>the
>> >intent. I'm fine with having a DT for a non-public prototype if it's
>> >clear from day one that it is. In this particular case, the DT just
>> >stated that support for the pinetab was added. I guess anyone would
>> >make
>> >the assumption without any context that this would be for the (or a)
>> >final design.
>> >
>> >Finally, I'd also advise against submitting the parts that are still
>> >not
>> >finalized though, because this is also fairly bad for the users.
>Let's
>> >take the current situation as the example: from what I understand,
>the
>> >screen changed half-way through the process, and the first one was
>> >upstreamed. This means that any user that would use a kernel with
>that
>> >bugfix would have the display working, while rolling back to 5.9
>would
>> >break the display, even though everyone claimed it was supported
>> >out-of-the-box in mainline. This is a worse situation than not
>> >supporting the display in the first place here.
>> >
>> >> You'll note that so far it has mostly affected Pine devices, and I
>> >don't
>> >> think that's because they make more board revisions than other
>> >> manufacturers.
>> >
>> >Yes definitely. Pine devices may be worse though because of their
>> >policy
>> >of making their prototypes public. I guess most of the issues we had
>> >also were due to poor communication: context on what were the Pine
>> >intentions were missing, and thus we couldn't catch things that
>turned
>> >out to be bad later on during review.
>> >
>> >> It's because they're actively involved in getting their
>> >> boards supported upstream. For other manufacturers, it's some user
>> >> sending in a device tree months after the hardware ships to the
>> >public
>> >> -- of course the hardware is more stable at that point.
>> >
>> >I mean, it's not black and white either. One could very well send
>the
>> >DT
>> >once the final design is done and that would still be upstreamed way
>> >before reaching the first user.
>> >
>> >> I think Pine's behavior is something we want to encourage, not
>> >> penalize.
>> >
>> >For the DT in particular, yes
>> >
>> >> > Okay. But I'm not satisfied with a non-public sample occupies
>> >> > the pinetab name. Is rename it to pinetab-dev and add a
>> >> > pinetab-retail okay?
>> >>
>> >> To me, naming the production version anything but "pinetab" isn't
>> >> satisfying either.
>> >
>> >I understand where you're coming from, but the point I was making my
>> >previous mail is precisely that it's not really possible.
>> >
>> >You want to name the early adopter version _the_ production version.
>> >Let's assume the hardware changes again between the early adopter
>and
>> >mass-production version. Which one will be _the_ production version?
>> >The
>> >early-adopter or the mass-produced one?
>> >
>> >There's really no good answer here, and both would suck in their own
>> >way. The only way to deal with this is to simply avoid defining one
>> >version as the one true board, and just loading the proper DT in
>u-boot
>> >based on whatever clue we have of the hardware revision.
>> 
>> Then will it be okay to rename current pinetab DT to pinetab-sample
>and
>> then introduce new DTs all with suffixes?
>
>No. From my previous mail:

It can be seen as dropping the PineTab DT and introduce new DTs with suffix.

Do we have rule that we cannot drop boards?

>
>> > there's two hard rules: never change the DT name and never change
>> > the compatible of a board.
>> >
>> > The former would break any build system, boot script or
>> > documentation, and the latter would break the DT compatibility.
>
>Maxime

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Maxime Ripard]

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

On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
> >> >> > Okay. But I'm not satisfied with a non-public sample occupies
> >> >> > the pinetab name. Is rename it to pinetab-dev and add a
> >> >> > pinetab-retail okay?
> >> >>
> >> >> To me, naming the production version anything but "pinetab" isn't
> >> >> satisfying either.
> >> >
> >> >I understand where you're coming from, but the point I was making my
> >> >previous mail is precisely that it's not really possible.
> >> >
> >> >You want to name the early adopter version _the_ production
> >> >version. Let's assume the hardware changes again between the early
> >> >adopter and mass-production version. Which one will be _the_
> >> >production version? The early-adopter or the mass-produced one?
> >> >
> >> >There's really no good answer here, and both would suck in their
> >> >own way. The only way to deal with this is to simply avoid
> >> >defining one version as the one true board, and just loading the
> >> >proper DT in u-boot based on whatever clue we have of the hardware
> >> >revision.
> >
> > > Then will it be okay to rename current pinetab DT to
> > > pinetab-sample and then introduce new DTs all with suffixes?
> >
> > No. From my previous mail:
> 
> It can be seen as dropping the PineTab DT and introduce new DTs with
> suffix.
> 
> Do we have rule that we cannot drop boards?

Are you really arguing that removing a DT and then adding an identical
one under a different name is not renaming it?

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

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Icenowy Zheng]

在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道：
> On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
> > > > > > > Okay. But I'm not satisfied with a non-public sample
> > > > > > > occupies
> > > > > > > the pinetab name. Is rename it to pinetab-dev and add a
> > > > > > > pinetab-retail okay?
> > > > > > 
> > > > > > To me, naming the production version anything but "pinetab"
> > > > > > isn't
> > > > > > satisfying either.
> > > > > 
> > > > > I understand where you're coming from, but the point I was
> > > > > making my
> > > > > previous mail is precisely that it's not really possible.
> > > > > 
> > > > > You want to name the early adopter version _the_ production
> > > > > version. Let's assume the hardware changes again between the
> > > > > early
> > > > > adopter and mass-production version. Which one will be _the_
> > > > > production version? The early-adopter or the mass-produced
> > > > > one?
> > > > > 
> > > > > There's really no good answer here, and both would suck in
> > > > > their
> > > > > own way. The only way to deal with this is to simply avoid
> > > > > defining one version as the one true board, and just loading
> > > > > the
> > > > > proper DT in u-boot based on whatever clue we have of the
> > > > > hardware
> > > > > revision.
> > > > Then will it be okay to rename current pinetab DT to
> > > > pinetab-sample and then introduce new DTs all with suffixes?
> > > 
> > > No. From my previous mail:
> > 
> > It can be seen as dropping the PineTab DT and introduce new DTs
> > with
> > suffix.
> > 
> > Do we have rule that we cannot drop boards?
> 
> Are you really arguing that removing a DT and then adding an
> identical
> one under a different name is not renaming it?

Then we can just keep confusing name?

If we do so, how can we mark the new DT as "the user should use this
one"?

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Clément Péron]

Hi Icenowy,

On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng <icenowy@aosc.io> wrote:
>
> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道：
> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
> > > > > > > > Okay. But I'm not satisfied with a non-public sample
> > > > > > > > occupies
> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a
> > > > > > > > pinetab-retail okay?
> > > > > > >
> > > > > > > To me, naming the production version anything but "pinetab"
> > > > > > > isn't
> > > > > > > satisfying either.
> > > > > >
> > > > > > I understand where you're coming from, but the point I was
> > > > > > making my
> > > > > > previous mail is precisely that it's not really possible.
> > > > > >
> > > > > > You want to name the early adopter version _the_ production
> > > > > > version. Let's assume the hardware changes again between the
> > > > > > early
> > > > > > adopter and mass-production version. Which one will be _the_
> > > > > > production version? The early-adopter or the mass-produced
> > > > > > one?
> > > > > >
> > > > > > There's really no good answer here, and both would suck in
> > > > > > their
> > > > > > own way. The only way to deal with this is to simply avoid
> > > > > > defining one version as the one true board, and just loading
> > > > > > the
> > > > > > proper DT in u-boot based on whatever clue we have of the
> > > > > > hardware
> > > > > > revision.
> > > > > Then will it be okay to rename current pinetab DT to
> > > > > pinetab-sample and then introduce new DTs all with suffixes?
> > > >
> > > > No. From my previous mail:
> > >
> > > It can be seen as dropping the PineTab DT and introduce new DTs
> > > with
> > > suffix.
> > >
> > > Do we have rule that we cannot drop boards?
> >
> > Are you really arguing that removing a DT and then adding an
> > identical
> > one under a different name is not renaming it?
>
> Then we can just keep confusing name?

Sorry maybe I missed some information
But why don't you do like pinephone?
sun50i-a64-pinetab-1.0.dts
sun50i-a64-pinetab-1.1.dts

-dev is also a confusing name I think, as the board has been already shipped.

Regards,
Clement


>
> If we do so, how can we mark the new DT as "the user should use this
> one"?
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io.

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Icenowy Zheng]

于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" <peron.clem@gmail.com> 写到:
>Hi Icenowy,
>
>On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng <icenowy@aosc.io> wrote:
>>
>> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道：
>> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
>> > > > > > > > Okay. But I'm not satisfied with a non-public sample
>> > > > > > > > occupies
>> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a
>> > > > > > > > pinetab-retail okay?
>> > > > > > >
>> > > > > > > To me, naming the production version anything but
>"pinetab"
>> > > > > > > isn't
>> > > > > > > satisfying either.
>> > > > > >
>> > > > > > I understand where you're coming from, but the point I was
>> > > > > > making my
>> > > > > > previous mail is precisely that it's not really possible.
>> > > > > >
>> > > > > > You want to name the early adopter version _the_ production
>> > > > > > version. Let's assume the hardware changes again between
>the
>> > > > > > early
>> > > > > > adopter and mass-production version. Which one will be
>_the_
>> > > > > > production version? The early-adopter or the mass-produced
>> > > > > > one?
>> > > > > >
>> > > > > > There's really no good answer here, and both would suck in
>> > > > > > their
>> > > > > > own way. The only way to deal with this is to simply avoid
>> > > > > > defining one version as the one true board, and just
>loading
>> > > > > > the
>> > > > > > proper DT in u-boot based on whatever clue we have of the
>> > > > > > hardware
>> > > > > > revision.
>> > > > > Then will it be okay to rename current pinetab DT to
>> > > > > pinetab-sample and then introduce new DTs all with suffixes?
>> > > >
>> > > > No. From my previous mail:
>> > >
>> > > It can be seen as dropping the PineTab DT and introduce new DTs
>> > > with
>> > > suffix.
>> > >
>> > > Do we have rule that we cannot drop boards?
>> >
>> > Are you really arguing that removing a DT and then adding an
>> > identical
>> > one under a different name is not renaming it?
>>
>> Then we can just keep confusing name?
>
>Sorry maybe I missed some information
>But why don't you do like pinephone?

They're the same board revision with different LCD panels.

And the major problem is that the DT for samples is already submitted
under the name "PineTab".

>sun50i-a64-pinetab-1.0.dts
>sun50i-a64-pinetab-1.1.dts
>
>-dev is also a confusing name I think, as the board has been already
>shipped.
>
>Regards,
>Clement
>
>
>>
>> If we do so, how can we mark the new DT as "the user should use this
>> one"?
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> To view this discussion on the web, visit
>https://groups.google.com/d/msgid/linux-sunxi/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io.

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Clément Péron]

Hi Maxime, Icenowy,

On Sat, 28 Nov 2020 at 12:59, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
>
> 于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" <peron.clem@gmail.com> 写到:
> >Hi Icenowy,
> >
> >On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng <icenowy@aosc.io> wrote:
> >>
> >> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道：
> >> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
> >> > > > > > > > Okay. But I'm not satisfied with a non-public sample
> >> > > > > > > > occupies
> >> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a
> >> > > > > > > > pinetab-retail okay?
> >> > > > > > >
> >> > > > > > > To me, naming the production version anything but
> >"pinetab"
> >> > > > > > > isn't
> >> > > > > > > satisfying either.
> >> > > > > >
> >> > > > > > I understand where you're coming from, but the point I was
> >> > > > > > making my
> >> > > > > > previous mail is precisely that it's not really possible.
> >> > > > > >
> >> > > > > > You want to name the early adopter version _the_ production
> >> > > > > > version. Let's assume the hardware changes again between
> >the
> >> > > > > > early
> >> > > > > > adopter and mass-production version. Which one will be
> >_the_
> >> > > > > > production version? The early-adopter or the mass-produced
> >> > > > > > one?
> >> > > > > >
> >> > > > > > There's really no good answer here, and both would suck in
> >> > > > > > their
> >> > > > > > own way. The only way to deal with this is to simply avoid
> >> > > > > > defining one version as the one true board, and just
> >loading
> >> > > > > > the
> >> > > > > > proper DT in u-boot based on whatever clue we have of the
> >> > > > > > hardware
> >> > > > > > revision.
> >> > > > > Then will it be okay to rename current pinetab DT to
> >> > > > > pinetab-sample and then introduce new DTs all with suffixes?
> >> > > >
> >> > > > No. From my previous mail:
> >> > >
> >> > > It can be seen as dropping the PineTab DT and introduce new DTs
> >> > > with
> >> > > suffix.
> >> > >
> >> > > Do we have rule that we cannot drop boards?
> >> >
> >> > Are you really arguing that removing a DT and then adding an
> >> > identical
> >> > one under a different name is not renaming it?
> >>
> >> Then we can just keep confusing name?
> >
> >Sorry maybe I missed some information
> >But why don't you do like pinephone?
>
> They're the same board revision with different LCD panels.

I just ask Pine64 about this and here is the reply :
"The PineTab LCD panel change was a last minutes before production
starts that vendor advise us switch over to new LCD controller due to
EoL concern".

"Pine64 communication" is not so bad we just need to ask and they reply :)

So the issue is not that the Product was not finalized but that one
component arrives in EoL.
This could also happens during a running production.

Regards,
Clement

>
> And the major problem is that the DT for samples is already submitted
> under the name "PineTab".
>
> >sun50i-a64-pinetab-1.0.dts
> >sun50i-a64-pinetab-1.1.dts
> >
> >-dev is also a confusing name I think, as the board has been already
> >shipped.
> >
> >Regards,
> >Clement
> >
> >
> >>
> >> If we do so, how can we mark the new DT as "the user should use this
> >> one"?
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >Groups "linux-sunxi" group.
> >> To unsubscribe from this group and stop receiving emails from it,
> >send an email to linux-sunxi+unsubscribe@googlegroups.com.
> >> To view this discussion on the web, visit
> >https://groups.google.com/d/msgid/linux-sunxi/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io.

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Maxime Ripard]

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

On Sat, Nov 28, 2020 at 10:07:27PM +0100, Clément Péron wrote:
> Hi Maxime, Icenowy,
> 
> On Sat, 28 Nov 2020 at 12:59, Icenowy Zheng <icenowy@aosc.io> wrote:
> >
> >
> >
> > 于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" <peron.clem@gmail.com> 写到:
> > >Hi Icenowy,
> > >
> > >On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng <icenowy@aosc.io> wrote:
> > >>
> > >> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道：
> > >> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
> > >> > > > > > > > Okay. But I'm not satisfied with a non-public sample
> > >> > > > > > > > occupies
> > >> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a
> > >> > > > > > > > pinetab-retail okay?
> > >> > > > > > >
> > >> > > > > > > To me, naming the production version anything but
> > >"pinetab"
> > >> > > > > > > isn't
> > >> > > > > > > satisfying either.
> > >> > > > > >
> > >> > > > > > I understand where you're coming from, but the point I was
> > >> > > > > > making my
> > >> > > > > > previous mail is precisely that it's not really possible.
> > >> > > > > >
> > >> > > > > > You want to name the early adopter version _the_ production
> > >> > > > > > version. Let's assume the hardware changes again between
> > >the
> > >> > > > > > early
> > >> > > > > > adopter and mass-production version. Which one will be
> > >_the_
> > >> > > > > > production version? The early-adopter or the mass-produced
> > >> > > > > > one?
> > >> > > > > >
> > >> > > > > > There's really no good answer here, and both would suck in
> > >> > > > > > their
> > >> > > > > > own way. The only way to deal with this is to simply avoid
> > >> > > > > > defining one version as the one true board, and just
> > >loading
> > >> > > > > > the
> > >> > > > > > proper DT in u-boot based on whatever clue we have of the
> > >> > > > > > hardware
> > >> > > > > > revision.
> > >> > > > > Then will it be okay to rename current pinetab DT to
> > >> > > > > pinetab-sample and then introduce new DTs all with suffixes?
> > >> > > >
> > >> > > > No. From my previous mail:
> > >> > >
> > >> > > It can be seen as dropping the PineTab DT and introduce new DTs
> > >> > > with
> > >> > > suffix.
> > >> > >
> > >> > > Do we have rule that we cannot drop boards?
> > >> >
> > >> > Are you really arguing that removing a DT and then adding an
> > >> > identical
> > >> > one under a different name is not renaming it?
> > >>
> > >> Then we can just keep confusing name?
> > >
> > >Sorry maybe I missed some information
> > >But why don't you do like pinephone?
> >
> > They're the same board revision with different LCD panels.
> 
> I just ask Pine64 about this and here is the reply :
> "The PineTab LCD panel change was a last minutes before production
> starts that vendor advise us switch over to new LCD controller due to
> EoL concern".
> 
> "Pine64 communication" is not so bad we just need to ask and they reply :)
> 
> So the issue is not that the Product was not finalized but that one
> component arrives in EoL.
> This could also happens during a running production.

Like you said, it can happen pretty much any time, for any reason, so
the intent doesn't really matter here.

Maxime

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

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Clément Péron]

Hi Maxime

On Tue, 1 Dec 2020 at 11:35, Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Sat, Nov 28, 2020 at 10:07:27PM +0100, Clément Péron wrote:
> > Hi Maxime, Icenowy,
> >
> > On Sat, 28 Nov 2020 at 12:59, Icenowy Zheng <icenowy@aosc.io> wrote:
> > >
> > >
> > >
> > > 于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" <peron.clem@gmail.com> 写到:
> > > >Hi Icenowy,
> > > >
> > > >On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng <icenowy@aosc.io> wrote:
> > > >>
> > > >> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道：
> > > >> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
> > > >> > > > > > > > Okay. But I'm not satisfied with a non-public sample
> > > >> > > > > > > > occupies
> > > >> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a
> > > >> > > > > > > > pinetab-retail okay?
> > > >> > > > > > >
> > > >> > > > > > > To me, naming the production version anything but
> > > >"pinetab"
> > > >> > > > > > > isn't
> > > >> > > > > > > satisfying either.
> > > >> > > > > >
> > > >> > > > > > I understand where you're coming from, but the point I was
> > > >> > > > > > making my
> > > >> > > > > > previous mail is precisely that it's not really possible.
> > > >> > > > > >
> > > >> > > > > > You want to name the early adopter version _the_ production
> > > >> > > > > > version. Let's assume the hardware changes again between
> > > >the
> > > >> > > > > > early
> > > >> > > > > > adopter and mass-production version. Which one will be
> > > >_the_
> > > >> > > > > > production version? The early-adopter or the mass-produced
> > > >> > > > > > one?
> > > >> > > > > >
> > > >> > > > > > There's really no good answer here, and both would suck in
> > > >> > > > > > their
> > > >> > > > > > own way. The only way to deal with this is to simply avoid
> > > >> > > > > > defining one version as the one true board, and just
> > > >loading
> > > >> > > > > > the
> > > >> > > > > > proper DT in u-boot based on whatever clue we have of the
> > > >> > > > > > hardware
> > > >> > > > > > revision.
> > > >> > > > > Then will it be okay to rename current pinetab DT to
> > > >> > > > > pinetab-sample and then introduce new DTs all with suffixes?
> > > >> > > >
> > > >> > > > No. From my previous mail:
> > > >> > >
> > > >> > > It can be seen as dropping the PineTab DT and introduce new DTs
> > > >> > > with
> > > >> > > suffix.
> > > >> > >
> > > >> > > Do we have rule that we cannot drop boards?
> > > >> >
> > > >> > Are you really arguing that removing a DT and then adding an
> > > >> > identical
> > > >> > one under a different name is not renaming it?
> > > >>
> > > >> Then we can just keep confusing name?
> > > >
> > > >Sorry maybe I missed some information
> > > >But why don't you do like pinephone?
> > >
> > > They're the same board revision with different LCD panels.
> >
> > I just ask Pine64 about this and here is the reply :
> > "The PineTab LCD panel change was a last minutes before production
> > starts that vendor advise us switch over to new LCD controller due to
> > EoL concern".
> >
> > "Pine64 communication" is not so bad we just need to ask and they reply :)
> >
> > So the issue is not that the Product was not finalized but that one
> > component arrives in EoL.
> > This could also happens during a running production.
>
> Like you said, it can happen pretty much any time, for any reason, so
> the intent doesn't really matter here.

Agree, that was more to support Pin64 guys here.

As pinetab compatible can't be reused maybe somethings like this :
sun50i-a64-pinetab.dtsi
sun50i-a64-pinetab-1.0-early-adopter.dtb
sun50i-a64-pinetab-1.0.dtb or sun50i-a64-pinetab-retail.dtb. But
retail is like prod it's not explicit.

What do you think ?

Clement

>
> Maxime

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

[Maxime Ripard]

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

On Sun, Dec 06, 2020 at 10:03:16PM +0100, Clément Péron wrote:
> Hi Maxime
> 
> On Tue, 1 Dec 2020 at 11:35, Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > On Sat, Nov 28, 2020 at 10:07:27PM +0100, Clément Péron wrote:
> > > Hi Maxime, Icenowy,
> > >
> > > On Sat, 28 Nov 2020 at 12:59, Icenowy Zheng <icenowy@aosc.io> wrote:
> > > >
> > > >
> > > >
> > > > 于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" <peron.clem@gmail.com> 写到:
> > > > >Hi Icenowy,
> > > > >
> > > > >On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng <icenowy@aosc.io> wrote:
> > > > >>
> > > > >> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道：
> > > > >> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
> > > > >> > > > > > > > Okay. But I'm not satisfied with a non-public sample
> > > > >> > > > > > > > occupies
> > > > >> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a
> > > > >> > > > > > > > pinetab-retail okay?
> > > > >> > > > > > >
> > > > >> > > > > > > To me, naming the production version anything but
> > > > >"pinetab"
> > > > >> > > > > > > isn't
> > > > >> > > > > > > satisfying either.
> > > > >> > > > > >
> > > > >> > > > > > I understand where you're coming from, but the point I was
> > > > >> > > > > > making my
> > > > >> > > > > > previous mail is precisely that it's not really possible.
> > > > >> > > > > >
> > > > >> > > > > > You want to name the early adopter version _the_ production
> > > > >> > > > > > version. Let's assume the hardware changes again between
> > > > >the
> > > > >> > > > > > early
> > > > >> > > > > > adopter and mass-production version. Which one will be
> > > > >_the_
> > > > >> > > > > > production version? The early-adopter or the mass-produced
> > > > >> > > > > > one?
> > > > >> > > > > >
> > > > >> > > > > > There's really no good answer here, and both would suck in
> > > > >> > > > > > their
> > > > >> > > > > > own way. The only way to deal with this is to simply avoid
> > > > >> > > > > > defining one version as the one true board, and just
> > > > >loading
> > > > >> > > > > > the
> > > > >> > > > > > proper DT in u-boot based on whatever clue we have of the
> > > > >> > > > > > hardware
> > > > >> > > > > > revision.
> > > > >> > > > > Then will it be okay to rename current pinetab DT to
> > > > >> > > > > pinetab-sample and then introduce new DTs all with suffixes?
> > > > >> > > >
> > > > >> > > > No. From my previous mail:
> > > > >> > >
> > > > >> > > It can be seen as dropping the PineTab DT and introduce new DTs
> > > > >> > > with
> > > > >> > > suffix.
> > > > >> > >
> > > > >> > > Do we have rule that we cannot drop boards?
> > > > >> >
> > > > >> > Are you really arguing that removing a DT and then adding an
> > > > >> > identical
> > > > >> > one under a different name is not renaming it?
> > > > >>
> > > > >> Then we can just keep confusing name?
> > > > >
> > > > >Sorry maybe I missed some information
> > > > >But why don't you do like pinephone?
> > > >
> > > > They're the same board revision with different LCD panels.
> > >
> > > I just ask Pine64 about this and here is the reply :
> > > "The PineTab LCD panel change was a last minutes before production
> > > starts that vendor advise us switch over to new LCD controller due to
> > > EoL concern".
> > >
> > > "Pine64 communication" is not so bad we just need to ask and they reply :)
> > >
> > > So the issue is not that the Product was not finalized but that one
> > > component arrives in EoL.
> > > This could also happens during a running production.
> >
> > Like you said, it can happen pretty much any time, for any reason, so
> > the intent doesn't really matter here.
> 
> Agree, that was more to support Pin64 guys here.
> 
> As pinetab compatible can't be reused maybe somethings like this :
> sun50i-a64-pinetab.dtsi
> sun50i-a64-pinetab-1.0-early-adopter.dtb
> sun50i-a64-pinetab-1.0.dtb or sun50i-a64-pinetab-retail.dtb. But
> retail is like prod it's not explicit.
> 
> What do you think ?

I already said what I think multiple times in this thread: the DT that
has been merged for the early adopter, devs, whatever, won't be renamed.
As far as I'm concerned, I don't care about the name that is picked for
the new version as long as everyone is clear on the fact that that name
won't change ever either.

Maxime

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