On Tue, Sep 28, 2021 at 09:24:00AM +0000, Charles Keepax wrote: > On Tue, Sep 28, 2021 at 10:51:36AM +0200, Arnd Bergmann wrote: > > Other DSPs use the drivers/remoteproc/ subsystem, but that > > is more for general-purpose DSPs that can load application > > specific firmware rather than loading a single firmware blob > > as you'd normally do with the request_firmware() style interface. > > Not sure if that fits what you do. Can you point to a high-level > > description of what this DSP does besides audio, and how > > flexible it is? That might help find the right place for this. > Hm... wasn't aware of that one, we should probably investigate that > a little more at this end. From a quick look, seems a bit more like > it is designed for much larger more general purpose probably memory > mapped DSPs. I guess our code is a little more firmware parsing > and loading, and a bit less generic remote proceedure call stuff. Right, that was why I didn't suggest remoteproc - the DSPs wm_adsp covers seem much smaller than fits comfortably with remoteproc. You probably could make it fit though.
Attachment:
signature.asc
Description: PGP signature
