[RFC][DNM]DTS service nodes #23394
[RFC][DNM]DTS service nodes #23394
Conversation
Currently, DTS is used to generate device nodes only. However, there are software services which are really close to devices (since they require certain device to work) and thus could be exposed through DTS directly. So adding the basic service node descriptor. Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
It is a service providing a console access through a UART port. Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
|
All checks are passing now. Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages. |
|
@tbursztyka not sure I follow what info you are trying to encode and extract from the DTS for this purpose. |
|
If we go this way we might need to reconsider rewriting this section a bit: Since it will no longer be true. |
|
@galak check mbolivar's issue #22545 this won't be really reliable without exposing all build time init level/prio based objects (which are all struct device). There will be nothing to help the user setting the level/prio properly by hand if, depending on the device tree, the dependency devices (uart in case of uart console) have level/prio varying depending on the board/config/build/etc... Getting rid of pre_kernel_<1/2> will not be possible either. @carlescufi DTS could help to set some options, like the uart dev name being used for the uart console. But I would not switch all the options to DTS. That said, I don't think the mentioned documentation needs to be updated: for instance if the user unset CONFIG_UART_CONSOLE via menuconfig, the uart console service won't be built anyway. Note as well that some services are in fact a mix of hardware and software service, such as the rtt based console. The line is quite blurry sometime. |
It provides a console through UART0. Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
9872223 to
fcf3097
Compare
The fact that they are all struct device seems to be a historical artifact. I'm not sure I agree we should be putting software objects into DT. That doesn't seem to be what it's for. |
Indeed. However, because of dependency between devices and such software services (in this example: uart console needs the uart device to be initialized first), you must keep all of them in the same initialization ordered list anyway. Unless you start to bloat things up (having some slist or else), but this is exactly what I don't want to do. |
|
I think this deserves some measurement. Allocating an entire struct device for a single function is also a waste of space. |
On that we agree. I already started a few days ago to rework struct device and all to fix that issue. |
Do you have any code to share? Now that #23245 is basically ready to go in and I have some bandwidth back, I would like to start discussing devicetree.h vs. device.h issues more seriously. |
|
@mbolivar-nordic I have a draft still in wip state. Anyway, let me close this RFC as it's a wrong approach altogether. |
If you have a branch you can post I would be very curious to see it with a full understanding that it's WIP. If not, any idea when you will have one? |
|
just look at my drafts, I updated #22941 with references there |
|
Let's close this one, as it won't go any further. |
This is an attempt to expose "software services" as DTS nodes.
Software services are mostly all these code being initialized through SYS_INIT() (it currently creates a struct device, but most of them are just not devices per-se)
Exposing them is a primary requirement for fixing #22545
(Or then we will have a problem with all these hardcoded leve/prio used on SYS_INIT())
So I took a quick example with the UART console for qemu_x86, so you'll get an idea.
I put it into a services {} .dtsi root node, it has nothing to do in soc {}, as it is not a hardware device being exposed.