Re: [PATCH RFC] dt-bindings: arm: renesas: Document Renesas Falcon sub-boards

[Rob Herring <robh@kernel.org>]

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@glider.be>
> ---
> 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.

Do you really need it? I'd assume you could just check for the 
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.

Rob