[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250522155338.gpbcubkvygtju3qc@bagpipe>
Date: Thu, 22 May 2025 10:53:38 -0500
From: Nishanth Menon <nm@...com>
To: Beleswar Padhi <b-padhi@...com>
CC: <vigneshr@...com>, <kristo@...nel.org>, <robh@...nel.org>,
<krzk+dt@...nel.org>, <conor+dt@...nel.org>, <afd@...com>,
<u-kumar1@...com>, <hnagalla@...com>, <jm@...com>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/2] TI: K3: Switch MCU R5F cluster into Split mode
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.
>
> Corresponding support to shutdown MCU R5F core 1 on SoC power on have
> been posted in U-Boot:
> https://lore.kernel.org/all/20250522071828.285462-1-b-padhi@ti.com/
>
> While at it, correct the firmware-name property for MCU R5F cores of
> J742S2 SoC in [PATCH 1/2].
>
> Testing Done:
> 1. Tested that each patch does not generate any new warnings/errors.
> 2. Build test on all existing TI K3 platforms.
> 3. Tested U-Boot and Linux load of MCU R5F core in split mode on all
> applicable boards (AM68-SK, AM69-SK, J7200-EVM, J721E-EVM, J721S2-EVM,
> J784S4-evm, J742S2-EVM)
>
> Test logs:
> https://gist.github.com/3V3RYONE/ee8e3cb9aa5f4c5c00b059b9c14bfa98
>
> Thanks,
> Beleswar
>
> Beleswar Padhi (2):
> arm64: dts: ti: k3-j742s2-mcu-wakeup: Override firmware-name for MCU
> R5F cores
> arm64: dts: ti: k3: Switch MCU R5F cluster to Split-mode
NAK! We are once again churning downstream users again and for what
reason - coverletter and the patch is vague on that!
I would prefer the entire remote proc dts stuff cleaned up once for all
in a comprehensive series.
Let me be clear (once again): We DO NOT break backward compatibility.
We do not break downstream users without a clear cut rationale. We do
not break all other ecosystems depending on device tree without a very
very solid reason.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Powered by blists - more mailing lists