On Thu, Dec 12, 2019 at 10:40 AM Benjamin GAIGNARD benjamin.gaignard@st.com wrote:
On 12/9/19 8:25 PM, Stefano Stabellini via System-dt wrote:
On Mon, 2 Dec 2019, Rob Herring wrote:
On Thu, Nov 07, 2019 at 02:13:18PM -0800, Stefano Stabellini wrote:
Hi all,
This small series introduces a few key concepts needed to make system device tree a reality:
- cpus,cluster
- indirect-bus
- address-map
Hi,
On ST SoCs changing of domain not only impact memory and interrupt mapping but also properties like status, clocks or pinctrl. If I compare our TF-A, U-Boot, kernel or Optee device trees, I would say that generate them require to be able to overwrite, delete or add properties and nodes. It is close to apply overlays.
While secure vs. non-secure could have completely different views of the system, within each of those the h/w view should look the same. IOW, u-boot and the kernel have the same view of h/w, so differences between those are configuration. I think that's a different issue and not necessarily solved the same way.
If I understand well we are going in a direction that may require to define new concepts like address-map for each properties that we would like to change per domain, right ? Does that sound achievable if we have to apply that logic to all properties and node ?
With addresses, the root node is implicitly the view of "the cpu". I think that's a fairly unique problem to say to extend it to everything else.
Would not it be better to describe theses changes in an /overlay (or /chosen) node and let a tool apply them and generate the devicetrees per domain ?
No idea because I don't have too much visibility into what are all the changes different vendors need (that's both vendors not publishing details and bandwidth on my part). There's not any requirement to even use system DT. At some point if the differences are great enough, I simply wouldn't. Just have separate DTs and if overlays are helpful, then use them.
Rob