Device tree overlay - dynamic load and unload

[sbp]

Hi

Is it possible to load and unload a device tree dynamically, so that it can be manipulated without a reboot?

I have read that at least the BeagleBone Black seems to allow such a behaviour http://events.linuxfoundation.org/sites ... elce14.pdf and here (read the section about Device tree ovelay) http://elinux.org/BeagleBone_and_the_3.8_Kernel

The reason for my interest is because we are updating piCorePlayer to the new kernel.
The player allows the user via a WEB-GUI to select their I2S-DAC from a drop-down list.
In the previous kernels we have managed this by loading/unloading modules, but in the new kernel (3.18.5) it seems like we will have to manipulate the Device tree overlay according to the selection.
It would be nice if a reboot could be avoided, so please advice how to do that.

See below:

[elatllat]

As noted in /boot/overlays/README you could use device_tree= to use the "old way of doing things" and hope this implementation of Device Tree overlays (a step backward in usability) will be updated to permit loading overlays from config.txt without a reboot.

[PhilE]

Yes, I think dynamic Device Tree is something we could support in future, but it is some way off.

Until then, there shouldn't be anything you can do without DT that you can't do with it, unless the specific drivers have some DT detection logic that gets in the way. I suggest you:
* Blacklist all of the audio board drivers. You are probably doing this already.
* Include overlays for all of the audio boards in your config.txt:

Code: Select all

dtoverlay=hifiberry-dac
dtoverlay=iqaudio-dac
...

* Use the same code you have now for loading the modules when you need them.

[elatllat]

...there shouldn't be anything you can do without DT that you can't do with it...

Except adding a new hardware specification without rebooting right?

/boot/overlays/README said "it is advisable to only enable interfaces if they are needed" with no reason given.
Why is it advisable? (less memory usage, faster kernel, less chance of overlays conflict, all of the above, some other reason)
would adding all interfaces and blacklisting the kernel modules be similar to "the old way of
doing things"?

[PhilE]

If you enable all interfaces then you restrict applications from using those pins for GPIO. Device Tree and the pinctrl drivers allow an extra level of checking for pin contention. Although this may seem tedious to some it does eliminate a whole class of hard-to-diagnose configuration errors - the modules will flat-out refuse to load.

But yes, enabling "all" interfaces (but not really all - you don't want to be enabling the VideoCore I2C unless you really need to because you will scupper the camera - use i2c_arm,i2s,spi) and blacklisting the modules will get you back to where you were. If you want to use the modules that previously relied on platform devices being created by the board support code then you will need to load the corresponding overlays, but as I said you can just load them all and blacklist the modules as before.

Of course, what you can do with DT that you couldn't do before is add a new platform device without rebuilding your kernel...

[DougieLawson]

As noted in /boot/overlays/README you could use device_tree= to use the "old way of doing things" and hope this implementation of Device Tree overlays (a step backward in usability) will be updated to permit loading overlays from config.txt without a reboot.

That's the coward's way out and could leave you with a system that can never be upgraded.

It's better if we can persuade everyone to stick with DT and work through the bugs. That improves the new function for everyone. Considering this was brand new at the start of December and now part way through February it's mostly working for most folks on old and shiny new hardware has to point to it being good solid code that's going to be very stable in future kernels. It doesn't take long to reboot a Raspberry Pi.

[sbp]

Yes, I think dynamic Device Tree is something we could support in future, but it is some way off.

Until then, there shouldn't be anything you can do without DT that you can't do with it, unless the specific drivers have some DT detection logic that gets in the way. I suggest you:
* Blacklist all of the audio board drivers. You are probably doing this already.
* Include overlays for all of the audio boards in your config.txt:

Code: Select all

dtoverlay=hifiberry-dac
dtoverlay=iqaudio-dac
...

* Use the same code you have now for loading the modules when you need them.

Thanks, It is working fine. So for now we just enable all the I2S-audio DACs via DT and then make the selection in the same way as before.
I hope the dynamic loading and unloading of device tree overlay is coming as it seems to be the correct way to do it.

Steen

[PhilE]

The dynamic overlay support hit the mainline kernel with 3.19 a few days ago, so the odds are improving.

[sbp]

Hi
I noticed that Dynamic loading/unloading of device tree is now included in the 4.0.y kernel (and maybe even before that).

So my question is - can it be used already? and if possible what would be the correct syntax?

Regards
Steen

[PhilE]

Yes, there is support for dynamic loading/unloading, but so far there is no user space interface. There is a patch providing a configfs interface but it isn't merged, and it will need some commands to make it easier. Plus, not all modules will be happy to be unloaded, so it will need a lot of testing.

[mikelangeloz]

Any news on this? That would be definetely very interesting, especially for loading i2s dacs overlays on userspace...

[DirkS]

Any news on this? That would be definetely very interesting, especially for loading i2s dacs overlays on userspace...

Dynamic DT was introduced in the 4.4 kernel.
Check out the command line progs dtoverlay and dtparam (enter without arguments to get some help).

Not all drivers react kindly to being loaded / unloaded in this way though.