Message-ID: <CAAEAJfDDhN4btecUzu=3ZYxP=amnOD=vq0bhhetx7voKdeMZ9Q@mail.gmail.com>
Date:   Tue, 2 Mar 2021 08:16:30 -0300
From:   Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
To:     Fabrizio Castro <fabrizio.castro.jz@...esas.com>
Cc:     Arnd Bergmann <arnd@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux API <linux-api@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
        Phil Edworthy <phil.edworthy@...esas.com>,
        "REE dirk.behme@...bosch.com" <dirk.behme@...bosch.com>,
        Peter Erben <Peter.Erben@...bosch.com>,
        Linux Media Mailing List <linux-media@...r.kernel.org>
Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices

Hello everyone,

On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro
<fabrizio.castro.jz@...esas.com> wrote:
>
> Hi Arnd,
>
> Thanks for your feedback!
>
> > From: Arnd Bergmann <arnd@...nel.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@...esas.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@...esas.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

Powered by blists - more mailing lists