[PATCH v2 0/3] Google Pixel 6 Pro support

[PATCH v2 0/3] Google Pixel 6 Pro support

[André Draszik]

Hi,

This series enables support for Google Pixel 6 Pro.

Since Pixel 6 and Pixel 6 Pro use a different resolution display, we
now need to add explicit support for it, we can not piggyback on the
non-Pro version anymore. This means having to separate them into their
respective DTs, and provide one for each of them.
There are other differences between the two of course, like battery
design capacity, etc., but they don't matter at this stage due to
incomplete upstream support.

* dependency note *

Due to the renaming of the gs101-oriole.dts, this series will conflict
with any pending patches touching the same file. I have therefore based
this series on top of my USB series from
https://lore.kernel.org/r/20241203-gs101-phy-lanes-orientation-dts-v2-0-1412783a6b01@linaro.org
and the patch enabling framebuffer support for Pixel 6 from
https://lore.kernel.org/r/20241220-gs101-simplefb-oriole-v2-1-df60e566932a@linaro.org

* dependency note end *

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
Changes in v2:
- We now have a generic gs101-based Pixel board DT, which can work on
  any Pixel 6 / 6 Pro / 6a
- Pixel 6 (Pro) are overlays onto that one.
  This has the advantage that all boards can be supported without
  having to have a full copy of the DT for each of them. We still
  instruct kbuild to create merged DTBs (in addition to the DTBOs) so
  that existing scripts can keep working while giving the option to
  just apply the overlay before boot (e.g. by the bootloader).
- The binding has been updated according to the above points
- I've changed the simple-framebuffer node to specify the memory via
  memory-region instead of reg, as that avoids unnecessary duplication
  (of the size), and it avoids having to specify #address-cells
  and #size-cells in the chosen node (and duplicating this in the
  DTSO), which is otherwise necessary to keep dt_binding_check happy
  and DT validation working in general.
- sort overriding/extending nodes ordered by label name (Krzysztof)
- format patches with diff.renames=copies (Krzysztof)
- dependencies have been updated, see below
- Link to v1: https://lore.kernel.org/r/20241216-gs101-simplefb-v1-0-8ccad1830281@linaro.org

---
André Draszik (3):
      dt-bindings: arm: google: add gs101-raven and generic gs101-pixel
      arm64: dts: exynos: gs101-pixel: add generic gs101-based Pixel support
      arm64: dts: exynos: gs101-raven: add new board file

 Documentation/devicetree/bindings/arm/google.yaml  | 18 +++++++++---
 arch/arm64/boot/dts/exynos/google/Makefile         |  9 ++++--
 .../arm64/boot/dts/exynos/google/gs101-oriole.dtso | 33 ++++++++++++++++++++++
 .../{gs101-oriole.dts => gs101-pixel-generic.dts}  | 24 +++++++---------
 arch/arm64/boot/dts/exynos/google/gs101-raven.dtso | 33 ++++++++++++++++++++++
 5 files changed, 97 insertions(+), 20 deletions(-)
---
base-commit: f70ddfc479f2fac1d0b744148743c25ce1778f01
change-id: 20241216-gs101-simplefb-8aae80278ed7

Best regards,
-- 
André Draszik <andre.draszik@linaro.org>

[PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel

[André Draszik]

Raven is Google's code name for Pixel 6 Pro. Since there are
differences compared to Pixel 6 (Oriole), we need to add a separate
compatible for it.

We also want to support a generic DT, which can work on any type of
gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as
a future addition). Such a DT will have certain nodes disabled / not
added. To facilitate such a generic gs101-based Pixel device, also add
a more generic gs101-pixel compatible. We can not just use the existing
google,gs101 for that, as it refers to the SoC, not a board.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
 Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
index e20b5c9b16bc..a8faf2256242 100644
--- a/Documentation/devicetree/bindings/arm/google.yaml
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -34,11 +34,21 @@ properties:
     const: '/'
   compatible:
     oneOf:
-      - description: Google Pixel 6 / Oriole
+      - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6
+          (Oriole), or 6 Pro (Raven)
+        minItems: 2
+        maxItems: 3
         items:
-          - enum:
-              - google,gs101-oriole
-          - const: google,gs101
+          enum:
+            - google,gs101-oriole
+            - google,gs101-raven
+            - google,gs101-pixel
+            - google,gs101
+        allOf:
+          - contains:
+              const: google,gs101-pixel
+          - contains:
+              const: google,gs101
 
   # Bootloader requires empty ect node to be present
   ect:

-- 
2.47.1.613.gc27f4b7a9f-goog

[PATCH v2 2/3] arm64: dts: exynos: gs101-pixel: add generic gs101-based Pixel support

[André Draszik]

In order to support Pixel 6 (Oriole), Pixel 6 Pro (Raven), and Pixel 6a
(Bluejay) correctly, we have to be able to distinguish them properly as
we add support for more features.

For example, Raven has a larger display. There are other differences,
like battery design capacity, etc.

To facilitate this, we create a generic gs101-based Pixel DT that can
work on any such gs101-based device. At the same time, we move the
Oriole specific parts that we have at the moment (display) into an
overlay, making it easy to add support for Raven and Bluejay in a
similar way.

Note1:
Despite being an overlay, we instruct kbuild to create a merged
gs101-oriole.dtb and a gs101-oriole.dtbo. This way existing scripts can
keep working, but it also gives the option to just apply the overlay
before boot (e.g. by the bootloader).

Note2:
I've changed the simple-framebuffer node to specify the memory via
memory-region instead of reg, as that avoids unnecessary duplication
(of the size), and it avoids having to specify #address-cells
and #size-cells in the chosen node (and duplicating this in the DTSO),
which is otherwise necessary to keep dt_binding_check happy and DT
validation working in general.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
Note: MAINTAINERS doesn't need updating, it covers this whole directory
---
 arch/arm64/boot/dts/exynos/google/Makefile         |  6 ++--
 .../arm64/boot/dts/exynos/google/gs101-oriole.dtso | 33 ++++++++++++++++++++++
 .../{gs101-oriole.dts => gs101-pixel-generic.dts}  | 24 +++++++---------
 3 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
index 0a6d5e1fe4ee..6e6b5319212a 100644
--- a/arch/arm64/boot/dts/exynos/google/Makefile
+++ b/arch/arm64/boot/dts/exynos/google/Makefile
@@ -1,4 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
-dtb-$(CONFIG_ARCH_EXYNOS) += \
-	gs101-oriole.dtb \
+dtb-$(CONFIG_ARCH_EXYNOS) += gs101-pixel-generic.dtb
+
+gs101-oriole-dtbs := gs101-pixel-generic.dtb gs101-oriole.dtbo
+dtb-$(CONFIG_ARCH_EXYNOS) += gs101-oriole.dtb
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso
new file mode 100644
index 000000000000..43572039cd07
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Oriole Device Tree
+ *
+ * Copyright 2021-2023 Google LLC
+ * Copyright 2023-2024 Linaro Ltd
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+	model = "Oriole";
+	compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101";
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <1>;
+
+		splash@fac00000 {
+			reg = <0x0 0xfac00000 (1080 * 2400 * 4)>;
+			status = "okay";
+		};
+	};
+};
+
+&framebuffer0 {
+	width = <1080>;
+	height = <2400>;
+	stride = <(1080 * 4)>;
+	format = "a8r8g8b8";
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-pixel-generic.dts
similarity index 93%
rename from arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
rename to arch/arm64/boot/dts/exynos/google/gs101-pixel-generic.dts
index 4e1625e3fbb4..48dc37afcb86 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
+++ b/arch/arm64/boot/dts/exynos/google/gs101-pixel-generic.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * Oriole Device Tree
+ * generic gs101-based Pixel Device Tree
  *
  * Copyright 2021-2023 Google LLC
  * Copyright 2023 Linaro Ltd - <peter.griffin@linaro.org>
@@ -15,30 +15,24 @@
 #include "gs101.dtsi"
 
 / {
-	model = "Oriole";
-	compatible = "google,gs101-oriole", "google,gs101";
+	model = "GS101-based Pixel or derivative";
+	compatible = "google,gs101-pixel", "google,gs101";
 
 	aliases {
 		serial0 = &serial_0;
 	};
 
 	chosen {
-		#address-cells = <2>;
-		#size-cells = <1>;
-		ranges;
-
 		/* Bootloader expects bootargs specified otherwise it crashes */
 		bootargs = "";
 		stdout-path = &serial_0;
 
 		/* Use display framebuffer as setup by bootloader */
-		framebuffer0: framebuffer@fac00000 {
+		framebuffer0: framebuffer-0 {
 			compatible = "simple-framebuffer";
-			reg = <0x0 0xfac00000 (1080 * 2400 * 4)>;
-			width = <1080>;
-			height = <2400>;
-			stride = <(1080 * 4)>;
-			format = "a8r8g8b8";
+			memory-region = <&cont_splash_mem>;
+			/* format properties to be added by board overlay */
+			status = "disabled";
 		};
 	};
 
@@ -86,8 +80,10 @@ ufs_0_fixed_vcc_reg: regulator-1 {
 
 	reserved-memory {
 		cont_splash_mem: splash@fac00000 {
-			reg = <0x0 0xfac00000 (1080 * 2400 * 4)>;
+			/* size to be updated by board overlay */
+			reg = <0x0 0xfac00000 0x0>;
 			no-map;
+			status = "disabled";
 		};
 	};
 };

-- 
2.47.1.613.gc27f4b7a9f-goog

[PATCH v2 3/3] arm64: dts: exynos: gs101-raven: add new board file

[André Draszik]

Raven is Google's code name for Pixel 6 Pro. Similar to Pixel 6
(Oriole), this is also based around its Tensor gs101 SoC.

For now, the relevant difference here is the display resolution:
1440 x 3120 instead of 1080 x 2400.

Create a new board file to reflect this difference.

Signed-off-by: André Draszik <andre.draszik@linaro.org>

---
Note: MAINTAINERS doesn't need updating, it covers this whole directory
---
 arch/arm64/boot/dts/exynos/google/Makefile         |  3 ++
 arch/arm64/boot/dts/exynos/google/gs101-raven.dtso | 33 ++++++++++++++++++++++
 2 files changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
index 6e6b5319212a..bc6d600fda84 100644
--- a/arch/arm64/boot/dts/exynos/google/Makefile
+++ b/arch/arm64/boot/dts/exynos/google/Makefile
@@ -4,3 +4,6 @@ dtb-$(CONFIG_ARCH_EXYNOS) += gs101-pixel-generic.dtb
 
 gs101-oriole-dtbs := gs101-pixel-generic.dtb gs101-oriole.dtbo
 dtb-$(CONFIG_ARCH_EXYNOS) += gs101-oriole.dtb
+
+gs101-raven-dtbs := gs101-pixel-generic.dtb gs101-raven.dtbo
+dtb-$(CONFIG_ARCH_EXYNOS) += gs101-raven.dtb
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-raven.dtso b/arch/arm64/boot/dts/exynos/google/gs101-raven.dtso
new file mode 100644
index 000000000000..577f52a4fdad
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-raven.dtso
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Raven Device Tree
+ *
+ * Copyright 2021-2023 Google LLC
+ * Copyright 2023-2024 Linaro Ltd
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+	model = "Raven";
+	compatible = "google,gs101-raven", "google,gs101-pixel", "google,gs101";
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <1>;
+
+		splash@fac00000 {
+			reg = <0x0 0xfac00000 (1440 * 3120 * 4)>;
+			status = "okay";
+		};
+	};
+};
+
+&framebuffer0 {
+	width = <1440>;
+	height = <3120>;
+	stride = <(1440 * 4)>;
+	format = "a8r8g8b8";
+	status = "okay";
+};

-- 
2.47.1.613.gc27f4b7a9f-goog

Re: [PATCH v2 0/3] Google Pixel 6 Pro support

[André Draszik]

On Fri, 2024-12-20 at 11:27 +0000, André Draszik wrote:
> Hi,
> 
> This series enables support for Google Pixel 6 Pro.
> 
> Since Pixel 6 and Pixel 6 Pro use a different resolution display, we
> now need to add explicit support for it, we can not piggyback on the
> non-Pro version anymore. This means having to separate them into their
> respective DTs, and provide one for each of them.
> There are other differences between the two of course, like battery
> design capacity, etc., but they don't matter at this stage due to
> incomplete upstream support.
> 
> * dependency note *
> 
> Due to the renaming of the gs101-oriole.dts, this series will conflict
> with any pending patches touching the same file. I have therefore based
> this series on top of my USB series from
> https://lore.kernel.org/r/20241203-gs101-phy-lanes-orientation-dts-v2-0-1412783a6b01@linaro.org
> and the patch enabling framebuffer support for Pixel 6 from
> https://lore.kernel.org/r/20241220-gs101-simplefb-oriole-v2-1-df60e566932a@linaro.org

Actually, since this series was regenerated with git's
diff.renames=copies, it doesn't depend on my USB series
anymore, just on the framebuffer enablement for Pixel 6.

Cheers,
Andre'

Re: [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel

[Krzysztof Kozlowski]

On 20/12/2024 12:27, André Draszik wrote:
> Raven is Google's code name for Pixel 6 Pro. Since there are
> differences compared to Pixel 6 (Oriole), we need to add a separate
> compatible for it.
> 
> We also want to support a generic DT, which can work on any type of

There are no such generic DT devices upstream, so we cannot add bindings
for them.

> gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as
> a future addition). Such a DT will have certain nodes disabled / not
> added. To facilitate such a generic gs101-based Pixel device, also add
> a more generic gs101-pixel compatible. We can not just use the existing
> google,gs101 for that, as it refers to the SoC, not a board.
> 
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
>  Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> index e20b5c9b16bc..a8faf2256242 100644
> --- a/Documentation/devicetree/bindings/arm/google.yaml
> +++ b/Documentation/devicetree/bindings/arm/google.yaml
> @@ -34,11 +34,21 @@ properties:
>      const: '/'
>    compatible:
>      oneOf:
> -      - description: Google Pixel 6 / Oriole
> +      - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6
> +          (Oriole), or 6 Pro (Raven)
> +        minItems: 2
> +        maxItems: 3
>          items:
> -          - enum:
> -              - google,gs101-oriole
> -          - const: google,gs101
> +          enum:
> +            - google,gs101-oriole
> +            - google,gs101-raven
> +            - google,gs101-pixel
> +            - google,gs101

SoC cannot be a board in the same time.

> +        allOf:
> +          - contains:
> +              const: google,gs101-pixel
> +          - contains:
> +              const: google,gs101

This should be fixed list.


Best regards,
Krzysztof

Re: [PATCH v2 2/3] arm64: dts: exynos: gs101-pixel: add generic gs101-based Pixel support

[Krzysztof Kozlowski]

On 20/12/2024 12:27, André Draszik wrote:
> In order to support Pixel 6 (Oriole), Pixel 6 Pro (Raven), and Pixel 6a
> (Bluejay) correctly, we have to be able to distinguish them properly as
> we add support for more features.
> 
> For example, Raven has a larger display. There are other differences,
> like battery design capacity, etc.
> 
> To facilitate this, we create a generic gs101-based Pixel DT that can
> work on any such gs101-based device. At the same time, we move the

No, whatever insanity Android has there, please don't populate it to
upstream.

There is no such thing as "generic board" thus cannot be a
"generic DTS".

> Oriole specific parts that we have at the moment (display) into an
> overlay, making it easy to add support for Raven and Bluejay in a
> similar way.
> 
> Note1:
> Despite being an overlay, we instruct kbuild to create a merged
> gs101-oriole.dtb and a gs101-oriole.dtbo. This way existing scripts can
> keep working, but it also gives the option to just apply the overlay
> before boot (e.g. by the bootloader).
> 
> Note2:
> I've changed the simple-framebuffer node to specify the memory via
> memory-region instead of reg, as that avoids unnecessary duplication
> (of the size), and it avoids having to specify #address-cells
> and #size-cells in the chosen node (and duplicating this in the DTSO),
> which is otherwise necessary to keep dt_binding_check happy and DT
> validation working in general.
> 
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
> Note: MAINTAINERS doesn't need updating, it covers this whole directory
> ---
>  arch/arm64/boot/dts/exynos/google/Makefile         |  6 ++--
>  .../arm64/boot/dts/exynos/google/gs101-oriole.dtso | 33 ++++++++++++++++++++++
>  .../{gs101-oriole.dts => gs101-pixel-generic.dts}  | 24 +++++++---------
>  3 files changed, 47 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
> index 0a6d5e1fe4ee..6e6b5319212a 100644
> --- a/arch/arm64/boot/dts/exynos/google/Makefile
> +++ b/arch/arm64/boot/dts/exynos/google/Makefile
> @@ -1,4 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
> -dtb-$(CONFIG_ARCH_EXYNOS) += \
> -	gs101-oriole.dtb \
> +dtb-$(CONFIG_ARCH_EXYNOS) += gs101-pixel-generic.dtb
> +
> +gs101-oriole-dtbs := gs101-pixel-generic.dtb gs101-oriole.dtbo
> +dtb-$(CONFIG_ARCH_EXYNOS) += gs101-oriole.dtb
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso
> new file mode 100644
> index 000000000000..43572039cd07
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Oriole Device Tree
> + *
> + * Copyright 2021-2023 Google LLC
> + * Copyright 2023-2024 Linaro Ltd
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&{/} {
> +	model = "Oriole";
> +	compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101";

Boards are not overlays. Board equals DTB.

> +
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <1>;
> +
> +		splash@fac00000 {
> +			reg = <0x0 0xfac00000 (1080 * 2400 * 4)>;
> +			status = "okay";
> +		};
> +	};
> +};
> +
> +&framebuffer0 {
> +	width = <1080>;
> +	height = <2400>;
> +	stride = <(1080 * 4)>;
> +	format = "a8r8g8b8";
> +	status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-pixel-generic.dts
> similarity index 93%
> rename from arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> rename to arch/arm64/boot/dts/exynos/google/gs101-pixel-generic.dts
> index 4e1625e3fbb4..48dc37afcb86 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-pixel-generic.dts
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
> - * Oriole Device Tree
> + * generic gs101-based Pixel Device Tree
>   *
>   * Copyright 2021-2023 Google LLC
>   * Copyright 2023 Linaro Ltd - <peter.griffin@linaro.org>
> @@ -15,30 +15,24 @@
>  #include "gs101.dtsi"
>  
>  / {
> -	model = "Oriole";
> -	compatible = "google,gs101-oriole", "google,gs101";
> +	model = "GS101-based Pixel or derivative";
> +	compatible = "google,gs101-pixel", "google,gs101";
>  
>  	aliases {
>  		serial0 = &serial_0;
>  	};
>  
>  	chosen {
> -		#address-cells = <2>;
> -		#size-cells = <1>;
> -		ranges;
> -
>  		/* Bootloader expects bootargs specified otherwise it crashes */
>  		bootargs = "";
>  		stdout-path = &serial_0;
>  
>  		/* Use display framebuffer as setup by bootloader */
> -		framebuffer0: framebuffer@fac00000 {

I don't think this exists in current source. It does exist in thing I
was applying, but then this does not make much sense: add a framebuffer
which has to be changed, because it is not correct.

I'll drop the framebuffer patch.



Best regards,
Krzysztof

Re: [PATCH v2 3/3] arm64: dts: exynos: gs101-raven: add new board file

[Krzysztof Kozlowski]

On 20/12/2024 12:27, André Draszik wrote:
> Raven is Google's code name for Pixel 6 Pro. Similar to Pixel 6
> (Oriole), this is also based around its Tensor gs101 SoC.
> 
> For now, the relevant difference here is the display resolution:
> 1440 x 3120 instead of 1080 x 2400.
> 
> Create a new board file to reflect this difference.

There is no board file here, I see only overlay.

> 
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> 
> ---
> Note: MAINTAINERS doesn't need updating, it covers this whole directory
> ---
>  arch/arm64/boot/dts/exynos/google/Makefile         |  3 ++
>  arch/arm64/boot/dts/exynos/google/gs101-raven.dtso | 33 ++++++++++++++++++++++

Nope, boards are not overlays. Boards are DTB.



Best regards,
Krzysztof

Re: [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel

[André Draszik]

Hi Krzysztof,

On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote:
> On 20/12/2024 12:27, André Draszik wrote:
> > Raven is Google's code name for Pixel 6 Pro. Since there are
> > differences compared to Pixel 6 (Oriole), we need to add a separate
> > compatible for it.
> > 
> > We also want to support a generic DT, which can work on any type of
> 
> There are no such generic DT devices upstream, so we cannot add bindings
> for them.

Do you have a better suggestion for the wording?
How about 'gs101-based Pixel base board'?

> > gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as
> > a future addition). Such a DT will have certain nodes disabled / not
> > added. To facilitate such a generic gs101-based Pixel device, also add
> > a more generic gs101-pixel compatible. We can not just use the existing
> > google,gs101 for that, as it refers to the SoC, not a board.
> > 
> > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++----
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> > index e20b5c9b16bc..a8faf2256242 100644
> > --- a/Documentation/devicetree/bindings/arm/google.yaml
> > +++ b/Documentation/devicetree/bindings/arm/google.yaml
> > @@ -34,11 +34,21 @@ properties:
> >      const: '/'
> >    compatible:
> >      oneOf:
> > -      - description: Google Pixel 6 / Oriole
> > +      - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6
> > +          (Oriole), or 6 Pro (Raven)
> > +        minItems: 2
> > +        maxItems: 3
> >          items:
> > -          - enum:
> > -              - google,gs101-oriole
> > -          - const: google,gs101
> > +          enum:
> > +            - google,gs101-oriole
> > +            - google,gs101-raven
> > +            - google,gs101-pixel
> > +            - google,gs101
> 
> SoC cannot be a board in the same time.

Can you please expand? google,gs101 is the SoC, the other ones are boards.
Is the commit message unclear?

> 
> > +        allOf:
> > +          - contains:
> > +              const: google,gs101-pixel
> > +          - contains:
> > +              const: google,gs101
> 
> This should be fixed list.

OK. (This was inspired by Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml)

Cheers,
Andre'

Re: [PATCH v2 2/3] arm64: dts: exynos: gs101-pixel: add generic gs101-based Pixel support

[André Draszik]

Hi Krzysztof,

On Sun, 2024-12-22 at 12:42 +0100, Krzysztof Kozlowski wrote:
> On 20/12/2024 12:27, André Draszik wrote:
> > In order to support Pixel 6 (Oriole), Pixel 6 Pro (Raven), and Pixel 6a
> > (Bluejay) correctly, we have to be able to distinguish them properly as
> > we add support for more features.
> > 
> > For example, Raven has a larger display. There are other differences,
> > like battery design capacity, etc.
> > 
> > To facilitate this, we create a generic gs101-based Pixel DT that can
> > work on any such gs101-based device. At the same time, we move the
> 
> No, whatever insanity Android has there, please don't populate it to
> upstream.
> 
> There is no such thing as "generic board" thus cannot be a
> "generic DTS".

I'll rephrase to gs101-based Pixel base board. Unless you have a better
suggestion.

> 
> > Oriole specific parts that we have at the moment (display) into an
> > overlay, making it easy to add support for Raven and Bluejay in a
> > similar way.
> > 
> > Note1:
> > Despite being an overlay, we instruct kbuild to create a merged
> > gs101-oriole.dtb and a gs101-oriole.dtbo. This way existing scripts can
> > keep working, but it also gives the option to just apply the overlay
> > before boot (e.g. by the bootloader).
> > 
> > Note2:
> > I've changed the simple-framebuffer node to specify the memory via
> > memory-region instead of reg, as that avoids unnecessary duplication
> > (of the size), and it avoids having to specify #address-cells
> > and #size-cells in the chosen node (and duplicating this in the DTSO),
> > which is otherwise necessary to keep dt_binding_check happy and DT
> > validation working in general.
> > 
> > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> > ---
> > Note: MAINTAINERS doesn't need updating, it covers this whole directory
> > ---
> >  arch/arm64/boot/dts/exynos/google/Makefile         |  6 ++--
> >  .../arm64/boot/dts/exynos/google/gs101-oriole.dtso | 33 ++++++++++++++++++++++
> >  .../{gs101-oriole.dts => gs101-pixel-generic.dts}  | 24 +++++++---------
> >  3 files changed, 47 insertions(+), 16 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
> > index 0a6d5e1fe4ee..6e6b5319212a 100644
> > --- a/arch/arm64/boot/dts/exynos/google/Makefile
> > +++ b/arch/arm64/boot/dts/exynos/google/Makefile
> > @@ -1,4 +1,6 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  
> > -dtb-$(CONFIG_ARCH_EXYNOS) += \
> > -	gs101-oriole.dtb \
> > +dtb-$(CONFIG_ARCH_EXYNOS) += gs101-pixel-generic.dtb
> > +
> > +gs101-oriole-dtbs := gs101-pixel-generic.dtb gs101-oriole.dtbo
> > +dtb-$(CONFIG_ARCH_EXYNOS) += gs101-oriole.dtb
> > diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso
> > new file mode 100644
> > index 000000000000..43572039cd07
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso
> > @@ -0,0 +1,33 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Oriole Device Tree
> > + *
> > + * Copyright 2021-2023 Google LLC
> > + * Copyright 2023-2024 Linaro Ltd
> > + */
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +
> > +&{/} {
> > +	model = "Oriole";
> > +	compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101";
> 
> Boards are not overlays. Board equals DTB.

You're saying this should move into a dts instead of dtso?
There are numerous boards upstream which use this same dtso
approach.

There is a base board, and also different versions of it,
oriole being one of them.

[...]

> > 	};
> >  
> >  	chosen {
> > -		#address-cells = <2>;
> > -		#size-cells = <1>;
> > -		ranges;
> > -
> >  		/* Bootloader expects bootargs specified otherwise it crashes */
> >  		bootargs = "";
> >  		stdout-path = &serial_0;
> >  
> >  		/* Use display framebuffer as setup by bootloader */
> > -		framebuffer0: framebuffer@fac00000 {
> 
> I don't think this exists in current source. It does exist in thing I
> was applying, but then this does not make much sense: add a framebuffer
> which has to be changed, because it is not correct.
> 
> I'll drop the framebuffer patch.

The framebuffer makes sense for the oriole version. I can fully remove this
node from this base board here, and just leave it in the versions.
That said, can you please expand how having a 'status=disabled' framebuffer
node is different from any other nodes that are enabled or modified by
overlays?

Cheers,
Andre'

Re: [PATCH v2 3/3] arm64: dts: exynos: gs101-raven: add new board file

[André Draszik]

On Sun, 2024-12-22 at 12:43 +0100, Krzysztof Kozlowski wrote:
> On 20/12/2024 12:27, André Draszik wrote:
> > Raven is Google's code name for Pixel 6 Pro. Similar to Pixel 6
> > (Oriole), this is also based around its Tensor gs101 SoC.
> > 
> > For now, the relevant difference here is the display resolution:
> > 1440 x 3120 instead of 1080 x 2400.
> > 
> > Create a new board file to reflect this difference.
> 
> There is no board file here, I see only overlay.
> 
> > 
> > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> > 
> > ---
> > Note: MAINTAINERS doesn't need updating, it covers this whole directory
> > ---
> >  arch/arm64/boot/dts/exynos/google/Makefile         |  3 ++
> >  arch/arm64/boot/dts/exynos/google/gs101-raven.dtso | 33 ++++++++++++++++++++++
> 
> Nope, boards are not overlays. Boards are DTB.

Several other boards are using this approach, e.g. in
arch/arm64/boot/dts/freescale/ and arch/arm64/boot/dts/xilinx/ and
arch/arm/boot/dts/ti/omap/

Can you please explain why this here can not use this approach?


Cheers,
Andre'

Re: [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel

[Krzysztof Kozlowski]

On 23/12/2024 08:45, André Draszik wrote:
> Hi Krzysztof,
> 
> On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote:
>> On 20/12/2024 12:27, André Draszik wrote:
>>> Raven is Google's code name for Pixel 6 Pro. Since there are
>>> differences compared to Pixel 6 (Oriole), we need to add a separate
>>> compatible for it.
>>>
>>> We also want to support a generic DT, which can work on any type of
>>
>> There are no such generic DT devices upstream, so we cannot add bindings
>> for them.
> 
> Do you have a better suggestion for the wording?
> How about 'gs101-based Pixel base board'?

It's not exactly about the wording but the concept. We don't have
generic devices, thus no generic DT (DTS). Period. Thus you cannot have
such schema.

> 
>>> gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as
>>> a future addition). Such a DT will have certain nodes disabled / not
>>> added. To facilitate such a generic gs101-based Pixel device, also add
>>> a more generic gs101-pixel compatible. We can not just use the existing
>>> google,gs101 for that, as it refers to the SoC, not a board.
>>>
>>> Signed-off-by: André Draszik <andre.draszik@linaro.org>
>>> ---
>>>  Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++----
>>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
>>> index e20b5c9b16bc..a8faf2256242 100644
>>> --- a/Documentation/devicetree/bindings/arm/google.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/google.yaml
>>> @@ -34,11 +34,21 @@ properties:
>>>      const: '/'
>>>    compatible:
>>>      oneOf:
>>> -      - description: Google Pixel 6 / Oriole
>>> +      - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6
>>> +          (Oriole), or 6 Pro (Raven)
>>> +        minItems: 2
>>> +        maxItems: 3
>>>          items:
>>> -          - enum:
>>> -              - google,gs101-oriole
>>> -          - const: google,gs101
>>> +          enum:
>>> +            - google,gs101-oriole
>>> +            - google,gs101-raven
>>> +            - google,gs101-pixel
>>> +            - google,gs101
>>
>> SoC cannot be a board in the same time.
> 
> Can you please expand? google,gs101 is the SoC, the other ones are boards.
> Is the commit message unclear?

You now say that these are valid boards:

compatible = "google,gs101", "google,gs101";
(although compatibles

compatible = "google,gs101", "google,gs101-pixel";

Both are wrong. SoC should not be before the board and SoC cannot be
used alone. Your schema allows that and that's not good.

I did not get what you want to achieve here, so tricky to advice.

Best regards,
Krzysztof

Re: [PATCH v2 2/3] arm64: dts: exynos: gs101-pixel: add generic gs101-based Pixel support

[Krzysztof Kozlowski]

On 23/12/2024 08:59, André Draszik wrote:
> Hi Krzysztof,
> 
> On Sun, 2024-12-22 at 12:42 +0100, Krzysztof Kozlowski wrote:
>> On 20/12/2024 12:27, André Draszik wrote:
>>> In order to support Pixel 6 (Oriole), Pixel 6 Pro (Raven), and Pixel 6a
>>> (Bluejay) correctly, we have to be able to distinguish them properly as
>>> we add support for more features.
>>>
>>> For example, Raven has a larger display. There are other differences,
>>> like battery design capacity, etc.
>>>
>>> To facilitate this, we create a generic gs101-based Pixel DT that can
>>> work on any such gs101-based device. At the same time, we move the
>>
>> No, whatever insanity Android has there, please don't populate it to
>> upstream.
>>
>> There is no such thing as "generic board" thus cannot be a
>> "generic DTS".
> 
> I'll rephrase to gs101-based Pixel base board. Unless you have a better
> suggestion.
> 
>>
>>> Oriole specific parts that we have at the moment (display) into an
>>> overlay, making it easy to add support for Raven and Bluejay in a
>>> similar way.
>>>
>>> Note1:
>>> Despite being an overlay, we instruct kbuild to create a merged
>>> gs101-oriole.dtb and a gs101-oriole.dtbo. This way existing scripts can
>>> keep working, but it also gives the option to just apply the overlay
>>> before boot (e.g. by the bootloader).
>>>
>>> Note2:
>>> I've changed the simple-framebuffer node to specify the memory via
>>> memory-region instead of reg, as that avoids unnecessary duplication
>>> (of the size), and it avoids having to specify #address-cells
>>> and #size-cells in the chosen node (and duplicating this in the DTSO),
>>> which is otherwise necessary to keep dt_binding_check happy and DT
>>> validation working in general.
>>>
>>> Signed-off-by: André Draszik <andre.draszik@linaro.org>
>>> ---
>>> Note: MAINTAINERS doesn't need updating, it covers this whole directory
>>> ---
>>>  arch/arm64/boot/dts/exynos/google/Makefile         |  6 ++--
>>>  .../arm64/boot/dts/exynos/google/gs101-oriole.dtso | 33 ++++++++++++++++++++++
>>>  .../{gs101-oriole.dts => gs101-pixel-generic.dts}  | 24 +++++++---------
>>>  3 files changed, 47 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
>>> index 0a6d5e1fe4ee..6e6b5319212a 100644
>>> --- a/arch/arm64/boot/dts/exynos/google/Makefile
>>> +++ b/arch/arm64/boot/dts/exynos/google/Makefile
>>> @@ -1,4 +1,6 @@
>>>  # SPDX-License-Identifier: GPL-2.0
>>>  
>>> -dtb-$(CONFIG_ARCH_EXYNOS) += \
>>> -	gs101-oriole.dtb \
>>> +dtb-$(CONFIG_ARCH_EXYNOS) += gs101-pixel-generic.dtb
>>> +
>>> +gs101-oriole-dtbs := gs101-pixel-generic.dtb gs101-oriole.dtbo
>>> +dtb-$(CONFIG_ARCH_EXYNOS) += gs101-oriole.dtb
>>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso
>>> new file mode 100644
>>> index 000000000000..43572039cd07
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dtso
>>> @@ -0,0 +1,33 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Oriole Device Tree
>>> + *
>>> + * Copyright 2021-2023 Google LLC
>>> + * Copyright 2023-2024 Linaro Ltd
>>> + */
>>> +
>>> +/dts-v1/;
>>> +/plugin/;
>>> +
>>> +&{/} {
>>> +	model = "Oriole";
>>> +	compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101";
>>
>> Boards are not overlays. Board equals DTB.
> 
> You're saying this should move into a dts instead of dtso?
> There are numerous boards upstream which use this same dtso
> approach.

Numerous? My quick look found zero. There are for specific
configurations, but not for boards. Look at something which could
support your case: imx8mm-kontron-dl.dtso
In first glance this is a board... but no! This is only about board with
display panel, because panel is detachable.

> 
> There is a base board, and also different versions of it,
> oriole being one of them.

Well, I did not see here baseboard - you renamed it.



Best regards,
Krzysztof

Re: [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel

[André Draszik]

On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote:
> On 23/12/2024 08:45, André Draszik wrote:
> > Hi Krzysztof,
> > 
> > On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote:
> > > On 20/12/2024 12:27, André Draszik wrote:
> > > > Raven is Google's code name for Pixel 6 Pro. Since there are
> > > > differences compared to Pixel 6 (Oriole), we need to add a separate
> > > > compatible for it.
> > > > 
> > > > We also want to support a generic DT, which can work on any type of
> > > 
> > > There are no such generic DT devices upstream, so we cannot add bindings
> > > for them.
> > 
> > Do you have a better suggestion for the wording?
> > How about 'gs101-based Pixel base board'?
> 
> It's not exactly about the wording but the concept. We don't have
> generic devices, thus no generic DT (DTS). Period. Thus you cannot have
> such schema.

There is a Pixel base board, with different additions to it, e.g.
different displays. The boot loader can pick the right one.

Let's discuss that in the other thread to have things in one place :-)
> 

> > > > gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as
> > > > a future addition). Such a DT will have certain nodes disabled / not
> > > > added. To facilitate such a generic gs101-based Pixel device, also add
> > > > a more generic gs101-pixel compatible. We can not just use the existing
> > > > google,gs101 for that, as it refers to the SoC, not a board.
> > > > 
> > > > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> > > > ---
> > > >  Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++----
> > > >  1 file changed, 14 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> > > > index e20b5c9b16bc..a8faf2256242 100644
> > > > --- a/Documentation/devicetree/bindings/arm/google.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/google.yaml
> > > > @@ -34,11 +34,21 @@ properties:
> > > >      const: '/'
> > > >    compatible:
> > > >      oneOf:
> > > > -      - description: Google Pixel 6 / Oriole
> > > > +      - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6
> > > > +          (Oriole), or 6 Pro (Raven)
> > > > +        minItems: 2
> > > > +        maxItems: 3
> > > >          items:
> > > > -          - enum:
> > > > -              - google,gs101-oriole
> > > > -          - const: google,gs101
> > > > +          enum:
> > > > +            - google,gs101-oriole
> > > > +            - google,gs101-raven
> > > > +            - google,gs101-pixel
> > > > +            - google,gs101
> > > 
> > > SoC cannot be a board in the same time.
> > 
> > Can you please expand? google,gs101 is the SoC, the other ones are boards.
> > Is the commit message unclear?
> 
> You now say that these are valid boards:
> 
> compatible = "google,gs101", "google,gs101";

Sorry, I don't see how (apart from the fact that dtbs_check flags
non-unique elements anyway). The result of the patch is:

        minItems: 2
        maxItems: 3
        items:
          enum:
            - google,gs101-oriole
            - google,gs101-raven
            - google,gs101-pixel
            - google,gs101
        allOf:
          - contains:
              const: google,gs101-pixel
          - contains:
              const: google,gs101

So one can not have 'google,gs101' twice. And if I only add
    compatible = "google,gs101", "google,gs101";
to the .dts, then dtbs_check complains indeed.

> (although compatibles
> 
> compatible = "google,gs101", "google,gs101-pixel";

OK, the schema doesn't flag incorrect ordering indeed.

> Both are wrong. SoC should not be before the board and SoC cannot be
> used alone. Your schema allows that and that's not good.
> 
> I did not get what you want to achieve here, so tricky to advice.

The intention is to enforce either of the following three:

    compatible = "google,gs101-raven", "google,gs101-pixel", "google,gs101";
    compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101";
    compatible = "google,gs101-pixel", "google,gs101";

I think this works (but I was aiming for something shorter,
possibly involving minItems):

  compatible:
    oneOf:
      - description: Google GS101 Pixel base board
        items:
          - const: google,gs101-pixel
          - const: google,gs101

      - description: Google GS101 Pixel 6 (Oriole), or 6 Pro (Raven)
        items:
          - enum:
              - google,gs101-oriole
              - google,gs101-raven
          - const: google,gs101-pixel
          - const: google,gs101


Cheers,
Andre'

Re: [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel

[Krzysztof Kozlowski]

On 23/12/2024 16:31, André Draszik wrote:
> On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote:
>> On 23/12/2024 08:45, André Draszik wrote:
>>> Hi Krzysztof,
>>>
>>> On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote:
>>>> On 20/12/2024 12:27, André Draszik wrote:
>>>>> Raven is Google's code name for Pixel 6 Pro. Since there are
>>>>> differences compared to Pixel 6 (Oriole), we need to add a separate
>>>>> compatible for it.
>>>>>
>>>>> We also want to support a generic DT, which can work on any type of
>>>>
>>>> There are no such generic DT devices upstream, so we cannot add bindings
>>>> for them.
>>>
>>> Do you have a better suggestion for the wording?
>>> How about 'gs101-based Pixel base board'?
>>
>> It's not exactly about the wording but the concept. We don't have
>> generic devices, thus no generic DT (DTS). Period. Thus you cannot have
>> such schema.
> 
> There is a Pixel base board, with different additions to it, e.g.
> different displays. The boot loader can pick the right one.
> 
> Let's discuss that in the other thread to have things in one place :-)
>>
> 
>>>>> gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as
>>>>> a future addition). Such a DT will have certain nodes disabled / not
>>>>> added. To facilitate such a generic gs101-based Pixel device, also add
>>>>> a more generic gs101-pixel compatible. We can not just use the existing
>>>>> google,gs101 for that, as it refers to the SoC, not a board.
>>>>>
>>>>> Signed-off-by: André Draszik <andre.draszik@linaro.org>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++----
>>>>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
>>>>> index e20b5c9b16bc..a8faf2256242 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/google.yaml
>>>>> +++ b/Documentation/devicetree/bindings/arm/google.yaml
>>>>> @@ -34,11 +34,21 @@ properties:
>>>>>      const: '/'
>>>>>    compatible:
>>>>>      oneOf:
>>>>> -      - description: Google Pixel 6 / Oriole
>>>>> +      - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6
>>>>> +          (Oriole), or 6 Pro (Raven)
>>>>> +        minItems: 2
>>>>> +        maxItems: 3
>>>>>          items:
>>>>> -          - enum:
>>>>> -              - google,gs101-oriole
>>>>> -          - const: google,gs101
>>>>> +          enum:
>>>>> +            - google,gs101-oriole
>>>>> +            - google,gs101-raven
>>>>> +            - google,gs101-pixel
>>>>> +            - google,gs101
>>>>
>>>> SoC cannot be a board in the same time.
>>>
>>> Can you please expand? google,gs101 is the SoC, the other ones are boards.
>>> Is the commit message unclear?
>>
>> You now say that these are valid boards:
>>
>> compatible = "google,gs101", "google,gs101";
> 
> Sorry, I don't see how (apart from the fact that dtbs_check flags
> non-unique elements anyway). The result of the patch is:
> 
>         minItems: 2
>         maxItems: 3
>         items:
>           enum:
>             - google,gs101-oriole
>             - google,gs101-raven
>             - google,gs101-pixel
>             - google,gs101

The problem is this line. Although entire concept of flexible list is
neither need nor ever recommended.

>         allOf:
>           - contains:
>               const: google,gs101-pixel
>           - contains:
>               const: google,gs101
> 
> So one can not have 'google,gs101' twice. And if I only add

Still can be, but indeed not with my example but:

"google,gs101", "google,gs101", "google,gs101-pixel";

>     compatible = "google,gs101", "google,gs101";
> to the .dts, then dtbs_check complains indeed.
> 
>> (although compatibles
>>
>> compatible = "google,gs101", "google,gs101-pixel";
> 
> OK, the schema doesn't flag incorrect ordering indeed.
> 
>> Both are wrong. SoC should not be before the board and SoC cannot be
>> used alone. Your schema allows that and that's not good.
>>
>> I did not get what you want to achieve here, so tricky to advice.
> 
> The intention is to enforce either of the following three:
> 
>     compatible = "google,gs101-raven", "google,gs101-pixel", "google,gs101";
>     compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101";

These two are standard - list of three: enum + const + const

>     compatible = "google,gs101-pixel", "google,gs101";

And that's a separate entry.

> 
> I think this works (but I was aiming for something shorter,
> possibly involving minItems):
> 
>   compatible:
>     oneOf:
>       - description: Google GS101 Pixel base board

What is a base board in terms of phone? This can be only final product,
you cannot use/have a baseboard. This is not an evalkit.

>         items:
>           - const: google,gs101-pixel
>           - const: google,gs101



Best regards,
Krzysztof

Re: [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel

[André Draszik]

On Mon, 2024-12-23 at 16:39 +0100, Krzysztof Kozlowski wrote:
> On 23/12/2024 16:31, André Draszik wrote:
> > On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote:
> > 
> > > 
> > > You now say that these are valid boards:
> > > 
> > > compatible = "google,gs101", "google,gs101";
> > 
> > Sorry, I don't see how (apart from the fact that dtbs_check flags
> > non-unique elements anyway). The result of the patch is:
> > 
> >         minItems: 2
> >         maxItems: 3
> >         items:
> >           enum:
> >             - google,gs101-oriole
> >             - google,gs101-raven
> >             - google,gs101-pixel
> >             - google,gs101
> 
> The problem is this line. Although entire concept of flexible list is
> neither need nor ever recommended.

All of this was inspired by Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
I guess not a good example in this case...

> 
> >         allOf:
> >           - contains:
> >               const: google,gs101-pixel
> >           - contains:
> >               const: google,gs101
> > 
> > So one can not have 'google,gs101' twice. And if I only add
> 
> Still can be, but indeed not with my example but:
> 
> "google,gs101", "google,gs101", "google,gs101-pixel";

This example doesn't pass irrespective of binding, because
dtbs_check will complain about non-unique elements.

Anyway, will use separate entries.


Thanks Krzysztof,
Cheers,
Andre'

> 

Re: [PATCH v2 1/3] dt-bindings: arm: google: add gs101-raven and generic gs101-pixel

[Krzysztof Kozlowski]

On 23/12/2024 16:54, André Draszik wrote:
> On Mon, 2024-12-23 at 16:39 +0100, Krzysztof Kozlowski wrote:
>> On 23/12/2024 16:31, André Draszik wrote:
>>> On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote:
>>>
>>>>
>>>> You now say that these are valid boards:
>>>>
>>>> compatible = "google,gs101", "google,gs101";
>>>
>>> Sorry, I don't see how (apart from the fact that dtbs_check flags
>>> non-unique elements anyway). The result of the patch is:
>>>
>>>         minItems: 2
>>>         maxItems: 3
>>>         items:
>>>           enum:
>>>             - google,gs101-oriole
>>>             - google,gs101-raven
>>>             - google,gs101-pixel
>>>             - google,gs101
>>
>> The problem is this line. Although entire concept of flexible list is
>> neither need nor ever recommended.
> 
> All of this was inspired by Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> I guess not a good example in this case...

These are SoMs with multiple revisions, so quite a different case. Plus
there is actual reason from Michal for doing that explained in commit msg.

> 
>>
>>>         allOf:
>>>           - contains:
>>>               const: google,gs101-pixel
>>>           - contains:
>>>               const: google,gs101
>>>
>>> So one can not have 'google,gs101' twice. And if I only add
>>
>> Still can be, but indeed not with my example but:
>>
>> "google,gs101", "google,gs101", "google,gs101-pixel";
> 
> This example doesn't pass irrespective of binding, because
> dtbs_check will complain about non-unique elements.

Ah, cool, I wasn't really sure. I checked only dt_binding_check on some
example and there it was not spotted.


Best regards,
Krzysztof