Messages in this thread | | | Date | Tue, 22 Nov 2022 17:48:13 +0000 | From | Cristian Marussi <> | Subject | Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem |
| |
On Mon, Nov 14, 2022 at 01:47:25PM +0000, Ludvig Pärsson wrote: > On Mon, 2022-11-14 at 12:29 +0100, Etienne Carriere wrote: > > Hello all, > >
Hi Ludvig,
following up on the issues raised by this thread and a few proposals that were flying around (online and offline), in the past days I took the chance to have a go at a substantial rework of the init/probe sequences in the SCMI core to address the issue you faced with SCMI TEE transport while trying to untangle a bit the SCMI core startup sequences (... while also possibly not breaking it all :P...)
In a nutshell, building on an idea from an offline chat with Etienne ad Sudeep, now the SCMI bus initialization is split on its own and initialized at subsys_initcall level, while the SCMI core stack, including the the SCMI TEE transport layer, is moved at module_init layer together with the SCMI driver users.
This *should* theoretically solve your issue ... (and it seems like all the rest it's still working :P) ... so I was wondering if you can give a go at the following pachset on your setup:
https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_rework_stack_init_draft/
... note that this is just a draft at the moment, which has undergone a reasonable amount of testing on mailbox/virtio transports only in both a SCMI builtin and/or modules scenario, but is no where ready for review.
The top three patches are really what you need BUT these are probably tightly bound to that bunch of early fixes you can see in the branch...so in other words better if you pick the whole branch for testing :D
Once you've confirmed me that this solves your issues I'll start the final cleanup for posting in the next cycle.
Thanks, Cristian
| |