[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-discuss] Initialization order of nodes in device tree

From: Alexei Colin
Subject: [Qemu-discuss] Initialization order of nodes in device tree
Date: Wed, 22 Aug 2018 17:44:14 -0400
User-agent: Mutt/1.10.1 (2018-07-13)

Hi, what is the recommended way to control the initialization order of
nodes in the device tree (that is, encode dependencies)?

I am working with Xilinx fork of Qemu (circa v2.11), I didn't
check yet if the device tree parsing logic changed in master.

In the following text, visited != initialized. From tracing ftd_init_*
parsing, my understanding is that Qemu walks the tree depth-first while
initialization seems to happen in breadth-first order.  Initialization
of a visited node blocks (using fdt_init_yield) until its parent has
been initalized. A parent is initialized after its children have been
visited. Initialization of the parent unblocks the initializations of
its children, but initilization of the parent's children does not
procede, until the parent's siblings have been intialized.

I would not ask this question if the initialization were also
depth-first: once a parent has been initialized, first resume the
children's initialization, before the siblings' initialization.
But that's not how it works, as far as I understand.

How do you recommend to encode dependencies between nodes?

One way is to make B a child of A whenever A must be initialized before
B.  That's problematic when my device tree is trying to reflect the bus
hierarchy of the hardware, not the same relationship as initialization
order. Also, leads to spaghetti device tree, where controllers are
children of caches, and similar nonsense.

Another way might be to order by moving nodes down by level, keeping the
same ancesto: e.g. if B is a child of A and Y, a child of X, depends on B,
then add fake middle node between X and Y to make Y a grandchild of X.
Then, I think B will be initialized before Y, because "B" is of a
younger generation. Correct?

Or, is the expectation that each model code should block using
fdt_init_yield? E.g. yield until the node it tries to link to has been
initialized by checking that node's fdt_init_get_opaque()?  Or is there
some other way to do multiple phases of initialization of a model?

Thank you.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]