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. 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
