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-keer...@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. -- Tom
signature.asc
Description: PGP signature
