[U-Boot] [PATCH 00/22] dm: Add support for a 'live' device tree

[Tom Rini]

On Sat, Feb 04, 2017 at 07:34:59PM -0800, Simon Glass wrote:
> Hi,
> 
> On 17 January 2017 at 21:50, Simon Glass <sjg at chromium.org> wrote:
> > So far U-Boot uses a 'flat' device tree, which means that it is decoded
> > on the fly as needed. This uses the libfdt library and avoids needing
> > extra memory for additional tables.
> >
> > For some time there has been discussion about moving U-Boot to use a
> > 'live' tree, where the device tree is decoded at start-up into a set of
> > hierarchical structures with pointers.
> >
> > The advantages are:
> >
> > - It is somewhat faster to access (in particular scanning and looking for a
> >     parent)
> > - It permits the device tree to be changed at run-time (this is not
> >     recommended at present since devices store the offset of their device
> >     tree node and updating the tree may invalidate that). This could be
> >     useful for overlays, for example.
> > - It allows nodes to be referenced by a single pointer, instead of the
> >     current device tree pointer plus offset
> >
> > The disadvantages are:
> >
> > - It requires more memory
> > - It takes (a little) time to build the live tree
> > - It adds more complexity under the hood, including an additional
> >     abstraction layer
> >
> > This series is an attempt to introduce a useful live tree feature into
> > U-Boot. There are many options and trade-offs. This series is the
> > culmination of quite a bit of thought and experimentation.
> >
> > The approach used in this series is:
> >
> > - Before relocation the flat tree is used, to avoid extra memory usage
> > and time. In general, there is not much access before relocation since
> > most drivers are not started up. So there is little benefit in having a
> > live tree
> >
> > - After relocation the live tree is built. At this point the CPU should be
> > running quickly and there is plenty of memory. All available devices will
> > be bound so the overhead of building the live tree may be outweighed by
> > its greater efficiency.
> >
> > As a simplification, this series supports only one tree or the other. When
> > the live tree is active, the flat tree cannot be used. That makes it easy
> > to know the current state and avoids confusion over mixing offset and node
> > pointers.
> >
> > Some drivers will need to be used both before and after relocation. This
> > means that they must support both the flat and the live tree. To support
> > this, the concept of a node 'reference' is defined. A reference can hold
> > either a node offset (for the flat tree) or a node pointer (for the live
> > tree). This allows drivers to access values from the tree regardless of
> > which tree is in use.
> >
> > In addition, since most device tree access happens in the context of a
> > device (struct udevice), a new 'dev_read' layer is provided to read device
> > tree configuration associated with a device. This encapsulates the details
> > of exactly how this information is read.
> >
> > I have taken the view that code compatibility with Linux is desirable. So
> > the of_access.c file brings in code from Linux with very little
> > modification. As new access methods are needed we should be able to bring
> > in more code and avoid writing it ourselves in U-Boot.
> >
> > Conversion of drivers and subsystems to support the live tree (as well as
> > flat tree) is fairly easy. A patch is included to add support to the GPIO
> > uclass, and the cros_ec device is converted over to provide a driver
> > example.
> >
> > Once I have comments on this series I will update it to build for all
> > boards, to pass current tests and to tidy up the code. I will also add
> > tests for the live tree and finish conversion for sandbox. So for now I am
> > just looking for high-level comments, rather than a detailed code review.
> >
> >
> > Simon Glass (22):
> >   dm: core: Set return value first in lists_bind_fdt()
> >   dm: core: atmel: Dont export dm_scan_fdt_node()
> >   Update WARN_ON() to return a value
> >   dm: Add livetree definitions
> >   dm: Add livetree access functions
> >   dm: Add a function to create a 'live' device tree
> >   dm: Build a live tree after relocation
> >   dm: Add support for device tree references
> >   dm: Add a place to put extra device-tree reading functions
> >   dm: core: Add device-based functions to access DT properties
> >   dm: core: Allow binding a device from a live tree
> >   dm: core: Add a method to find a driver for a livetree node
> >   dm: core: Scan the live tree when setting up driver model
> >   dm: core: Add a way to find a device by its live-tree node
> >   dm: core: Add a way to find a device by node reference
> >   dm: gpio: Refactor to prepare for live tree support
> >   dm: gpio: Add live tree support
> >   dm: gpio: Drop blank line in gpio_xlate_offs_flags() comment
> >   dm: gpio: sandbox: Use dm_read...() functions to access DT
> >   cros_ec: Fix debug() statement in ec_command_inptr()
> >   cros_ec: Convert to support live tree
> >   sandbox: Move to use live tree
> 
> Any comments on the general concept?

Sorry, I do need to review this and the concept a bit more, just been
busy of late.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170205/dc25f26c/attachment.sig>