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@xxxxxxxxx -- +49-151-27565287
