• Launchpad Entry: https://blueprints.edge.launchpad.net/ubuntu-arm/+spec/arm-m-using-device-tree-on-arm

• Created: JeremyKerr

• Contributors:

• Packages affected:

Summary

This will be a discussion defining future development areas for the Device tree work on ARM, and making some of the decisions that have emerged from the past 6 months of DT development on ARM.

Discussion areas

Boot interface

The boot interface has been defined and is in-use in the development kernel and qemu. We need to ensure that this is the proper way forward before submitting patches to be merged upstream.

Clock interface & bindings

ARM clock implementations are often complex, more so than existing DT-enabled architectures. Jeremy Kerr's proposed clock API is aimed at implementing a DT-compatible approach for representing clocks in the kernel. Discussion is suggested on the viability of this approach, and further implementation details that may be particular to representing clocks in the device tree.

Platform support

Platform-specific design discussion, iMX51 and OMAP in particular.

Defining power domains

We need a way to provide power domain information in the DT

BoF agenda and discussion

Boot interface

Draft boot interface: http://devicetree.org/Main_Page

Nicolas: ATAGs should be deprecated in favor of device tree which takes precedent when we have ATAGs and device tree? glikely: ATAGs are cheap

New uboot older kernel: uboot has to be used in a compatible mode, it's up to you

If you have a newer uboot, you can probably have a newer kernel - usually when you're stuck it's stuck with an old uboot and newer kernel, not vice versa

• the ability to sidestep an old uboot and pass device tree is an unsolved problem
• ATAGs are nicely designed, clean, straightforward; reduces conditional paths; not a lot gained by removing them
• Magic numbers make it possible to distinguish between ATAGs and devicetree, so there isn't actually any ambiguity
• Some of the information in ATAGs doesn't belong in device tree
  • If we're passing data from the bootloader, we have to pass information via the device tree anyway
• glikely wants a decision in the next couple of weeks: if dropping ATAGs completely gets it done, do it
• pain on ppc has been in development, need to pass something different to test the new kernel
  • powerpc is worse than ARM will be, new kernel can still accept the legacy machine ID w/ ATAG
  • why not a clean cut instead of letting the code linger?
    • ACTION: further offline discussion between jk, glikely, npitre regarding what the boot interface will be

Clocks

• new common clock struct with the standard operations
• anything that doesn't care passes the struct; things that do will get subclassing per implementation
• analogous to the driver interfaces
• feedback from Russell is: prove it works
• jk working on demonstrating it for imx51
• compile-time selectable API
• are these typically used in hot paths?
  • Normally just in device init
• memory usage?
  • struct clk itself is small, but if you have a lot of different clocks there'll be some more usage

Power domains

• interface is different on all SoCs

  • is there information that belongs in the device tree to describe the power domains and what decisions kernel or user space can make?

  • are there conventions that would be useful across SoCs to describe what devices are in what power domain?

  • what do you need?
• can't assume power domain and clock domain are synonymous
  • clock domains, spec already exists
  • Connections plus constraints
• mappings of regulators to rails - pure data
• power domains are usually trees, very easy to represent
• internal power domains on a chip, probably no point in putting these in the devicetree
• Two requirements for device tree bindings generally:
  • document
  • publish for review
• Don't merge into mainline until this is done
• If a new driver doesn't rely on the device tree, the DT doesn't have to be included in the driver in the first pass and this process doesn't apply

"Compatible" properties in device tree nodes:

• "compatible" properties are lists of decreasing specificity: the first item should unambiguously identify the real vendor and device. The remaining items can name register-level compatible devices.

The dtc compiler doesn't need to be changed to take account of new device tree bindings.

Upstreaming:

• need community buy-in
• please start using it

Platform drivers:

• Can't 100% avoid modification
• Probe routine can contain a shim to extract/manufacture platform data from the device tree data
  • Nicolas Pitre disputes whether this code should live in the driver
• machine code can take respondibility for fixing up function pointers if needed

Actions

• [jk-ozlabs] boot interface: begin discussion on list
• [jk-ozlabs] clock domains: just do it
• [jk-ozlabs] power domains: propose bindings
• code to be gotten upstream, but not in time for the 2.6.35 kernel so Ubuntu will have to take kernel backport patches for this

---

CategorySpec