[PATCH 1/4] dt-bindings: arm: google: Add bindings for frankel/blazer/mustang
Douglas Anderson
dianders at chromium.org
Tue Nov 11 11:22:04 PST 2025
Add top-level DT bindings useful for Pixel 10 (frankel), Pixel 10 Pro
(blazer), and Pixel 10 Pro XL (mustang).
Since overlays are fairly well-supported these days and the downstream
Pixel bootloader assumes that the SoC is the base overlay and specific
board revisions are overlays, reflect the SoC / board split in the
bindings.
The SoC in the Pixel 10 series has the marketing name of "Tensor
G5". Despite the fact that it sounds very similar to the "Tensor G4",
it's a very different chip. Tensor G4 was, for all intents and
purposes, a Samsung Exynos offshoot whereas Tensor G5 is entirely its
own SoC. This SoC is known internally as "laguna" and canonically
referred to in code as "lga". There are two known revisions of the
SoC: an A0 pre-production variant (ID 0x000500) and a B0 variant (ID
0x000510) used in production. The ID is canonicaly broken up into a
16-bit SoC product ID, a 4-bit major rev, and a 4-bit minor rev.
The dtb for all supported SoC revisions is appended to one of the boot
partitions and the bootloader will look at the device trees and pick
the correct one. The current bootloader uses a downstream
`soc_compatible` node to help it pick the correct device tree. It
looks like this:
soc_compatible {
B0 {
description = "LGA B0";
product_id = <0x5>;
major = <0x1>;
minor = <0x0>;
pkg_mode = <0x0>;
};
};
Note that `pkg_mode` isn't currently part of the ID on the SoC and the
bootloader always assumes 0 for it.
In this patch, put the SoC IDs straight into the compatible. Though
the bootloader doesn't look at the compatible at the moment, this
should be easy to teach the bootloader about.
Boards all know their own platform_id / product_id / stage / major /
minor / variant. For instance, Google Pixel 10 Pro XL MP1 is:
* platform_id (8-bits): 0x07 - frankel/blazer/mustang
* product_id (8-bits): 0x05 - mustang
* stage (4-bits): 0x06 - MP
* major (8-bits): 0x01 - MP 1
* minor (8-bits): 0x00 - MP 1.0
* variant (8-bits): 0x00 - No special variant
When board overlays are packed into the "dtbo" partition, a tool
(`mkdtimg`) extracts a board ID and board rev from the overlay and
stores that as metadata with the overlay. Downstream, the dtso
intended for the Pixel 10 Pro XL MP1 has the following properties at
its top-level:
board_id = <0x70506>;
board_rev = <0x010000>;
The use of top-level IDs can probably be used for overlays upstream as
well, but also add the IDs to the compatible string in case it's
useful.
Compatible strings are added for all board revisions known to be
produced based on downstream sources.
A few notes:
* If you look at `/proc/device-tree/compatible` and
`/proc/device-tree/model` on a running device, that won't
necessarily be an exact description of the hardware you're running
on. If the bootloader can't find a device tree that's an exact match
then it will pick the best match (within reason--it will never pick
a device tree for a different product--just for different revs of
the same product).
* There is no merging of the top-level compatible from the SoC and
board. The compatible string containing IDs for the SoC will not be
found in the device-tree passed to the OS.
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
In the past, attempts to have the SoC as a base device tree and boards
supported as overlays has been NAKed. From a previous discussion [1]
"Nope, boards are not overlays. Boards are DTB." I believe this needs
to be relitigated.
In the previous NAK, I didn't see any links to documentation
explicitly stating that DTBs have to represent boards. It's also
unclear, at least to me, _why_ a DTB would be limited to represent a
"board" nor what the definition of a "board" is.
As at least one stab at why someone might not want an overlay scheme
like this, one could point out that the top-level compatible can be a
bit of a mess. Specifically in this scheme the board "compatible" from
the overlay will fully replace/hide the SoC "compatible" from the base
SoC. If this is truly the main concern, it wouldn't be terribly hard
to add a new semantic (maybe selectable via a new additional
property?) that caused the compatible strings to be merged in a
reasonable way.
Aside from dealing with the compatible string, let's think about what
a "board" is. I will make the argument here that the SoC qualifies as
a "board" and that the main PCB of a phone can be looked at as a
"cape" for this SoC "board". While this may sound like a stretch, I
would invite a reader to propose a definition of "board" that excludes
this. Specifically, it can be noted:
* I have a development board at my desk that is "socketed". That is, I
can pull the SoC out and put a different one in. I can swap in a
"rev A0" or a "rev B0" SoC into this socket. Conceivably, I could
even put a "Tensor G6", G7, G8, or G999 in the socket if it was
compatible. In this sense, the "SoC" is a standalone thing that can
be attached to the devboard "cape". The SoC being a standalone thing
is in the name. It's a "system" on a chip.
* In case the definition of a board somehow needs a PCB involved, I
can note that on my dev board the CPU socket is soldered onto to a
CPU daughtercard (a PCB!) that then has a board-to-board connector
to the main PCB.
* Perhaps one could argue that a dev board like I have describe would
qualify for this SoC/board overlay scheme but that a normal cell
phone wouldn't because the SoC isn't removable. Perhaps removability
is a requirement here? If so, imagine if some company took a
Raspberry Pi, soldered some components directly onto the "expansion"
pins, and resold that to consumers. Does this mean they can't use
overlays?
To me, the above arguments justify why SoC DTBs + "board" overlays
should be accepted. As far as I can tell, there is no downside and
many people who would be made happy with this.
[1] https://lore.kernel.org/all/dbeb28be-1aac-400b-87c1-9764aca3a799@kernel.org/
.../devicetree/bindings/arm/google.yaml | 87 +++++++++++++++----
1 file changed, 68 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
index 99961e5282e5..f9f9ea1c8050 100644
--- a/Documentation/devicetree/bindings/arm/google.yaml
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -13,27 +13,18 @@ description: |
ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
devices.
- Currently upstream this is devices using "gs101" SoC which is found in Pixel
- 6, Pixel 6 Pro and Pixel 6a.
+ These bindings for older Pixel devices don't use device tree overlays so
+ no separate SoC entry is added. This may change in the future.
- Google have a few different names for the SoC:
- - Marketing name ("Tensor")
- - Codename ("Whitechapel")
- - SoC ID ("gs101")
- - Die ID ("S5P9845")
-
- Likewise there are a couple of names for the actual device
- - Marketing name ("Pixel 6")
- - Codename ("Oriole")
-
- Devicetrees should use the lowercased SoC ID and lowercased board codename,
- e.g. gs101 and gs101-oriole.
+ Newer Pixel devices are expected to have the SoC device tree as the base
+ and specific board device trees as overlays.
properties:
$nodename:
const: '/'
compatible:
oneOf:
+ # Google Tensor G1 AKA gs101 AKA whitechapel AKA Die ID S5P9845 boards
- description: Google Pixel 6 or 6 Pro (Oriole or Raven)
items:
- enum:
@@ -41,13 +32,71 @@ properties:
- google,gs101-raven
- const: google,gs101
+ # Google Tensor G5 AKA lga (laguna) SoC and boards
+ - description: Tensor G5 SoC (laguna)
+ items:
+ - enum:
+ - google,soc-id-0005-rev-00 # A0
+ - google,soc-id-0005-rev-10 # B0
+ - const: google,lga
+ - description: Google Pixel 10 Board (Frankel)
+ items:
+ - enum:
+ - google,pixel-id-070302-rev-000000 # Proto 0
+ - google,pixel-id-070302-rev-010000 # Proto 1
+ - google,pixel-id-070302-rev-010100 # Proto 1.1
+ - google,pixel-id-070303-rev-010000 # EVT 1
+ - google,pixel-id-070303-rev-010100 # EVT 1.1
+ - google,pixel-id-070303-rev-010101 # EVT 1.1 Wingboard
+ - google,pixel-id-070304-rev-010000 # DVT 1
+ - google,pixel-id-070305-rev-010000 # PVT 1
+ - google,pixel-id-070306-rev-010000 # MP 1
+ - const: google,lga-frankel
+ - const: google,lga
+ - description: Google Pixel 10 Pro Board (Blazer)
+ items:
+ - enum:
+ - google,pixel-id-070402-rev-000000 # Proto 0
+ - google,pixel-id-070402-rev-010000 # Proto 1
+ - google,pixel-id-070402-rev-010100 # Proto 1.1
+ - google,pixel-id-070403-rev-010000 # EVT 1
+ - google,pixel-id-070403-rev-010100 # EVT 1.1
+ - google,pixel-id-070404-rev-010000 # DVT 1
+ - google,pixel-id-070405-rev-010000 # PVT 1
+ - google,pixel-id-070406-rev-010000 # MP 1
+ - const: google,lga-blazer
+ - const: google,lga
+ - description: Google Pixel 10 Pro XL Board (Mustang)
+ items:
+ - enum:
+ - google,pixel-id-070502-rev-000000 # Proto 0
+ - google,pixel-id-070502-rev-010000 # Proto 1
+ - google,pixel-id-070502-rev-010100 # Proto 1.1
+ - google,pixel-id-070502-rev-010101 # Proto 1.1 Wingboard
+ - google,pixel-id-070503-rev-010000 # EVT 1
+ - google,pixel-id-070503-rev-010100 # EVT 1.1
+ - google,pixel-id-070503-rev-010101 # EVT 1.1 Wingboard
+ - google,pixel-id-070504-rev-010000 # DVT 1
+ - google,pixel-id-070505-rev-010000 # PVT 1
+ - google,pixel-id-070506-rev-010000 # MP 1
+ - const: google,lga-mustang
+ - const: google,lga
+
+allOf:
# Bootloader requires empty ect node to be present
- ect:
- type: object
- additionalProperties: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: google,gs101
+ then:
+ properties:
+ ect:
+ type: object
+ additionalProperties: false
-required:
- - ect
+ required:
+ - ect
additionalProperties: true
--
2.51.2.1041.gc1ab5b90ca-goog
More information about the linux-arm-kernel
mailing list