Messages in this thread | | | Subject | Re: RFC: oftree based setup of composite board devices | From | "Enrico Weigelt, metux IT consult" <> | Date | Wed, 24 Feb 2021 14:00:12 +0100 |
| |
On 15.02.21 02:12, Frank Rowand wrote:
> Why not compile in ACPI data (tables?) instead of devicetree description?
The problem is a bit more complex than it might seem.
Let's take the APU2/37/4 boards as an example. They've got some aux devices, eg. some gpio controller, and some things (leds, keys, reset lines, etc) attached to it.
Now we've got lots of different bios versions in the field, enumerating only some of the devices. For example, older ones didn't even contain the gpio, later ones added just gpio, other ones just added LEDs (with different names than the Linux driver already mainlined and field-deployed at that time), but still other lines unhandled, etc, etc. etc.
A big mess :( And I can't ask everybody to do bios uprade on devices far out in the field (litterally open field, sometimes offshore, ...). So, I need a usable solution, that's also maintainable, w/o testing each single combination of board, bios, etc. IOW: without relying on bios (except for board identification)
OTOH, I'm also looking for a solution get rid writing those kind of relatively huge board drivers, that pretty are much like old fashioned board files from pre-DT times - just made up of lots of tables and a few trivial register-something calls. Sounds pretty much like the original use case of oftree.
The primary difference between classic oftree and this scanario: * this is additional to existing platform information, which is incomplete or even incorrect (and that can't be fixed) * extra carrier boards that are detected by other means, but no enumeration of the devices on it.
>> 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.
Well, mixing different, overlapping data sources tends to be tricky. The same problem exists with the classic approach of hand-written board drivers. So there have to be clear border lines.
In my case (eg. apu2+ boards), the overlap is only that some bios versions enumerate the gpio chip, others even some of the gpio-based devices. I'm attempting to solve this by just kicking out those duplicate devices, if they exist. The alternative could be leaving them in an trying to bind the missing ones to them. But that would be really complicatd and needs to be well crafted for lots of different board and bios versions - a kind of complexity we wanna avoid.
My use cases are actually a bit easier than the average dt overlay cases, as I have almost no interactions with already existing devices (except that some specific devices have to be moved out of the way)
The original DT overlay use case, arbitrary expansion boards (eg. on raspi), are trickier, if the overlays shall be generic over a wider range of base boards (eg. same overlay for any raspi or odroid). This is something calling for an own (pseudo-)bus type that handles the correct probing ... I've hacked up something similar for the APU2+'s combined msata/usb/mpcie ports.
BTW: I've already been thinking of ways for internally transforming ACPI tables into DT data structures (struct device_node) at an early point, before probing. But that would be another research project with unknown outcome, and most likely a HUGE change. Not what I'm talking about now.
> From the devicetree side, I expect nightmares for me if devicetree and ACPI > are mixed in a single running kernel image.
Note that I'm not talking about arbitrary configurations. Just re-using existing device tree code to express things that are currently open coded C into DT.
It's NOT trying to boot an ACPI-based machine with DT. (which would be yet another research project)
> 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.
Yes, it's not entirely trivial, but managable. My experiments seemed to work so far, and I couldn't see general blockers yet. Drivers usually expect certain sub-nodes, but haven't found any that expect their node being embedded in some other one. (maybe there really are some, but the likehood that they're applicable in these use cases looks pretty low).
--mtx
-- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287
| |