On Mon, Feb 15, 2021 at 3:15 AM Frank Rowand <frowand.list@xxxxxxxxx> wrote: > On 2/8/21 5:48 PM, Rob Herring wrote: > > On Mon, Feb 8, 2021 at 4:22 PM Enrico Weigelt, metux IT consult > > <info@xxxxxxxxx> wrote: > >> > >> Hello folks, > >> > >> here's an RFC for using compiled-in dtb's for initializing board devices > >> that can't be probed via bus'es or firmware. > > I've just been monitoring this thread for several days, hoping that the > discussion would make things more clear for me. You beat me up to it. I support your comments. I have to comment to Enrico and others that under overlays for ACPI-based platforms I meant SSDT overlays, no DT. Also I have to point out that we have swnode API for the cases where we need quirks for either ACPI or DT or whatever (not yet present) firmware quirks. > Disclaimer: I know essentially nothing about ACPI, please excuse improper > naming and misunderstandings on my part. > > Why not compile in ACPI data (tables?) instead of devicetree description? > > > > > I'm not convinced compiled in is the mechanism we want. > > > >> Use cases are boards with non-oftree firmware (ACPI, etc) where certain > >> platform devices can't be directly enumerated via firmware. Traditionally > >> we had to write board specific drivers that check for board identification > >> (DMI strings, etc), then initialize the actual devices and their links > >> (eg. gpio<->leds/buttons, ...). Often this can be expressed just by DT. > > > > This is something I've wanted to see for a while. There's use cases > > for DT based systems too. The example I'd like to see supported are > > USB serial adapters with downstream serdev, GPIO, I2C, SPI, etc. Then > > plug more than one of those in. > > My understanding from the past is that the experts (those who understand both > devicetree and ACPI) regard trying to mix devicetree and ACPI in a single > running Linux kernel image is insanity, or at least likely to be confusing, > difficult, and problematic. > > From the devicetree side, I expect nightmares for me if devicetree and ACPI > are mixed in a single running kernel image. > > > > >> This patch queue does a bunch of preparations in oftree code, so we can > >> support multiple fully independent DT's (not using DT overlays). And then > >> adds a generic driver parses compiled-in fdt blobs, checks for mathing > >> DMI strings and initializes the devices. As an example, the last patch > >> adds an alternative implementation for the PC engines APU2/3/4 boa> Disclaimer: I know essentially nothing about ACPI, please excuse improper rd > >> family based on device tree. > > > > I think there's a couple of approaches we could take. Either support > > multiple root nodes as you have done or keep a single root and add > > child nodes to them. I think the latter would be less invasive. In the > > non-DT cases, we'd just always create an empty skeleton DT. A 3rd > > variation on a DT system is we could want to create parent nodes if > > they don't exist to attach this DT to so we have a full hierarchy. > > > > I'm not saying which one we should do, just laying out some of the options. > > > > Multiple root nodes and disjoint trees both seem problematic. Existing > subsystems and drivers expect a single cohesive tree. Changing that > architecture looks to me to be a painful exercise. > > >> The approach can be easily be extended to other kinds of composite devices, > >> eg. PCI cards or USB dongles. > >> > >> > >> Yet some drawbacks of the current implementation: > >> > >> * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based > >> modprobing anyways) > > > > I think we need to use either firmware loading or udev mechanisms to > > load the FDTs. > > > >> * can't reconfigure or attach to devices outside the individual DT's > >> (eg. probed by PCI, etc) > > > > Not sure I follow. > > > > Rob > > > -- With Best Regards, Andy Shevchenko
