Re: [PATCH 2/7] arm64: dts: ti: k3-j721e-common-proc-board: Add mailboxes to C66x DSPs

From: Suman Anna <s-anna@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/7] arm64: dts: ti: k3-j721e-common-proc-board: Add mailboxes to C66x DSPs
Date: Tue, 25 Aug 2020 12:25:48 -0500	[thread overview]
Message-ID: <b41d2aeb-7e54-a0de-3a93-5fe65ffee00d@ti.com> (raw)
In-Reply-To: <20200825104239.lvdlz4sci3fe3nis@akan>

On 8/25/20 5:42 AM, Nishanth Menon wrote:
> 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).

OK, posted a v2 [1] with the cleanup first. It does create a dependency on the
pending ABI 3.0 PR.

regards
Suman

[1] https://patchwork.kernel.org/cover/11736095/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel