On Thu, Sep 11, 2025 at 10:26:08PM +0900, Alexandre Courbot wrote: > On Thu Sep 11, 2025 at 9:46 PM JST, Danilo Krummrich wrote: [..] > >> By keeping the initialization in the GPU, we can keep the GSP object > >> architecture-independent, and I think it makes sense from a design point > >> of view. That's not to say this code should be in `gpu.rs`, maybe we > >> want to move it to a GPU HAL, or if we really want this as part of the > >> GSP a `gsp/boot` module supporting all the different archs. But I'd > >> prefer to think about this when we start supporting several > >> architectures. > > > > Didn't we talk about a struct Gsp that will eventually be returned by > > Self::start_gsp(), or did I make this up in my head? > > > > The way I think about this is that we'll have a struct Gsp that represents > > the > > entry point in the driver to mess with the GSP command queue. > > > > But either way, this throws up two questions, if Self::start_gsp() return a > > struct GspMemObjects instead (which is probably the same thing with a > > different > > name), then: > > > > Are we sure this won't need any locks? If it will need locking (which I > > expect) > > then it needs pin-init. > > Sorry, I have been imprecise: I should I said: "it can be moved" rather > than "it doesn't need to be pinned". In that case I don't think > `Gsp::new` needs to return an `impl PinInit`, right?
If you don't mind clarifying for me, what is the difference between "it doesn't need to be pinned" and "it can be moved"? AFAICS, they mean the same thing. If you don't want move semantics on something, the only way to achieve that is pinning no?. If it can be moved, and it contains locks, then that will break unless pinned AFAICS. So if need locking in Gsp, which I think we'll need (to support sychrnoized command queue accesses), then I think pinning is unavoidable. On the other hand, if just the firmware loading part is kept separate, then perhaps that part can remain unpinned? Any chance we can initialize the locks later? We don't need locking until after the boot process is completed, and if there's a way we can dynamically "pin", where we hypothetically pin after the boot process completed, that might also work. Though I am not sure if that's something possible in Rust/rust4linux or if it makes sense. Other thoughts? thanks, - Joel
