Re: [PATCH 0/2] TI: K3: Switch MCU R5F cluster into Split mode

["Kumar, Udit" <u-kumar1@ti.com>]

On 5/23/2025 6:46 PM, Andrew Davis wrote:
> On 5/23/25 6:48 AM, Nishanth Menon wrote:
>> On 14:27-20250523, Beleswar Prasad Padhi wrote:
>>> Hi Nishanth,
>>>
>>> On 5/22/2025 9:23 PM, Nishanth Menon wrote:
>>>> On 13:04-20250522, Beleswar Padhi wrote:
>>>>> Several TI K3 SoCs like J7200, J721E, J721S2, J784S4 and J742S2 
>>>>> have a
>>>>> R5F cluster in the MCU domain which is configured for LockStep 
>>>>> mode at
>>>>> the moment. Switch this R5F cluster to Split mode by default in all
>>>>> corresponding board level DTs to maximize the number of R5F cores.
>>>> Why? I can read the patch to understand what you are trying to do, but
>>>> the rationale needs to be explained.
>>>
>>>
>>> [..]
>> I suggest the following:
>> * SoC dts files - use a common standard for remote proc - lockstep makes
>>    sense as it is right now
>> * Modification to board specific dts files - call them out as board
>>    files specific patches to flip over to split mode - while considering
>>    the possibilities that users may NOT upgrade kernel and bootloader at
>>    the same time and the existence of EFI based dtb handover from
>>    bootloader to kernel - which means, kernel should be able to 
>> handle the
>>    same combinations correctly. Also handle the carveouts correctly for
>>    the new processors - at least state the strategy - overlays etc.. 
>> Come
>>    to think of it, I think we should fix up the carveout strategy for
>>    user programmable remote cores first before attempting all this new
>>    processor additions.
>
> +1
>
> The core issue here is that split vs lockstep is a *configuration*, which
> means it doesn't belong in DT in the first place. This is the reason 
> to keep
> config out of DT, why should what mode my R5 core starts in be based 
> on what
> board I'm using? It hard-codes what should be configurable decisions.

configurable decisions is bootloader build .

and you know what you are building then change DT as well.


>
> Same issue with carveouts, so IMHO all of the: carveouts, mailbox 
> selection,
> timer reserved status, and mode selection belong in an overlay. It 
> doesn't
> fix the issues, but at least it isolates it.
>
Its usage model, and split mode is enabled at board level.

as default, split mode is used, in case lock-step is needed then change 
DT in custom build too.


Also, Patch 1/2 should be posted as different patch.


> Andrew
>
>> * Split out the fixes patches separately out - no reason to mix it up
>>    with the rest of the refactoring.
>> * Fix your commit messages and subject lines to indicate clearly what is
>>    impacted, rationale, backward compatibility status
>>
>> [1] 
>> https://lore.kernel.org/all/20250522071828.285462-7-b-padhi@ti.com/#Z31dts:upstream:src:arm64:ti:k3-j7200-mcu-wakeup.dtsi
>> [2] https://lore.kernel.org/all/20250522073426.329344-2-b-padhi@ti.com/
>>