Talk:Frank's Evolving Overlay Thoughts
|Thread title||Replies||Last modified|
|DT Overlays for mikroBUS||0||12:19, 14 April 2020|
I've been trying to end-run device tree overlays to get mikroBUS devices. The goal is to have Click boards only require a minimal descriptor that can be included on an EEPROM on the boards or provided at run-time via ConfigFS. mikroBUS is much more constrained than Cape Bus, so I thought this could be a more reasonable problem to solve.
We had a GSoC student use gbsim to load devices dynamically. The challenge is that many device drivers require more platform data than are provided by default by the bus driver. I thought that since these things worked classically, that it should be easy enough to provide the additional platform data in a mikroBUS bus driver that knows where things like IRQs and other needs of device drivers should be defined by default, since mikroBUS includes those resources as well. This does seem to work reasonably for a large class of device drivers.
However, I'm wondering if we aren't chasing our tail a bit. It seems to me that many, many new device drivers simply rely on device tree elements to get the data they need to be configured. So, even if we evolve the mikroBUS bus driver to know about all of these device drivers, it would need to generate of_node fragments on-the-fly to be able to start those device drivers. Is that what you see as well?
Therefore, it seems like we may be back in a situation where adding dt overlay fragments to the EEPROMs might continue to be the best option.
I don't think the bootloader is a great option, but I'll certainly explore it. Development of the overlays will be a real nightmare that way.
Assuming the answer is not applying the overlays in the boot loader, do you think something like a mikroBUS would be constrained enough that we could come up with an upstream way to apply overlays included in the EEPROMs? It would only touch subnodes of mikroBUS and shouldn't even need to reference outside of it as all of the references should be made local to that bus.
Otherwise, do you have any other suggestions to provide sufficient data to configure I2C, SPI, UART, PWM, ADC, and GPIO device drivers?