[PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices

[Ezequiel Garcia]

Hello everyone,

On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro
<fabrizio.castro.jz at renesas.com> wrote:
>
> Hi Arnd,
>
> Thanks for your feedback!
>
> > From: Arnd Bergmann <arnd at kernel.org>
> > Sent: 26 February 2021 10:38
> > Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-
> > Car devices
> >
> > On Thu, Feb 25, 2021 at 11:51 PM Fabrizio Castro
> > <fabrizio.castro.jz at renesas.com> wrote:
> > >
> > > The DAB hardware accelerator found on R-Car E3 and R-Car M3-N devices is
> > > a hardware accelerator for software DAB demodulators.
> > > It consists of one FFT (Fast Fourier Transform) module and one decoder
> > > module, compatible with DAB specification (ETSI EN 300 401 and
> > > ETSI TS 102 563).
> > > The decoder module can perform FIC decoding and MSC decoding processing
> > > from de-puncture to final decoded result.
> > >
> > > This patch adds a device driver to support the FFT module only.
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz at renesas.com>
> > > ---
> > >  MAINTAINERS                      |   7 ++
> > >  drivers/misc/Kconfig             |   1 +
> > >  drivers/misc/Makefile            |   1 +
> > >  drivers/misc/rcar_dab/Kconfig    |  11 ++
> > >  drivers/misc/rcar_dab/Makefile   |   8 ++
> > >  drivers/misc/rcar_dab/rcar_dev.c | 176 +++++++++++++++++++++++++++++++
> > >  drivers/misc/rcar_dab/rcar_dev.h | 116 ++++++++++++++++++++
> > >  drivers/misc/rcar_dab/rcar_fft.c | 160 ++++++++++++++++++++++++++++
> > >  include/uapi/linux/rcar_dab.h    |  35 ++++++
> >
> > Can you explain why this is not in drivers/media/?
>
> I wasn't entirely sure were to put it to be honest as I couldn't find
> anything similar, that's why "misc" for v1, to mainly get a feedback
> and advice.
>
> >
> > I don't think we want a custom ioctl interface for a device that
> > implements
> > a generic specification. My first feeling would be that this should not
> > have a user-level API but instead get called by the DAB radio driver.
>
> I hear you, the trouble is that the modules of this IP should be seen
> as part of a SW and HW processing pipeline.
> Some of the SW components of the pipeline can be proprietary, and
> unfortunately we don't have access (yet) to a framework that allows us to
> test and demonstrate the whole pipeline, for the moment we can only test
> things in isolation. It'll take us a while to come up with a full solution
> (or to have access to one), and in the meantime our SoCs come with an IP
> that can't be used because there is no driver for it (yet).
>
> After discussing things further with Geert and Laurent, I think they
> are right in saying that the best path for this is probably to add this
> driver under "drivers/staging" as an interim solution, so that the IP will
> be accessible by developers, and when we have everything we need (a fully
> fledged processing framework), we will able to integrate it better with
> the other components (if possible).
>
> >
> > What is the intended usage model here? I assume the idea is to
> > use it in an application that receives audio or metadata from DAB.
> > What driver do you use for that?
>
> This IP is similar to a DMA to some extent, in the sense that it takes
> input data from a buffer in memory and it writes output data onto a buffer
> in memory, and of course it does some processing in between.

That sounds like something that can fit V4L2 MEM2MEM driver.
You queue two buffers and an operation, and then run a job.

> It's not directly connected to any other Radio related IP.
> The user space application can read DAB IQ samples from the R-Car DRIF
> interface (via driver drivers/media/platform/rcar_drif.c, or from other
> sources since this IP is decoupled from DRIF), and then when it's time
> to accelerate FFT, FIC, or MSC, it can request services to the DAB IP, so
> that the app can go on and use the processor to do some work, while the DAB
> IP processes things.
> A framework to connect and exchange processing blocks (either SW or HW) and
> interfaces is therefore vital to properly place a kernel implementation
> in the great scheme of things, in its absence a simple driver can help

I'm not entirely sure we are missing a framework. What's missing in
V4L2 MEM2MEM?

Before considering drivers/staging, it would be interesting to figure
out if V4L2 can do it as-is, and if not, discuss what's missing.

Thanks,
Ezequiel