Support circular DTS node references #57708
Comments
danieldegrasse
added
Enhancement
|
I want to make clear that especially with my upcoming departure from Nordic, I have no plans to work on this any time soon. I also want to point out that @gmarull 's close collaboration will be needed, since any solution needs to be compatible with what we want for #22545, and that's really in the device model |
It turns out that I would be glad to know more about the model you had in mind, as I wish to do the same for implementing UVC. |
|
It looks like fetching the compatible: blah,blah
child-binding:
child-binding:
properties:
remote-endpoint:
type: phandle
required: trueThen the devicetre actually started to validate the |
|
Further insights by tinkering with Given And the given This works
This works
This fails
With the error that the Maybe this is the same bug. At least, in my case, the temporary workaround is to set a YAML binding rule like |
I am not a devicetree expert- but my understanding is that by only adding the |
|
What are the actual use cases of circular references in DT? Ie why do nodes need to reference each other, if their corresponding devices truly both depend on each other being initialized, then it seems impossible to initialize either correctly? In that case it seems like it's not a problem from DT, but from some part of the software architecture being nonsensical, and don't see how allowing this in DT would solve a problem, it would only reveal the more fundamental problem with the software design. Otherwise, is it reasonable to decide that DT nodes with circular references just would not imply dependencies in either direction? or maybe even have the same init priority (doesn't seem strictly necessary in all cases, though)? |
|
If there is a convention that building pipelines is always done with the source referring the sink (or the other way around), then there might not need any need for going the other direction... Following the flow of the data down the pipeline seems more intuitive: data is pushed from the source to the sink whenever it arrives (rather than pulled by the sink). That might depend if controls need to be propagated in both direction: how is the pipeline driven. |
|
It looks like there is a guard against circular dependencies in |
|
I encountered the same issue while developing a custom interlocking mechanism that requires circular references. Has anyone tried to fix this? |
Add macros to access the port/endpoint constructs from drivers and
application.
Devicetrees currently use "port { endpoint { ... }; };" to describe
interconnection between devices. With introduction of the
"remote-endpoint-label = string" syntax, it is now possible to
describe circular dependencies until zephyrproject-rtos#57708 is addressed.
Signed-off-by: Josuah Demangeon <[email protected]>
Add macros to access the port/endpoint constructs from drivers and
application.
Devicetrees currently use "port { endpoint { ... }; };" to describe
interconnection between devices. With introduction of the
"remote-endpoint-label = string" syntax, it is now possible to
describe circular dependencies until zephyrproject-rtos#57708 is addressed.
Signed-off-by: Josuah Demangeon <[email protected]>
|
I agree with |
|
The workaround deployed for video systems for the bi-directional endpoint@123 {
- remote-endpoint = <&peer_node>;
+ remote-endpoint-label = "peer_node";
};Then, this macro is used in devicetree to retrieve the other node, instead of a phandle: -DT_PHANDLE(remote_endpoint)
+DT_NODELABEL(DT_STRING_TOKEN(node, remote_endpoint_label)) |
|
Yes, what I was saying above appears to be that two nodes requiring each other to initialize first is nonsensical, which is still true, but determining initialization priority is not the only use of DT, so having circular references could still be desirable for other reasons. |
|
Peer-to-peer relationships are the main example in my experience where this would be useful. In situations like this, you have some IP blocks that can be initialized independently, but have some set of peers in a larger 'network' or 'graph' in the system as a whole. The entire graph is something you want to initialize after the init routines are done for the individual IP blocks themselves. You don't want to even bother initializing portions of the network where one or more of the peers failed to init individually. The simplest/stupidest way to do this would be to add an additional key to the bindings language that says 'phandles in this property do not imply a dependency', like and then you would be able to write: How to implement this? You'd modify this bit of the idea would be to skip the edges from being added if the properties were marked as not adding dependencies. |
Is your enhancement proposal related to a problem? Please describe.
Zephyr's current devicetree infrastructure does not support devicetree nodes having circular references. A few examples of this:
"Classic" circular reference
Parent referencing child- this is also a circular reference
Any of these devicetrees will fail to compile, as the current devicetree scripting cannot create dependency ordinal numbers for all devicetree nodes when a circular reference exists. The key issue here is that we need to determine which of these nodes has a higher initialization priority, which is not clear from the circular reference.
Describe the solution you'd like
A method to support circular references in devicetree- One method that has been proposed by @mbolivar to handle this is treating circular references as a block of strongly connected components: https://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm.
Additional context
While this issue will affect any devicetree, the core driver behind the request is a way to support the sometimes complicate devicetree infrastructure needed to accurately describe display pipelines. One such example:
cc @gmarull
The text was updated successfully, but these errors were encountered: