Difference between revisions of "Device tree kernel summit 2017 action items"

From eLinux.org
Jump to: navigation, search
(update where should overlays live)
(Device Tree Workshop 2017 Action Items: changed format of "assigned:")
 
(One intermediate revision by the same user not shown)
Line 5: Line 5:
 
# prop: [ *foo_label, 1 ] -> prop: [ $foo_label, 1 ]
 
# prop: [ *foo_label, 1 ] -> prop: [ $foo_label, 1 ]
  
Assigned: Pantelis
+
Assigned: Pantelis
  
 
* YAML tools need to preserve comments (yes/no)
 
* YAML tools need to preserve comments (yes/no)
Line 12: Line 12:
 
# Comments are not preserved for yamldt
 
# Comments are not preserved for yamldt
 
   
 
   
Assigned: None
+
Assigned: None
  
 
* Select YAML or JSON for deduplicated machine readable format.
 
* Select YAML or JSON for deduplicated machine readable format.
Line 20: Line 20:
 
# Alternative JSON encoding with type information using escapes.  foo: [ "string", 12 "\aref reference", "\aint8 8" ] Would require disallowing presence of the \a characters in normal strings and encoding tags that can not be deduced in quoted strings. Pro is that it's straight forward, con looks weird for human readers.
 
# Alternative JSON encoding with type information using escapes.  foo: [ "string", 12 "\aref reference", "\aint8 8" ] Would require disallowing presence of the \a characters in normal strings and encoding tags that can not be deduced in quoted strings. Pro is that it's straight forward, con looks weird for human readers.
  
Assigned: Grant, Pantelis
+
Assigned: Grant, Pantelis
  
 
* YAML schemas
 
* YAML schemas
Line 27: Line 27:
 
# Handle extra constraints. [https://www.ietf.org/archive/id/draft-wright-json-schema-validation-01.txt JSON schema] does not define arbitrary constraints as expressions. They are needed for validation of busses etc. yamldt can eventually generate constraints from a subset of the JSON schema.
 
# Handle extra constraints. [https://www.ietf.org/archive/id/draft-wright-json-schema-validation-01.txt JSON schema] does not define arbitrary constraints as expressions. They are needed for validation of busses etc. yamldt can eventually generate constraints from a subset of the JSON schema.
  
Assigned: Grant, Pantelis
+
Assigned: Grant, Pantelis
  
 
* Extendable schemas
 
* Extendable schemas
Line 34: Line 34:
 
# There can be a systematic method of separating and then combining them for validation/code generation
 
# There can be a systematic method of separating and then combining them for validation/code generation
  
Assigned: None
+
A ssigned: None
  
 
* Code generation
 
* Code generation
Line 43: Line 43:
 
# Possible to have a common infrastructure to generate code, based on bindings?
 
# Possible to have a common infrastructure to generate code, based on bindings?
  
Assigned: None
+
Assigned: None
  
 
* Device Tree Overlays
 
* Device Tree Overlays
 
# How they should be structured? Differences between how Android does it and how Linux does it.
 
# How they should be structured? Differences between how Android does it and how Linux does it.
 +
## Android structure is:
 +
##:
 +
##: Main DT. The SoC-only part and the default configurations, provided by SoC vendor.
 +
##: Overlay DT. The device-specific configurations, provided by ODM/OEM.
 +
##:
 +
##: https://source.android.com/devices/architecture/dto/implement
 +
## Android bootloader applies the overlay, and passes the merged device tree to the kernel.
 
# Where should they live? Part of the kernel tree or external repo?
 
# Where should they live? Part of the kernel tree or external repo?
 
## Frank: The source in overlays soon (4.15-rc1?) should be in .dtsi files, which are included from an overlay .dts that supplies the /plugin/ directive.  They should live wherever the .dtsi files live.
 
## Frank: The source in overlays soon (4.15-rc1?) should be in .dtsi files, which are included from an overlay .dts that supplies the /plugin/ directive.  They should live wherever the .dtsi files live.
 
# Git submodules use if external repo?
 
# Git submodules use if external repo?
  
Assigned: None
+
Assigned: None
  
 
* Device Tree duplication avoidance.
 
* Device Tree duplication avoidance.
Line 61: Line 68:
 
# YAML can use merge keys and templating instead. Not specified yet.
 
# YAML can use merge keys and templating instead. Not specified yet.
  
Assigned: None
+
Assigned: None
  
 
* DT foreign bindings
 
* DT foreign bindings
Line 68: Line 75:
 
# Could be part of Extendable Schemas
 
# Could be part of Extendable Schemas
  
Assigned: None
+
Assigned: None
  
 
* Sharing generic bindings
 
* Sharing generic bindings
Line 74: Line 81:
 
# Inheritable bindings. How to define them in schemas?
 
# Inheritable bindings. How to define them in schemas?
  
Assigned: None
+
Assigned: None
  
 
* Linux kernel device tree overlays specific
 
* Linux kernel device tree overlays specific
Line 83: Line 90:
 
# Pantelis, Frank: switch drivers to using <s>devm_ managed memory accessor methods</s> new API (architecture TBD)
 
# Pantelis, Frank: switch drivers to using <s>devm_ managed memory accessor methods</s> new API (architecture TBD)
  
Assigned: Frank, Pantelis
+
Assigned: Frank, Pantelis

Latest revision as of 22:49, 1 November 2017

Device Tree Workshop 2017 Action Items

  • YAML data schema must enable 3rd party tools, switch from using anchors and labels as in YAML to special properties.
  1. foo: &foo_label -> foo: { $label: foo_label }
  2. prop: [ *foo_label, 1 ] -> prop: [ $foo_label, 1 ]
Assigned: Pantelis
  • YAML tools need to preserve comments (yes/no)
  1. Hard requirement or not?
  2. Comments are preserved for ruamel
  3. Comments are not preserved for yamldt
Assigned: None
  • Select YAML or JSON for deduplicated machine readable format.
  1. Example in source YAML format is: foo: [ "string", 10+2, $reference, !int16 8 ] declares a property which is comprised of a sequence of 4 scalars. One string equal to "string", one integer/cell value with the value 12, a reference to a node with the label 'reference' and finally a 16 bit value with a value of 8.
  2. YAML is easier to read and maps to source file format. Easily distinguish strings, integer values and references. Type information is preserved too. foo: [ "string", 12, $reference, !int16 8 ] Strings are always quoted, integer values are expressions, references are tagged by being unquoted strings starting with $, and if a tag exists it is preserved.
  3. JSON is easier for machines to parse but does not preserve types. foo: [ "string", 12, "$reference", 8 ] Requires use of the bindings to retrieve type information. Quoted strings maybe either strings or references, values require binding info to know whether they are 32 bit or something elese.
  4. Alternative JSON encoding with type information using escapes. foo: [ "string", 12 "\aref reference", "\aint8 8" ] Would require disallowing presence of the \a characters in normal strings and encoding tags that can not be deduced in quoted strings. Pro is that it's straight forward, con looks weird for human readers.
Assigned: Grant, Pantelis
  • YAML schemas
  1. Grant is using ruamel, validates using json schema format file. Hand written, how it would pick rules from binding files?
  2. Pantelis is using yamldt, no extra format file, pick up everything from bindings.
  3. Handle extra constraints. JSON schema does not define arbitrary constraints as expressions. They are needed for validation of busses etc. yamldt can eventually generate constraints from a subset of the JSON schema.
Assigned: Grant, Pantelis
  • Extendable schemas
  1. Core bindings refer to hardware definitions
  2. Operating systems/bootloaders may require extensions that are configuration related or specific use related. I.e. Linux specific configuration properties, u-boot spl node tags, etc.
  3. There can be a systematic method of separating and then combining them for validation/code generation

A ssigned: None

  • Code generation
  1. Project require generation of code/defines from device tree sources.
  2. u-boot
  3. Zephyr
  4. Xilinx?
  5. Possible to have a common infrastructure to generate code, based on bindings?
Assigned: None
  • Device Tree Overlays
  1. How they should be structured? Differences between how Android does it and how Linux does it.
    1. Android structure is:
      Main DT. The SoC-only part and the default configurations, provided by SoC vendor.
      Overlay DT. The device-specific configurations, provided by ODM/OEM.
      https://source.android.com/devices/architecture/dto/implement
    2. Android bootloader applies the overlay, and passes the merged device tree to the kernel.
  2. Where should they live? Part of the kernel tree or external repo?
    1. Frank: The source in overlays soon (4.15-rc1?) should be in .dtsi files, which are included from an overlay .dts that supplies the /plugin/ directive. They should live wherever the .dtsi files live.
  3. Git submodules use if external repo?
Assigned: None
  • Device Tree duplication avoidance.
  1. New marvell parts are using highly duplicated IP. How to support those cases
  2. Thomas: Use CPP macros -> works now
  3. David: Could be easier if relative paths would work: <&/foo/bar> -> <&../bar>
  4. David: Node names generated via expression might make things easier. What kind of expressions?
  5. Pantelis: Possible expression might refer to a property, could tie in with unit-names. foo@10 { reg = <10>; }; -> foo@{reg[0]} { reg = <10>; };
  6. YAML can use merge keys and templating instead. Not specified yet.
Assigned: None
  • DT foreign bindings
  1. Different projects use the same bindings differently
  2. devicetree.org?
  3. Could be part of Extendable Schemas
Assigned: None
  • Sharing generic bindings
  1. Geert: On certain cases generic bindings apply to devices in the whole domain
  2. Inheritable bindings. How to define them in schemas?
Assigned: None
  • Linux kernel device tree overlays specific
  1. configfs patch not admissible yet, due to the way that the kernel breakage
  2. Culprit is of_* accessor methods that directly return pointer to device tree properties
  3. Switch to using a safer API for drivers
  4. Locking should be revisited or revised completely
  5. Pantelis, Frank: switch drivers to using devm_ managed memory accessor methods new API (architecture TBD)
Assigned: Frank, Pantelis