Am 19.05.2014 17:49, schrieb Jon Loeliger:
[ Crap. Sorry about the duplicate post. Stupid HTML; didn't hit the
lists. -- jdl ]
What's still questionable about the patches for dtc is if dependencies to
devices and not just drivers should be included in the new property
dependencies too.
I don't think the DTC should have any semantic knowledge of why these
dependency arcs are being added to the graph. Sure, it could be that
different types of arcs are added, and that the total dependency graph
travels multiple such arc types to obtains some valid topological sort,
but the DTC itself should just not care.
I will remove those policies (which means including all dependencies).
As said below, I already thought it was evil premature optimization (I
did in order to make the graph a bit smaller and to save some bytes).
(No date, it isn't a paid project so I will do it whenever I feel good
to do so).
After saying that, there are likely semantic checks that could be added to
ensure some policy about those arcs was followed. Separate the
implementation from the policy. There is already plenty of discussion
down that line within the DTC ongoing.
Hmm, discussion about what? Those dependencies or about semantic checks?
Btw., if someone has a problem with the necessary time to do the
topological sort at boot time (needs a few ms on a single core omap with
600 MHz), there could be an additional option to add a new property
which includes the whole (already topological sorted) list. That
wouldn't be much effort. But currently I don't think any DT enabled
device is in need of having to avoid doing the topological sort itself.
Regards,
Alexander Holler
HTH,
jdl
On Mon, May 19, 2014 at 7:35 AM, Alexander Holler <holler@xxxxxxxxxxxxx>wrote:
Am 17.05.2014 14:16, schrieb Tomasz Figa:
References to phandles of parent or child nodes will not be added to this
property, because this information is already contained in the blob (in
the
form of the tree itself).
I wonder if we shouldn't be including them too for consistency related
reasons, so we have all the necessary information in one place.
References to child nodes are great recipes for cycles, though...
No strong opinion, though, just an idea.
As said, they are already in the tree itself. And they are already
included in the graph (these are the black edges), so they just don't
appear in the property dependencies.
No dependencies to disabled nodes will be added.
Same here. IMHO it might be wise to let the parsing entity (e.g. kernel)
decide whether to ignore a dependency to disabled node or not.
Otherwise, I like the simplicity of compile-time dependency list
creation. Quite a nice work.
Thanks.
What's still questionable about the patches for dtc is if dependencies to
devices and not just drivers should be included in the new property
dependencies too. My current assumption is that all devices belonging to
one and the same driver don't have dependencies between each other. In
other words the order in which devices will be attached to one and the same
driver isn't important. If that assumption is correct it would be possible
to just attach all devices belonging to a driver after the driver was
loaded (also I haven't that done in my patches).
And thinking about that again, I think I was wrong and doing so have been
some kind of evil premature optimization I did in order to spare a few
dependencies/edges. But changing this can done by removing a few lines in
the code for dtc (patch 1).
Regards,
Alexander Holler
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
