Re: RFC: oftree based setup of composite board devices
On Wed, Feb 24, 2021 at 05:14:10PM -0600, Frank Rowand wrote: > On 2/24/21 7:00 AM, Enrico Weigelt, metux IT consult wrote: > > 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. > > Since you have persisted, a more referenced and emphatic "no" to mixing ACPI > and devicetree: > > https://elinux.org/Device_Tree_Linux#mixing_devicetree_and_ACPI The 'no' is for mixing the 2. Despite the no, it's been happening anyways. That's mostly been the reusing DT bindings in ACPI tables. I won't review such bindings if I realize that's what they are, but usually that's not evident. This is a bit different I think where both ACPI and DT are used, but they are totally disjoint. I don't have any issue with that. Why would we want to force 2 different firmware descriptions for something otherwise independent of the base system's firmware. Maybe that's not exactly the case here, but the same changes to the DT code are needed (unless you have a better solution for my example than multiple roots). If someone wants to implement the changes that align with what I want, then I don't really care what their motivation is. Rob
Re: RFC: oftree based setup of composite board devices
On 2/24/21 7:00 AM, Enrico Weigelt, metux IT consult wrote: > 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. Since you have persisted, a more referenced and emphatic "no" to mixing ACPI and devicetree: https://elinux.org/Device_Tree_Linux#mixing_devicetree_and_ACPI > > 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. So you want to use devicetree data to fix broken ACPI data. Again, why don't you use data in an ACPI format to fix broken ACPI data? -Frank > > 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
Re: RFC: oftree based setup of composite board devices
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 i...@metux.net -- +49-151-27565287
Re: RFC: oftree based setup of composite board devices
On Mon, Feb 15, 2021 at 3:15 AM Frank Rowand 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 > > 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
Re: RFC: oftree based setup of composite board devices
On 2/8/21 5:48 PM, Rob Herring wrote: > +Johan H > > On Mon, Feb 8, 2021 at 4:22 PM Enrico Weigelt, metux IT consult > 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. 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 board >> 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 >
Re: RFC: oftree based setup of composite board devices
On 11.02.21 12:41, Andy Shevchenko wrote: Hi, On Thu, Feb 11, 2021 at 1:15 PM Enrico Weigelt, metux IT consult 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
Re: RFC: oftree based setup of composite board devices
On Thu, Feb 11, 2021 at 1:15 PM Enrico Weigelt, metux IT consult 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 https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html Please, please, read documentation beforehand! > 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? > There're few things I don't know how to solve w/ overlays: > > * 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. > >> The approach can be easily be extended to other kinds of composite devices, > >> eg. PCI cards or USB dongles. > > > > What do you mean? PCI and USB are self-enumerated. What's wrong with them? > > In general yes, but of course you need drivers for them. Sometimes those > devices are composites of other devices, wired up in some special way. > Traditionally, we'd need to write a special driver that just don't do > much more than instantiating other drivers. 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. > 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! ... > * 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. > 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. -- With Best Regards, Andy Shevchenko
Re: RFC: oftree based setup of composite board devices
On 10.02.21 11:30, Andy Shevchenko wrote: Hi, 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 ? You already know my apu board driver - that's my first example usecase. There're few things I don't know how to solve w/ overlays: * 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 The approach can be easily be extended to other kinds of composite devices, eg. PCI cards or USB dongles. What do you mean? PCI and USB are self-enumerated. What's wrong with them? In general yes, but of course you need drivers for them. Sometimes those devices are composites of other devices, wired up in some special way. Traditionally, we'd need to write a special driver that just don't do much more than instantiating other drivers. Those things could be expressed via DTS, so we don't need to write individual drivers anymore. Yet some drawbacks of the current implementation: * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based modprobing anyways) What?! https://lwn.net/Articles/233385/ `git grep -n 'MODULE_DEVICE_TABLE(dmi'` Shame on me, I really must have missed that all the time, thanks for the hint. But that has some drawbacks in my case: * 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. My goal is having everything that describes a board into one DTS (source) file. --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 i...@metux.net -- +49-151-27565287
Re: RFC: oftree based setup of composite board devices
On 09.02.21 00:48, Rob Herring wrote: Hi, 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'm not convinced compiled in is the mechanism we want. To make it clear, I'm talking of DTBs compiled into the ofboard driver (which itself can be a module). And yes, that's pretty much what I want. It's meant for drop-in replacement of composite board drivers, in cases where this driver doesn't do more than initializing other drivers. Therefore, it should work without any special userland actions, and it should put all board specific stuff into dtb. 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. Yes, that's also on my 2do list (eg. adcs behind some usb-i2c dongle) 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 already investigating this idea. Actually, I'm also thinking a bit further, whether for the future it could make sense converting the acpi tables into oftree at runtime. Not sure whether it's good idea, but maybe we could consolidate the platform driver probing into one, more generic mechanism. 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. In my usecase neither would not be a good idea, because: a) on common machines (eg. pc's) we can't touch firmware easily (if we could, we wouldn't need those board drivers in the first place - we'd just fix the firmware :p) b) I'd like to have my new mechanism as a drop-in replacement for existing drivers, reduce the init boilerplace to just a piece of dt. Don't wanna force users to do userland changes on a kernel upgrade. Userland-driven approach IMHO makes sense for extra devices behind some interfaces, that itself is probed otherwise, and we don't know hat the user has attached to it (eg. USB->SPI adapter). * can't reconfigure or attach to devices outside the individual DT's (eg. probed by PCI, etc) Not sure I follow. Let's take an example: I've got a PCI card with a bunch of generic chips, where we already have drivers for. A traditional driver would be probed the usual pci way, and then instantiate sub-devices directly. That's lots of boilerplace code, whose semantics could be described entirely via DT. In order to make that work, I need two things: 1. create a pci device instance (when the card is found) 2. instantiate all sub-devices with the card device as parent Another problem: I've got extra devices behind an interface that itself already is enumerated by firmware or some bus, but the extra devices aren't. (eg. acpi already enumerates some gpio's, but not what's connected to them, eg. leds, keys, ...). In this case, I somehow need to get these parent devices into my DT's scope, so the additional devices can refer to them. --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 i...@metux.net -- +49-151-27565287
Re: RFC: oftree based setup of composite board devices
On Tue, Feb 9, 2021 at 12:25 AM Enrico Weigelt, metux IT consult 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. > > 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? > 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 board > family based on device tree. Sounds weird, but let's see... > The approach can be easily be extended to other kinds of composite devices, > eg. PCI cards or USB dongles. What do you mean? PCI and USB are self-enumerated. What's wrong with them? > Yet some drawbacks of the current implementation: > > * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based >modprobing anyways) What?! https://lwn.net/Articles/233385/ `git grep -n 'MODULE_DEVICE_TABLE(dmi'` > * can't reconfigure or attach to devices outside the individual DT's >(eg. probed by PCI, etc) -- With Best Regards, Andy Shevchenko
Re: RFC: oftree based setup of composite board devices
+Johan H On Mon, Feb 8, 2021 at 4:22 PM Enrico Weigelt, metux IT consult 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'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. > 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 board > 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. > 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
RFC: oftree based setup of composite board devices
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. 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 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 board family based on device tree. 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) * can't reconfigure or attach to devices outside the individual DT's (eg. probed by PCI, etc) have fun, --mtx
