Hi Rob,
On Mon, Mar 8, 2021 at 11:16 PM Rob Herring <robh@xxxxxxxxxx> wrote:
> On Fri, Mar 05, 2021 at 02:37:03PM +0100, Geert Uytterhoeven wrote:
> > Add device tree bindings documentation for the Renesas R-Car V3U Falcon
> > CSI/DSI and Ethernet sub-boards. These are plugged into the Falcon
> > BreakOut board to form the full Falcon board stack.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> > ---
> > Marked as RFC
> >
> > The Falcon board stack consists of 4 boards:
> > 1. CPU board, containing the R-Car V3U SoC, and core system parts like
> > RAM, console, eMMC,
> > 2. BreakOut board, providing power, an Ethernet PHY, and a backplane
> > where boards 1, 3, and 4 are plugged in,
> > 3. CSI/DSI sub-board, providing 2 GMSL displays and 12 GMSL cameras,
> > 4. Ethernet sub-board, providing 6 Ethernet PHYs.
> >
> > As the BreakOut board provides power, the CPU board cannot be used
> > without the BreakOut board. However, both the CSI/DSI and Ethernet
> > sub-boards are optional. So that means we have to support 4 stacks of
> > board combinations (1+2, 1+2+3, 1+2+4, 1+2+3+4).
> >
> > That sounds like a good target for fdtoverlay, right?
> >
> > For now[1] the Falcon include hierarchy looks like this (supporting only
> > the full stack 1+2+3+4):
> >
> > r8a779a0-falcon.dts
> > |-- r8a779a0-falcon-cpu.dtsi
> > | `-- r8a779a0.dtsi
> > |-- r8a779a0-falcon-csi-dsi.dtsi
> > `-- r8a779a0-falcon-ethernet.dtsi
> >
> > Traditionally, we augmented the "model" and "compatible" properties of
> > the root node in each additional layer:
> >
> > r8a779a0.dtsi:
> > compatible = "renesas,r8a779a0";
> >
> > r8a779a0-falcon-cpu.dtsi:
> > model = "Renesas Falcon CPU board";
> > compatible = "renesas,falcon-cpu", "renesas,r8a779a0";
> >
> > r8a779a0-falcon.dts:
> > model = "Renesas Falcon CPU and Breakout boards based on r8a779a0";
> > compatible = "renesas,falcon-breakout", "renesas,falcon-cpu", "renesas,r8a779a0";
> >
> > (Note: I haven't done that yet for the CSI/DSI and Ethernet sub-boards)
> >
> > With a stack of 4 boards, some optional, this becomes a bit cumbersome.
> > But it is still doable when using .dts and .dtsi files, by just adding 3
> > more r8a779a0-falcon*.dts files.
> >
> > So we can add model/compatible properties to the sub-boards:
> >
> > r8a779a0-falcon-csi-dsi.dtsi
> > model = "Renesas Falcon CSI/DSI sub-board";
> > compatible = "renesas,falcon-csi-dsi";
> >
> > r8a779a0-falcon-ethernet.dtsi:
> > model = "Renesas Falcon Ethernet sub-board";
> > compatible = "renesas,falcon-ethernet";
> >
> > and update r8a779a0-falcon*dts to augment the properties.
> >
> > However, this is currently not possible when using overlays, as applying
> > an overlay would override the properties in the underlying DTB, not
> > augment them.
> >
> > Questions:
> > a. Should we document all possible combinations in the bindings file?
> > After this patch, we only have 1, 1+2, and 1+2+3+4 documented.
> >
> > b. How to handle "model" and "compatible" properties for (sub)boards?
> > Perhaps fdtoverlay could combine the "model" and "compatible"
> > properties in the root nodes? However, that is not always desired.
>
> I think we just don't want to put sub-board compatibles in the root
> compatible at least if they are optional, peripheral components like
> this case seems to be. For something like a SoM plus baseboard I tend to
> feel differently.
OK, makes sense.
> Do you really need it? I'd assume you could just check for the
Just being cautious. We once (actually 5 times) needed a quirk for
boards with regulators keeping shared IRQS asserted[1]. Something
like that might happen with an expansion board, too.
> components? Or we define connectors and under the connector we define a
> top level compatible for the sub-board. This sounds like an eval or
> validation board? Those tend to have every possible option and I'm not
> sure we want to solve that before solving the simple cases.
Let's do without for now. We can still check for main board compatible
value + components when needed.
Thanks!
[1] arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
