Re: [PATCH v2 3/4] dt-bindings: mailbox: goog-mba: Add goog-mba mailbox bindings
From: Doug Anderson
Date: Fri Oct 30 2026 - 19:34:54 EST
Hi,
On Fri, Oct 30, 2026 at 3:48 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On Fri, Oct 23, 2026 at 04:52:20PM -0700, Douglas Anderson wrote:
> > +properties:
> > + compatible:
> > + const: google,lga-mailbox-array
> > +
> > + reg:
> > + minItems: 1
> > + items:
> > + - description: Host registers (not accessible to client)
> > + - description: Global registers (not present on newer IP blocks)
>
> That's still confusing. Last time you said:
> 1. You identified 4x instances of MBA
> 2. Each of the instance has global registers (quotting: "Each of these 4
> MBA instances has its own "global" registers."), then why does the
> binding say otherwise?
>
> You repeat here again "newer IP blocks" so how many versions does your SoC have?
In v2, I'll remove the "(not present on newer IP blocks)" part and
remove "minItems: 1". Both Pixel 10 SoC (laguna or lga) and Pixel 11
SoC (malibu) have the global registers. Newer (unreleased) SoCs lack
these (read-only) global registers and all of the information that was
in them is replicated in each mailbox's register space. There
shouldn't be any harm in making them both required for now and we can
make the change later.
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > +
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + mailbox-array@5240000 {
> > + compatible = "google,lga-mailbox-array";
> > + reg = <0x0 0x05240000 0x0 0x00010000>,
> > + <0x0 0x05250000 0x0 0x00010000>;
> > + ranges = <0x0 0x0 0x05260000 0x00020000>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + mailbox@0 {
> > + reg = <0x0000 0x1000>;
> > + interrupts = <GIC_SPI 250 IRQ_TYPE_LEVEL_HIGH 0>;
> > +
> > + #mbox-cells = <0>;
> > +
> > + google,tx-payload-words = <4>;
> > + google,mba-queue-mode;
> > + };
> > +
> > + mailbox@1000 {
> > + reg = <0x1000 0x1000>;
> > + interrupts = <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH 0>;
> > +
>
> Please make the example complete. Last time you wrote:
>
> "If we tried to represent the mailbox array as a single mailbox with a
> bunch of channels, each instance would have a different number of
> "reg" entries and a different number of interrupts."
>
> and I do not see that. I see each instance having exactly one reg entry,
> exactly one interrupt with difference in RX and TX.
>
> The DTS here:
> https://lore.kernel.org/all/20261026144346.1.Iaf8214205f496225013f482f6e0035e89ac624f2@changeid/
>
> has the same.
OK, sounds good. I can give more examples. That being said, I'm having
a hard time finding a great example that _proves_ that this shouldn't
be a single mailbox with a bunch of channels. Specifically, although
the hardware itself is fairly flexible, the current firmware running
on the remote processors isn't taking advantage of all of this
flexibility. That being said, it is not far-fetched that this would
change as more users of this IP block emerge. This IP block is used
_heavily_ in Google designs.
Really, I think my argument for describing things this way comes more
from looking at the hardware register descriptions than from looking
at the current users. I think modeling the bindings to best match the
hardware design is the right approach. Let me see if I can give more
details here, even if they don't translate well into examples...
Let's start by looking at the CPM mailbox array. This is the mailbox
array shown in the examples. The first two mailboxes (0 and 1) in this
array allow the AP to communicate with the CPM. They are high
bandwidth and use queuing. One is for TX, and one is for RX. In
current designs, both happen to use 4-words per transfer.
What you can't see (and won't translate into examples) is that this
same mailbox array has many extra mailboxes. These extra mailboxes are
used for the CPM to communicate with other system components. From
what I see, the second two mailboxes (2 and 3) are used to communicate
to the AP's secure firmware (TF-A) and also use queuing mode. Then
mailboxes 4 and 5 communicate to the GDMC (Google Debug Monitor Core)
and _don't_ use queuing. Mailboxes 8 and 9 communicate with the AOC
(Always On Compute). There are a pile of other mailbox pairs. Though
we don't model these mailboxes in the Linux device tree (which only
looks at things from the AP perspective), the protocol used here is
very different.
Different mailboxes in the array are allocated to different processors
in the system, which is why each mailbox is fairly self-contained.
Each mailbox in the array has a 4K register space representing that
mailbox. To me, this is a primary reason why these are best
represented as full-blown mailboxes, not as "channels". Each of these
mailboxes is a self-contained unit and can be allocated independently
toward one of the processors in the system. They don't look like
"channels". The thing that ties them together into an "array" is that
all the mailboxes in the array all talk to a given "host" that owns
the mailbox array. Yes, sometimes several of these mailboxes end up
routed to the same processor in the system, but fundamentally they are
still separate mailboxes...
Yes, we could try to make these mailboxes look like "channels", but
the hardware is really designed around each mailbox in the array being
an independent/separate thing.
Does that make sense?
>From a perspective of "do these each need their own node": Even if we
don't currently see an instance where multiple mailboxes are routed to
the non-secure AP and some use queueing while others don't, the
hardware supports it and we should make sure the bindings are ready
for that.
If you want, I can create a hypothetical example where some mailboxes
use queuing mode (or have a different TX word size) and others don't.
Would that make things look better?
---
To show examples of some of the other mailboxes in lga, here is the
"GDMC to AP NonSecure" one. You'll note that it starts at mailbox 2 in
the array (not mailbox 0) since mailboxes 0 and 1 in the array are
routed elsewhere.
gdmc_ap_ns_mba: mailbox-array@6240000 {
compatible = "google,lga-mailbox-array";
reg = <0x0 0x06240000 0x0 0x00010000>,
<0x0 0x06250000 0x0 0x00010000>;
ranges = <0x0 0x0 0x06260000 0x00020000>;
#address-cells = <1>;
#size-cells = <1>;
gdmc_ap_non_secure_req_mba_client_2: mailbox@2000 {
reg = <0x2000 0x1000>;
interrupts = <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH 0>;
#mbox-cells = <0>;
google,rx-payload-words = <4>;
};
...
gdmc_ap3_req_mba_client_10: mailbox@a000 {
reg = <0xa000 0x1000>;
interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH 0>;
#mbox-cells = <0>;
google,rx-payload-words = <4>;
};
gdmc_ap3_resp_mba_client_11: mailbox@b000 {
reg = <0xb000 0x1000>;
interrupts = <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH 0>;
#mbox-cells = <0>;
google,rx-payload-words = <4>;
};
};
---
The "AOC to AP" mailbox for "lga" looks like this. In practice, the
software uses most of these as "doorbell only", though exactly one of
the mailboxes here actually gets data transferred over it.
aoc_ap_mba: mailbox-array@b480000 {
compatible = "google,lga-mailbox-array", "google,mailbox-array";
reg = <0x0 0x0b480000 0x0 0x00010000>,
<0x0 0x0b490000 0x0 0x00010000>;
ranges = <0x0 0x0 0x0b4a0000 0x00020000>;
#address-cells = <1>;
#size-cells = <1>;
aoc_ap_0_mba_client_0: mailbox@0 {
reg = <0x00000 0x1000>;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH 0>;
#mbox-cells = <0>;
};
aoc_ap_1_mba_client_1: mailbox@1000 {
reg = <0x01000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>;
#mbox-cells = <0>;
};
...
aoc_ap_19_mba_client_19: mailbox@13000 {
reg = <0x13000 0x1000>;
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
#mbox-cells = <0>;
};
};