Re: [PATCH 1/4] dt-bindings: arm: google: Add bindings for frankel/blazer/mustang
From: Rob Herring <robh@kernel.org>
Date: 2025-11-13 02:27:21
Also in:
linux-devicetree, linux-samsung-soc, lkml
On Tue, Nov 11, 2025 at 11:22:04AM -0800, Douglas Anderson wrote:
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.I think this is a problem...
Signed-off-by: Douglas Anderson <dianders@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.
I think it is worth having the discussion. There's been some discussions about an overlay split with SoMs and baseboards as well. I think that's what is driving this addition[1]. I don't think this case is much different. As a different way to combine things compared to .dtsi files, I don't care too much how things are structured to the extent that's just internal structure and we're moving the combining of files from one point in time to another. My concern here is largely around validation. Can the SoC DTB pass validation, and can we still validate the whole thing at build time? To start with, it's not great if we have to make the schema allow only an SoC compatible without a board compatible. Then suddenly omitting a board compatible is always valid. Solving that with an entirely different SoC compatible as you have doesn't seem great. My other concern is whether this is an ABI between the SoC and board DTBs? And I don't mean just you, but for anyone wanting to do anything remotely similar. An ABI is a problem as we don't really have any way to validate each piece separately. (This is already a problem for existing overlays.)
quoted hunk ↗ jump to hunk
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/ (local) .../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
Should upstream really care about anything other than MP1? I don't think so. Which ones are useful in 1 year, 2 years, 10 years?
+ - const: google,lga-frankel + - const: google,lga
It's not clear to me how you map boards to SoC revision? You boot up using the SoC DTB and then select the board DTBO based on? This all needs to be well defined and general enough any (existing) platform could use it. If [1] helps or doesn't work for you I'm interested in hearing that. Rob [1] https://lore.kernel.org/devicetree-spec/20250911151436.2467758-1-raymond.mao@linaro.org/ (local)