i2c provides an example of where a schema would be useful.
>From the binding text files, I removed the common items
fsl-i2c
i2c@1740 {
clock-frequency = <100000>;
fsl,timeout = <10000>;
};
samsung-i2c
i2c@13870000 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <100000>;
samsung,i2c-slave-addr = <0>;
};
ce4100-i2c.txt
i2c@0 {
missing clock-frequency
};
omap-i2c.txt
i2c1: i2c@0 {
ti,hwmods = "i2c1"; -- I think this is because they are missing reg = <>
clock-frequency = <400000>;
};
arm-versatile.txt
missing clock frequency
i2c-designware.txt
looks ok
fsl-imx-i2c.txt
looks ok
cpm_qe/cpm/i2c.txt
file is in wrong place
The schema probably should be:
i2c@address {
compatible = "xxxx"; - required
reg = <xxxx>; - required
interrupts = <xxx>; - required?
interrupt-parent = <xxxx>; - if need
clock-frequency = <xxxx>; - optional, schema says default is
100Khz
slave-addr = <xxxx>; - optional, all of the controllers
support slave mode
timeout = <xxxxx>; - optional
#address-cells = <1>;
#size-cells = <0>;
aaaa,bbbb = <xxxx> - private, must have a comma in the name
}
Once schemas are in place and everything is validating, another pass
can be made to implement a common parser. The common parser would get
all of these attributes and parse them into a struct. Then we can
work on making sure each driver actually implements these core
attributes consistently.
--
Jon Smirl
[email protected]
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
