[Q] devicetree overlays

[Q] devicetree overlays

[Sven Van Asbroeck]

Pantelis, Frank,

A quick question about the state of devicetree overlays. There don't seem to
be many in-kernel overlay users (rcar and fpga only?). Does it make sense for
new projects to use them?

My situation is this: I have hardware which consists of several modules.
Knowledge about the type and location of these modules is located in an
on-board eeprom.

So now I need to assemble a devicetree, by puzzling various 'blobs' together.
This could be done in the bootloader, but also by a rcar-like driver, which
queries the eeprom and inserts devicetree fragments/overlays into a live kernel.

A couple of questions:
- are devicetree overlays here to stay? (given that there are 2 in-kernel users)
- does it make sense to solve the modular devicetree problem in a rcar-like
  fashion?
- is there perhaps a more canonical / idiomatic way to solve this?

Sven

Re: [Q] devicetree overlays

[Frank Rowand]

On 4/16/20 9:46 AM, Sven Van Asbroeck wrote:
> Pantelis, Frank,
> 
> A quick question about the state of devicetree overlays. There don't seem to
> be many in-kernel overlay users (rcar and fpga only?). Does it make sense for
> new projects to use them?

Run time overlay apply and run time overlay remove from user space are not
supported in the mainline kernel.

rcar is grandfathered in.  fpga use is very careful and done in a somewhat
restricted manner.

There is a desire for run time overlay apply and run time overlay remove
to become more complete and more robust.  Improvements are slowly moving
forward.

The best way to use overlays at the moment is to apply them before booting
the Linux kernel, such as having u-boot apply them.

My opinion is that run time overlay apply and run time overlay remove will
always be more fragile and less well supported than pre-boot overlay apply,
and thus run time usage should be avoided if possible.

You can read more details about the status and direction of overlays at:

   https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts


> 
> My situation is this: I have hardware which consists of several modules.
> Knowledge about the type and location of these modules is located in an
> on-board eeprom.

Does the eeprom provide an ID, from which an overlay blob can be inferred?
Or is "the type and location of these modules" more explicit, such as
path of the blob in a filesystem?

> 
> So now I need to assemble a devicetree, by puzzling various 'blobs' together.
> This could be done in the bootloader,

Do this, if at all reasonably possible.

> but also by a rcar-like driver, which
> queries the eeprom and inserts devicetree fragments/overlays into a live kernel.

Don't do this.

> 
> A couple of questions:
> - are devicetree overlays here to stay? (given that there are 2 in-kernel users)

I expect devicetree overlay run time support to remain for fpga.  I am optimistic
that we will add support for other use cases in an incremental roll out of
functionality.  But this is not happening quickly.


> - does it make sense to solve the modular devicetree problem in a rcar-like
>   fashion?

No.

> - is there perhaps a more canonical / idiomatic way to solve this?

Yes, apply the overlays before booting.

> 
> Sven
> 

Re: [Q] devicetree overlays

[Sven Van Asbroeck]

Hello Frank, thank you for sharing your expertise. Much appreciated !

On Mon, Apr 27, 2020 at 4:26 PM Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 4/16/20 9:46 AM, Sven Van Asbroeck wrote:
> > My situation is this: I have hardware which consists of several modules.
> > Knowledge about the type and location of these modules is located in an
> > on-board eeprom.
> >
> > So now I need to assemble a devicetree, by puzzling various 'blobs' together.
> > This could be done in the bootloader,
>
> Do this, if at all reasonably possible.
>
> > - is there perhaps a more canonical / idiomatic way to solve this?
>
> Yes, apply the overlays before booting.

Re: [Q] devicetree overlays

[Enrico Weigelt, metux IT consult]

On 16.04.20 16:46, Sven Van Asbroeck wrote:

Hello folks,

> My situation is this: I have hardware which consists of several modules.
> Knowledge about the type and location of these modules is located in an
> on-board eeprom.

I've got a somewhat similar use cases, but not necessarily on DT-native
platforms:

a) composite devices that are probed via PCI or DMI and just instantiate
   a bunch of other (more generic) devices.

   For example the  APUv2/3/4 board driver: it eg. instanciates the
   gpio-amd-fch driver first, and then binds specific gpio lines to
   appropriate functions, eg. reset key (input), LEDs, ...

b) I2C devices behind an USB-based bus adapter.

In both cases it would be nice to have the actual device configuration
written as a DT snippet, which just needs to be loaded.

Let me know, if anybody has an idea how to do that.


--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

Re: [Q] devicetree overlays

[Sven Van Asbroeck]

Hello Enrico,

On Fri, Aug 7, 2020 at 7:27 AM Enrico Weigelt, metux IT consult
<info@metux.net> wrote:
>
> In both cases it would be nice to have the actual device configuration
> written as a DT snippet, which just needs to be loaded.
>

I believe you're asking: "how do I associate device tree nodes to
devices on a dynamically discoverable bus such as USB or PCI" right ?

I believe that already exists. You can describe the _expected_ pci or
usb topology in the
devicetree. If a device gets detected in a spot on the bus described
in the tree, that
snippet will be automatically associated with this device.

How to for usb:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/usb/usb-device.txt?h=v5.8

How to for pci:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/pci.txt?h=v5.8

For example, associate a mac address to an ethernet controller
on a pcie bus via the devicetree.
"reg" (which describes pcie topology/address) still needs filling in.

&pcie {
        host@0 {
                #address-cells = <3>;
                #size-cells = <2>;
                reg = <0 0 0 0 0>;
                bcm5778: bcm5778@0 {
                        reg = <0 0 0 0 0>;
                        mac-address = [CA 11 AB 1E 10 01];
                };
        };
};

Re: [Q] devicetree overlays

[Enrico Weigelt, metux IT consult]

On 07.08.20 16:17, Sven Van Asbroeck wrote:

Hi,

> I believe you're asking: "how do I associate device tree nodes to
> devices on a dynamically discoverable bus such as USB or PCI" right ?
> 
> I believe that already exists. You can describe the _expected_ pci or
> usb topology in the
> devicetree. If a device gets detected in a spot on the bus described
> in the tree, that
> snippet will be automatically associated with this device.
> 
> How to for usb:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/usb/usb-device.txt?h=v5.8
> 
> How to for pci:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/pci.txt?h=v5.8

Thanks, that looks good.

But I've still got another problem: how can I use DT along w/ ACPI ?

The scenario goes like this:

* machine boots and probes normally w/ ACPI
* device is detected via USB, PCI, DMI, etc -> driver gets active
* driver loads (or carries) a DT snippet
* devices on the bus are instantiated via this DT snippet

(driver could also be some udev vodoo)

Example a:

* generic usb i2c dongle w/ some i2c devices attached behind it
* config (or DT snippet) somewhere in the FS

Example b:

* x86 board driver (eg. apu2/3/4), probed via DMI
* just instantiates a bunch of generic drivers and wires up
  devices (gpio, leds, keys, ...)


Do you think we can already do that ?
Otherwise, what has to be done to achieve that ?	


--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

Re: [Q] devicetree overlays

[Sven Van Asbroeck]

On Wed, Aug 12, 2020 at 9:28 AM Enrico Weigelt, metux IT consult
<lkml@metux.net> wrote:
>
> But I've still got another problem: how can I use DT along w/ ACPI ?
>

That's a very good question. I focus on arm, so I'm unfamiliar with ACPI.
Hopefully someone with ACPI knowledge can chime in.

Re: [Q] devicetree overlays

[Frank Rowand]

On 2020-08-12 08:27, Enrico Weigelt, metux IT consult wrote:
> On 07.08.20 16:17, Sven Van Asbroeck wrote:
> 
> Hi,
> 
>> I believe you're asking: "how do I associate device tree nodes to
>> devices on a dynamically discoverable bus such as USB or PCI" right ?
>>
>> I believe that already exists. You can describe the _expected_ pci or
>> usb topology in the
>> devicetree. If a device gets detected in a spot on the bus described
>> in the tree, that
>> snippet will be automatically associated with this device.
>>
>> How to for usb:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/usb/usb-device.txt?h=v5.8
>>
>> How to for pci:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/pci.txt?h=v5.8
> 
> Thanks, that looks good.
> 
> But I've still got another problem: how can I use DT along w/ ACPI ?

Some answers from https://elinux.org/Device_tree_plumbers_2016_etherpad

Question: what about device tree on x86

    Answer: there's already support for DT on x86. But, we should not mix DT and ACPI.


A controversial topic is ACPI overlays (putting DT in ACPI or ACPI in DT).

    Don't want to have drivers that get part of their info from ACPI and part from DT. That's nuts.


Question: Can you have ACPI and DT at the same time on x86?

    Answer: No. Some ARM64 systems have support for both ACPI and DT, but the system selects one to use at runtime. They are not used at the same time.
    You can run the DT unit tests on x86.


-Frank

> 
> The scenario goes like this:
> 
> * machine boots and probes normally w/ ACPI
> * device is detected via USB, PCI, DMI, etc -> driver gets active
> * driver loads (or carries) a DT snippet
> * devices on the bus are instantiated via this DT snippet
> 
> (driver could also be some udev vodoo)
> 
> Example a:
> 
> * generic usb i2c dongle w/ some i2c devices attached behind it
> * config (or DT snippet) somewhere in the FS
> 
> Example b:
> 
> * x86 board driver (eg. apu2/3/4), probed via DMI
> * just instantiates a bunch of generic drivers and wires up
>   devices (gpio, leds, keys, ...)
> 
> 
> Do you think we can already do that ?
> Otherwise, what has to be done to achieve that ?	
> 
> 
> --mtx
>