On 08:09-20250523, Tom Rini wrote: > On Fri, May 23, 2025 at 06:54:00AM -0500, Nishanth Menon wrote: > > On 12:05-20250523, Beleswar Prasad Padhi wrote: > > > Hi Nishanth, > > > > > > On 5/22/2025 9:18 PM, Nishanth Menon wrote: > > > > On 08:45-20250522, Tom Rini wrote: > > > > > On Thu, May 22, 2025 at 12:48:28PM +0530, Beleswar Padhi wrote: > > > > > > > > > > > Previously, MCU R5F runs in lockstep mode. Enable split-mode on MCU > > > > > > R5F > > > > > > as the support to shut down core1 and use it for loading other > > > > > > firmware, > > > > > > while DM runs on core0, has been added. > > > > > > > > > > > > Signed-off-by: Beleswar Padhi <b-pa...@ti.com> > > > > > > --- > > > > > > dts/upstream/src/arm64/ti/k3-j7200-mcu-wakeup.dtsi | > > > > > > 2 +- > > > > > > dts/upstream/src/arm64/ti/k3-j721e-mcu-wakeup.dtsi | > > > > > > 2 +- > > > > > > dts/upstream/src/arm64/ti/k3-j721s2-mcu-wakeup.dtsi | > > > > > > 2 +- > > > > > > .../src/arm64/ti/k3-j784s4-j742s2-mcu-wakeup-common.dtsi | > > > > > > 2 +- > > > > > > 4 files changed, 4 insertions(+), 4 deletions(-) > > > > > Please don't post DONOTMERGE patches. If the series can be applied > > > > > without this patch, because the functionality is backwards compatible > > > > > put these changes in the cover letter or link to a gist or similar to > > > > > show how to test the changes locally. If the series can't be merged > > > > > until the DTS changes are ready too, please mark the whole thing as > > > > > RFC. > > > > > For clarity, what is the case with this series? > > > > While I appreciate the energy to get upstream, > > > > > > > > > Thanks :) > > > > > > > <vent> > > > > I think this habit of jumping ahead of kernel should be > > > > stopped. > > > > https://lore.kernel.org/all/20250522073426.329344-1-b-pa...@ti.com/ was > > > > posted, but not reviewed or accepted. I understand that there is a > > > > latency in picking things up in upstream kernel, but creating churn is > > > > not the right way of doing things. It took us an year+ to get > > > > OF_UPSTREAM settled down. At least wait for kernel maintainers to queue > > > > things up before attempting to sync u-boot with non-mainlined patches. > > > > </vent> > > > > > > > > > Actually the functionality added in this series is independent of the DT > > > patch. I posted this DT patch here as DONOTMERGE just so that folks can > > > know > > > how to test the functionality. > > > > > > I understand your concern, and if it was the case that these changes were > > > dependent on the DT, I would have waited until the DT patch is picked up > > > before posting this series here. > > > > use gist next time if your intent is to show how to test it.. Let us > > continue the discussion on the kernel list for the dts portion > > So it sounds like the bindings being used here aren't settled then? I'm > going to mark the whole series as RFC for now then, if so.
No change in bindings. Just the approach in this "easy to reproduce" patch does the change on SoC dtsi. I dont think that was the author's intent (and yes, i was confused as well). The question in kernel at least is organizing this in the right board dts/overlay methodology. Question then is: do we wait for kernel dts to settle down OR do we get the u-boot infra for handling these combinations ahead of the changes (more or less like do we do the driver fixes first or dts fixes first? in kernel at least, we do the driver fixes first).. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
