On Tue 28 Sep 04:24 CDT 2021, Charles Keepax wrote:

On Tue, Sep 28, 2021 at 10:51:36AM +0200, Arnd Bergmann wrote:

quoted

On Tue, Sep 28, 2021 at 10:37 AM Charles Keepax
[off-list ref] wrote:

quoted

I guess the question might be where else would said code go?
drivers/firmware seemed most obvious, all the other locations
I can think of don't really make sense. Can't really put it a bus
like spi/i2c etc. because we have parts on many buses. Can't
really put it in a functional subsystem (audio/input etc.) since
the whole idea was to try and get some independence from that so
we don't have parts including subsystems they don't use. Could
maybe put it in MFD, but no hard guarantee every part using it
will be an MFD device and I am fairly confident Lee will feel it
isn't MFD code as it doesn't relate to managing multiple devices.
Only other option I can think of would be to make some sort of
drivers/dsp or maybe drivers/cs_dsp, but not clear to me that is
obviously better than using drivers/firmware.

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.

You're correct, remoteproc tends to situations where you have
multi-function firmware; be it at a single point in time, or due to
different firmware choices. Where you essentially boot some firmware on
the remoteproc and from that instantiate one of more functional devices
based on the loaded firmware.

I am not sure there is great deal available publically on the
DSP core. It is talked about in a few of our datasheets, see
section 4.4 in [1]. But a basic description might be it is a
signal processing focused, very small DSP core. If can be loaded
with different firmwares at runtime, and indeed might be doing say
echo cancellation in one use-case, or always on voice detect in
another. Functionally it is very unlikely to be used for anything
besides signal processing inside the device it is in, since it is
typically quite integrated with that hardware and will be sitting
behind a slow bus, like I2C or SPI.

To me it sounds like the main difference compared to above is that you
have a single function that owns and controls the DSP and implements
that function - i.e. the audio driver probes, boots the DSP, if there's
a problem the audio driver will handle it etc.


When it comes to firmware parsing, that might be a somewhat unrelated
topic. E.g. in the Qualcomm case, the same customized ELF header is used
in both for remoteproc devices and in function-specific devices. For
this we extracted the relevant functions into a library of some common
helpers, which can be found in drivers/soc/qcom/mdt_loader.c.

Regards,
Bjorn

Current users are all audio, planning to upstream some haptics
parts soon, with possible other uses in the future.

[1] https://statics.cirrus.com/pubs/proDatasheet/CS48L32_DS1219F4.pdf

Thanks,
Charles

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel