Messages in this thread | | | Date | Tue, 29 Nov 2022 12:15:33 +0000 | From | Cristian Marussi <> | Subject | Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem |
| |
On Tue, Nov 29, 2022 at 10:49:10AM +0000, Ludvig Pärsson wrote: > On Tue, 2022-11-22 at 17:48 +0000, Cristian Marussi wrote: > > 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 > > Hi Cristian,
Hi,
> > I tried my best to get the patchset to work somehow on my version of > the kernel, and it seems to be working great. I played around with some > things, for example changing order of some drivers that were on the > same init levels, and it still worked. Only tested with voltage domain > protocol and optee transport. > > Thanks for your great work! >
Great, thanks for testing it. I'll post shortly a cleaned up series aiming at the next release cycle.
Thanks, Cristian
| |