Devicetree config generation
Carles Cufi
Hi Petr,
Yes, this has been talked about repeatedly over the last couple of years. You can find most of the issues and PRs related to the work that has been done so far in this umbrella issue: https://github.com/zephyrproject-rtos/zephyr/issues/8499
In the dev-review meeting on Thursdays we are currently discussing DeviceTree-related topics, and code generation, and in particular to solve the pinctrl/pinmux problem but also for instancing, is one of those topics. Kumar Gala (on copy) drives the overall DT efforts within Zephyr. Feel free to join the meeting or comment on the multiple issues or Pull Requests on GitHub to drive the feature forward.
Regards,
Carles
From:
<users@...> on behalf of "Petr Buchta via Lists.Zephyrproject.Org" <cz7asm=googlemail.com@...>
Hi, I just started looking around Zephyr and coming from Linux world I really like the idea of using Devicetree for driver configuration.
I noticed, however, that config generation that enables particular low level driver must be dobe manualy using Kconfig. I know that this is the same in Linux but given the way Zephyr leverages DT I would think that, in this case, config generation based on DT could simplify things.
For example looking at led_strip driver code samples, there are projects that duplicate almost all code only to bind to a different low level driver, like samples/drivers/apa102 and samples/drivers/ws2812. They even have the same prj.conf. If the DT processing could provide things like mapping "enabled device compatible string" -> "LL driver CONFIG_xx parameter", then there would be no need for code duplication and all the samples utilizing same driver api could share same project.
Is this something that's been considered but abandoned for a reason?
Thanks, Petr |
|
Petr Buchta <cz7asm@...>
Hi, I just started looking around Zephyr and coming from Linux world I really like the idea of using Devicetree for driver configuration. I noticed, however, that config generation that enables particular low level driver must be dobe manualy using Kconfig. I know that this is the same in Linux but given the way Zephyr leverages DT I would think that, in this case, config generation based on DT could simplify things. For example looking at led_strip driver code samples, there are projects that duplicate almost all code only to bind to a different low level driver, like samples/drivers/apa102 and samples/drivers/ws2812. They even have the same prj.conf. If the DT processing could provide things like mapping "enabled device compatible string" -> "LL driver CONFIG_xx parameter", then there would be no need for code duplication and all the samples utilizing same driver api could share same project. Is this something that's been considered but abandoned for a reason? Thanks, Petr |
|