Messages in this thread | | | Subject | Re: RFC: oftree based setup of composite board devices | From | "Enrico Weigelt, metux IT consult" <> | Date | Thu, 11 Feb 2021 18:01:11 +0100 |
| |
On 11.02.21 12:41, Andy Shevchenko wrote:
Hi,
> On Thu, Feb 11, 2021 at 1:15 PM Enrico Weigelt, metux IT consult > <lkml@metux.net> wrote: >> On 10.02.21 11:30, Andy Shevchenko wrote: > >>>> 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. >>> >>> In ACPI we support DT compatible strings, and we support overlays for >>> a long time. Would it work for you? >> >> please tell me more, how ACPI and DT can already work together ? > > It's all in documentation. > > https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
Thanks, but I'm still unsure how this helps me. I'm not intending to touch any firmware (and expect people in the field flashing new fw). I have to live with what we find in the field (otherwise I'd just write omplete DTs for the corresponding boards and throw out ACPI :p)
> https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html
Are you suggesting I should load SSDT overlays at runtime (from userland ?) instead of using DT ?
> Please, please, read documentation beforehand!
I actually did read that documentation, but unfortunately it doesn't tell me how to use additional DTs on ACPI systems.
>> You already know my apu board driver - that's my first example usecase. > > Sorry, but I forgot about it. Can you summarize what is your use case > that really needs so intrusive and hard work?
The current APU2/3/4 driver is pretty much fine (except that possibly some more bios-version specific quirks might be needed). It basically just instantiates a bunch of other devices (gpio, led, input, ...) and connects them.
All of that (except for the DMI match table) already can be easily expressed in DT, so this calls for a generalization. At that point I tried to achieve the following goals:
* a generic mechanism for detecting boards (and later pci cards, usb dongles, etc) and probing the devices from the corresponding DT * have everything that makes up an individual board in one DT(S) * ability to blacklist (kick out) specific devices already probed via ACPI, so they don't conflict. (*1)
>> * match rules shall be inside the DTS >> * future match rules shall also check for bios versions etc >> * adding new boards shall be possible by just adding another DTS to >> the tree (not a whole module) >> * supporting several board variants (w/ small differences) by one DTS >> * sometimes existing devices (eg. enumerated by acpi) need to be kicked >> out (buggy firmware, ...) >> * can't rely on any special userland tweaks > > Show an example why either of the above is needed in your case and > tell what is the exact issue.
In the specific APU case (note that my proposal is a generic mechanism for a whole class of similar usecases), *some* bios versions already enumerate *some* gpios, later versions already enumerate some LEDs but different naming than the driver's, etc., etc. (at time of writing the driver, apu bios didn't support any of that). For preventing conflicts and consistency between all bios versions, it's IMHO better to just remove the conflicting devices if they're enumerated by bios.
> Yes, that driver represents hardware. MFD already has some support for > composite devices. We have the auxiliary bus for some other > interesting cases, etc. Depending on the hardware in question you have > to choose a proper bus and locking (access synchronisation) schema.
Yes, but similar to the apu case, I'd like to be able describe those devices just by a DT (instead of lots of C code).
>> Those things could be expressed via DTS, so we don't need to write >> individual drivers anymore. > > It seems you are trying to create something like "universal quirk". > Brave idea, but from my experience a fiasco is what will be out of it. > The hardware has a lot of different issues and levels of issues and it > is close to impossible to describe everything possible and predict the > future... Good luck!
Dont worry, I don't try create some one-fits-all-solution. It's just for a specific class of use cases, where we need additional devices that can't be (reliably) enumerated via firmware or buses.
>> * need to split the information into several places (instead of having >> all in one DTS) >> * need to have one separate module board, or merge the dmi tables. > > Have no idea what you are talking about here, sorry.
Well, for now I have the matching criteria (DMI strings) within the DT - don't need any additional code per board. For using the existing mechanisms, I would need to move that out into a separate .c file, something I'd like to avoid.
>> My goal is having everything that describes a board into one DTS >> (source) file. > > I'm confused, you are talking about non-DT platforms in the > cover-letter and now you are talking about DTS. AFAIK DTS allows you > to put everything in one source.
Nope, I'm using DT *in addition* to firmware data (ACPI), for things that arent't properly described by firmware. The idea goes like this:
* walk through all available board descriptions (builtin dtbs) * check whether board matches critiera given in the DT * if match: * kick out blacklisted devices * populate devices from the DT
The idea is just not having to write lots of C code for cases like the apu boards anymore, but reuse existing DT infrastructure for that and also heavily reduce code size this way (for apu case, the dtb is around 2kb, while the existing driver is around 17kb)
--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
| |