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

[Neha Malcom Francis]

Hi Tom,

On 17/11/23 19:37, Tom Rini wrote:
> On Fri, Nov 17, 2023 at 02:00:43PM +0530, Neha Malcom Francis wrote:
>> 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.
> 
> OK, please rebase on top of whatever other series are needed (and note
> so in the cover letter) and mark it as non-RFC, thanks.
> 

Thanks! I'll rebase and send the next version.

-- 
Thanking You
Neha Malcom Francis