On 17:00-20200824, Suman Anna wrote: > Hi Nishanth, > > On 8/20/20 2:03 PM, Nishanth Menon wrote: > > On 08:25-20200820, Suman Anna wrote: > > [...] > >>> I am just wondering if the carveouts and mbox linkage should be in the > >>> common processor board? if that makes sense at all? I know we already > >>> have other definitions.. Trying to see if we are making it harder to > >>> understand the definition than that is necessary.. > >> > >> In general, I consider these as stuff that needs to be added to the board dts > >> files. You will see that this is what I have followed on all the TI > >> AM57xx/DRA7xx boards. For J721E, we have a weird organization as the memory > >> node, typically a board property, is defined in the som dtsi file, so the > >> reserved memory nodes are also added in the som dtsi file. The convention I > >> followed in general is to have the reserved-memory and memory nodes together. > >> > >> If you think the mailbox nodes should be moved into the SoM dts file, I could do > > > > I think that might make more sense and less confusing. I'd rather > > leave the processor board dts for more signal and interface hookup > > related topics as it is done right now. if we do endup with too many > > SoM duplication, then we should consider it's own dtsi > > > >> it as a follow-on cleanup series, but would wait for the ABI 3.0 changes to be > >> merged first. > > > > Of course. We are expecting this to be part of rc2, please rebase and > > post once the tag is out. next-20200820 has it already, if you want a > > pre-look. > > > > So, the ABI 3.0 changes are not part of -rc2, so, I cannot move the unrelated > mailbox nodes/cleanup without conflicting with that series. Are you ok if I just > move these nodes into the SoM dtsi file? Lets introduce things properly: First cleanup rather creating a kludgy intermediate state (half of r5 mbox nodes in proc, half of c6x node in SoM etc). -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
