[PATCH RFC 10/10] board: ti: j721e: Enable ESM initialization for J7200

[Neha Malcom Francis]

Hi Tom

On 17/11/23 00:10, Tom Rini wrote:
> On Thu, Nov 16, 2023 at 11:43:50AM +0530, Neha Malcom Francis wrote:
>> Hi Tom,
>>
>> Trying to bring back this series here.
>>
>> On 03/10/23 20:40, Tom Rini wrote:
>>> On Tue, Oct 03, 2023 at 07:57:04PM +0530, Kumar, Udit wrote:
>>>>
>>>> On 10/3/2023 1:40 PM, Keerthy wrote:
>>>>> Enable ESM initialization for J7200
>>>>>
>>>>> Signed-off-by: Keerthy <j-keerthy at ti.com>
>>>>> ---
>>>>>     board/ti/j721e/evm.c | 6 ++++--
>>>>>     1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
>>>>> index 42fa94b7a5..070b28326f 100644
>>>>> --- a/board/ti/j721e/evm.c
>>>>> +++ b/board/ti/j721e/evm.c
>>>>> @@ -543,7 +543,8 @@ void spl_board_init(void)
>>>>>     	}
>>>>>     #ifdef CONFIG_ESM_K3
>>>>> -	if (board_ti_k3_is("J721EX-PM2-SOM")) {
>>>>> +	if ((board_ti_k3_is("J721EX-PM2-SOM")) ||
>>>>> +	    IS_ENABLED(CONFIG_TARGET_J7200_R5_EVM)) {
>>>>
>>>>
>>>> Could we align on one kind of check,  For J721E check is done against
>>>> board-id, whereas for J7200 checking
>>>
>>> We should look at figuring out how to split this file in two.  One for
>>> "generic J721E systems" and one for "TI EVMs", as I've mentioned in
>>> other threads, so that it's easier for custom platforms to drop code
>>> they don' require.
>>>
>>
>> Yes that does make sense. Would it be okay if we solve that problem
>> separately in a different patch series? We can move along with this current
>> series for now (after making the required change in CONFIG/board-id for v2)
>> since ESM support is important for these platforms.
> 
> Well, I think part of the answer to your question is (and this is a more
> general TI one too), what outstanding changes need to come in now to
> make existing platforms functional for v2024.01 ? My first thought is
> that this series would be taken to -next, if I took it now, which means
> there's time before it would be in master, and so if it really makes the
> re-org later easier, we could take it, but if not, can we re-org then do
> this? But if we need this to deal with regressions, OK, yes, we can take
> it like this now.
> 

Maybe focusing on the re-org after having in the changes would help give more 
perspective on how we can split? Not sure just a thought... in that case I 
prefer taking this in and having a working error signaling module in rather than 
delaying it if that's okay.

-- 
Thanking You
Neha Malcom Francis