Device tree plumbers 2015 etherpad

Top Device Tree page

Local cache of Linux Plumbers 2015 Device Tree Track etherpad notes
Device Tree Microconference Notes

Welcome to Linux Plumbers Conference 2015

The structure will be short introductions to an issue or topic followed by a discussion with the audience.

Please use this etherpad to take notes. Microconf leaders will be giving a TWO MINUTE summary of their microconference during the Friday afternoon closing session.

Please remember there is no video this year, so your notes are the only record of your microconference.

Miniconf leaders: Please remember to take note of the approximate number of attendees in your session(s).

Reference Materials
Presentation slides and many references are at: http://elinux.org/Device_tree_future

Organizers
Frank Rowand

Schedule
1:30 Intro Frank Rowand

1:35 Device Tree Overlays Pantelis Antoniou, Guenter Roeck

2:00 Overlays, some times a good idea sometimes not. Pantelis Antoniou

2:15 Device Tree Documentation Matt Porter, Frank Rowand

2:30 Chat With The dtc Maintainers, part 1 David Gibson, Jon Loeliger

2:45 - Tea Break -

3:00 Chat With The dtc Maintainers, part 2 David Gibson, Jon Loeliger

3:10 Overlays and tools for sanity. Pantelis Antoniou

3:25 Device Tree Tools Frank Rowand

3:40 Device Tree probe order and parallel device probing Pantelis Antoniou

3:50 Device tree round up   Frank Rowand

Notes

Total # attendees: 53 Total # participants: 20

1:30 Introduction
Frank does not suggest interfering with each other Multiple people can write on etherpad at the same time.

1:35 Device Tree Overlays
Pantelis Antoniou slides: http://elinux.org/images/f/fa/Plumbers_2015_dt_DT-plumbers-2015.pdf

Device trees have been static in the past, but doesn't work for many scenarios
 * expansion boards, riser cards, etc.
 * too many combinations, not realistic to have a device tree per combination

With dynamic use cases device trees phandles have to be resolved, similar to linking

Overlays initially created for Beagle Bone board, which has expansion boards called Capes
 * can select which overlay applies to your scenario
 * Proposed overlay dtb stored in eeprom of device
 * Also overlays for changing what driver an I2C or PCI attached device should use, instead of changing the PCI ID

CONFIG_OF_DYNAMIC
 * allowed some dynamic changes to live device tree at runtime
 * Frank: some changes on powerpc in process to allow reverting PCI device tree fragments
 * Changes to DT were not fully reflected in driver state
 * reworking of OF_DYNAMIC made it into 3.17
 * major user was dt self tests

Dynamic resolution
 * Device handles used to be converted from names to numbers at compile time
 * Now needed to be resolved at run-time when overlays are added

DT compiler changes
 * no changes to DTB format
 * Inserts a __symbols__ table with the name of the handle pointing to the node path

Changesets
 * Grant Likely: current algorithm for selecting phandles sucks
 * have talked about using hash tables
 * if they overlap can only be reverted in order

Frank: Are things fixed to the point where the proposed .dtb format can't be changed
 * generally no, things could be changed
 * there are some overlays flashed in firmware already, but if necessary the old overlay content could be used to detect the hardware and look up the right overlay

We should not make decisions assuming "Linux". There are other device tree users, like BSD.

Overlays are not merged into the kernel yet,  Questions about how and when overlays are applied is one of the issues. Grant wants to have mechanism to filter out which nodes can be touched. User space policy thoughts:
 * only add things that did not exist?
 * can't delete nodes?
 * can only modify nodes not bound to a driver?

FPGA use case
 * "bridge" driver would apply the overlay

2:00 Overlays, some times a good idea sometimes not
xxx

2:15 Device Tree Binding Documentation
Matt Porter slides: http://elinux.org/images/4/4a/Plumbers_2016_dt_DT_Binding_Documentation.pdf

Process is mature
 * subsystem maintainers make sure new hardware adhere to the generic bindings

Problems
 * bindings bit rot
 * formatting is inconsistent
 * no rigid format
 * terminology is inconsistent

Grant: as long as bindings are human readable, we'll have issues Need a schema that could be applied to nodes...but this has been discussed for years and nothing has been done

Proposed solutions
 * move to rigid text markup template
 * revive Stephen Warren's old DT bindings doc
 * separate generic bindings from other bindings

Device Tree Documentation
Frand Rowand slides: http://elinux.org/images/1/17/Plumbers_2016_dt_device_tree_doc.pdf

What exists:
 * ePAPR, 1275, etc. Lots of fragments of information

Frank is trying to organize info at elinux.org/Device_Tree

Email Frank suggestions, etc related to documentatoin and he will included it in elinux.org

Question about standardization-- talk last year about OASIS or Linux Foundation Stuart: will send Frank info about possibility of moving ePAPR outside of power.org, which is effectively defunct.

2:30 Chat With The dtc Maintainers
David Gibson: has some concerns about overlay syntax. Conerned about living with bad decisions for a very long time.

DTC with overlay support is not in mainline DTC, is in side repos.

DTC to do list
 * richer expression support
 * string expressions
 * way of producing node/property names from an expression
 * more checks, like does "reg" have sane value, does interrupts have right number of cells?

David: wants to see patches to DTC

Frank: would like to have an option to have DTC insert a build string (e,g. SHA) into the DTB

FreeBSD guys have reimplemented DTC. (same source format, different code base).

David: who would like to see more expression support? (1 person interested)

Frank: DTC error messages are problematic-- what is the actual issue found (cause of the error message) and how to fix it. David: DTC does track line number of all tokens, but error productions need improvements

Device Tree Overlays at Juniper
Guenter Roeck slides: http://elinux.org/images/7/71/Plumbers_2016_dt_Devicetree_Overlays_at_Juniper.pdf

don't know what board will be inserted in a chassis use overlays to describe various boards want to be able to hot insert cards into a system that is in the field without rebooting it each slot has an overlay connector driver handles insertion/removal David: why use overlays on PCI devices
 * card may have hundreds of gpio pins, and large number of i2c busses
 * PCI cards don't use normal int a/b ... use GPIOs that implement interrup

Want DT overlay support on x86.

3:10 Overlays and tools for sanity
xxx

3:25 Device Tree Tools
Frank: working on tools to identify where things went wrong. Did talk on Wednesday. Working on additional tools.

3:40 Device Tree probe order and parallel device probing
xxx

3:50 Device tree round up
xxx