On Wed, 28 Aug 2024, David Leonard wrote:
OK, but I still wonder why is it here. Without it the hardware will work
in little-endian?
Well, it's here firstly because I was trying to follow a perceived convention
in
dts/freescale/fsl,ls1012a.dtsi. That DT uses big-endian in child
nodes of /soc that match up with memory map tables from the datasheet.
(Not only do different and adjacent parts of the register map have
opposing endianess, some register layouts also seem to be reversed
bitwise, others bytewise.)
The second reason is practical/dodgy. The pinctrl driver should logically
be a child of the scfg node, but the syscon driver doesn't populate its
child nodes. To get the pinctrl driver to work meant making it a sibling
node with an unsatisfactory overlap with the scfg's address region
0x1570000+0x10000. (No driver binds to "fsl,ls1012a-scfg".)
Sorry, my examples had mixed up some ls1046a with ls1012a, which
must be confusing. Corrections follow, should the meaning have been lost:
soc {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
...
scfg: scfg@1570000 {
compatible = "fsl,ls1012a-scfg", "syscon";
reg = <0x0 0x1570000 0x0 0x10000>;
big-endian;
};
pinctrl: pinctrl@1570430 {
compatible = "fsl,ls1012a-pinctrl";
reg = <0x0 0x1570430 0x0 0x4>; /* SCFG PMUXCR0 */
big-endian;
fsl,dcfg-regmap = <&dcfg>;
...
};
};
The better device tree would be:
soc {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
...
scfg: scfg@1570000 {
compatible = "fsl,ls1012a-scfg", "syscon";
reg = <0x0 0x1570000 0x0 0x10000>;
big-endian;
#address-cells = <1>;
#size-cells = <1>;
...
pinctrl: pinctrl@430 {
compatible = "fsl,ls1012a-pinctrl";
reg = <0x430 0x4>; /* SCFG PMUXCR0 */
fsl,dcfg-regmap = <&dcfg (416/8)>;
...
};
};
};
And this would resolve the big-endian property issue.
There was a discussion of syscon populating its child nodes at
https://lore.kernel.org/lkml/1403513950.4136.34.camel@xxxxxxxxxxxxxxxxxxxxxxxx/T/
