[PATCH v3 2/3] configs: j721e_evm_r5: Enable HBMC and MUX_MMIO at SPL

[Kumar, Udit]

Thanks Tom,

On 9/8/2025 9:50 PM, Tom Rini wrote:
> On Wed, Sep 03, 2025 at 09:58:34AM +0530, Kumar, Udit wrote:
>> Hi Tom,
>>
>> On 9/2/2025 9:42 PM, Tom Rini wrote:
>>> On Tue, Sep 02, 2025 at 09:36:25PM +0530, Kumar, Udit wrote:
>>>> Hi Tom
>>>>
>>>> On 9/2/2025 9:16 PM, Tom Rini wrote:
>>>>> On Tue, Sep 02, 2025 at 03:49:59PM +0530, Anurag Dutta wrote:
>>>>>
>>>>>> Commit 0e198ff1a911 ("configs: Resync with savedefconfig") removed
>>>>>> the necessary configs required to boot HyperFlash successfully, due to
>>>>>> missing Kconfig dependencies. Now that the Kconfig dependencies have
>>>>>> been added, re-enable the HBMC and MUX_MMIO configs in the SPL stage.
>>>>>>
>>>>>> Fixes: 0e198ff1a911 ("configs: Resync with savedefconfig")
>>>>>> Signed-off-by: Anurag Dutta <a-dutta at ti.com>
>>>>> Please note that this means it never worked to start with.
>>>>> "savedefconfig" does the equivalent of "make foo_defconfig" and then
>>>> It was working before but due to some boot issues , due to DT sync
>>>>
>>>> we disabled HBMC with commit id 5b2671594b80af116e259313d48bcd580d71f462 .
>>>>
>>>>
>>>> Instead of saying Fixes: 0e198ff1a91,
>>>>
>>>> This patch is fixing sha id 5b2671594b80af116e259313d48bcd580d71f462 by kind
>>>> of revert.
>>>>
>>>> my bad to give R/B , overlooked on sha id of fixes tag.
>>> Again, no, that's not quite how it works. When we do a defconfig resync
>>> like this we're just making the defconfigs reflect the present reality.
>> would need your suggestion here, what should be fixes tag,
>>
>> My comments were not related to defconfig sync
> Ah, yes, sorry, I mis-matched the hashes here.
>
>>> If you checkout 5b2671594b80af116e259313d48bcd580d71f462^ and then look
>>> at the resulting defconfig, that option will be off. Doing a git blame
>>> on drivers/mtd/Kconfig the right fixes tag is for:
>>
>> If you look at sha id d7ef2ef7c87528c359e110d7170e01a98aaecf14 (configs:
>> j721e_evm_defconfig: Add HBMC related configs)
>>
>> is adding support for HBMC. So it was functional before.
> Yes, I see that now, that's good.
>
>> Later due to DT sync and HBMC was broken so we disabled HBMC with sha id
>> 5b2671594b80af116e259313d48bcd580d71f462.
>>
>>
>> After that there was attempt to enable HBMC via below sha ids
>>
>> 8f71d37838ba0b0bfa047f5133877092ee9d1110 (mtd: Kconfig: Change HBMC driver's
>> dependency to MULTIPLEXER and MUX_MMIO)
>>
>> fd7fcd4098d5c1ba9e20dbd72aa5f9a74f0cbe42 (configs: j721e_evm_*_defconfig:
>> Add configs for Hyperflash boot)
>>
>> c9df79ee64d0885277d5061a9426744920c4d6a5 (arm: dts: k3-j721e-r5-common: Add
>> HBMC overrides for R5 SPL)
>>
>> a42b8b0b3fe0ffe69ffb932bf3e709a62ff34a23 (mtd: HBMC-AM654: Changed syscon
>> API to mux APIs)
>>
>> f0558f3a89fe0fa900b162ae2758772e37f72739 (mux: Makefile: Add config for mux
>> drivers)
> I guess my main frustration now is just that it's unclear where along
> the way what was submitted was or wasn't fully tested. We have both
> Kconfig dependency changes and dts additions (but not binding changes).

I understand your frustration,

we will take care of testing part.


>
> At the end of the day however, we don't yet have a linux kernel style
> "backport changes to eveywhere a fixes tag exists in old but supported
> releases" work flow, so we can just drop the fixes tag if it's too
> tricky to see where things did / didn't work. Alternatively, with the
> list of commits above and a board to test on, checkout the tree at the
> commit prior to that, test, then test the commit and see what the
> functional change is.
>