Hello Ezequiel,


Thanks for your feedback!

From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Sent: 02 March 2021 11:17
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
[off-list ref] wrote:

quoted

Hi Arnd,

Thanks for your feedback!

quoted

From: Arnd Bergmann <arnd@kernel.org>
Sent: 26 February 2021 10:38
Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas

R-

quoted

quoted

Car devices

On Thu, Feb 25, 2021 at 11:51 PM Fabrizio Castro
[off-list ref] wrote:

quoted

The DAB hardware accelerator found on R-Car E3 and R-Car M3-N

devices is

quoted

quoted

quoted

a hardware accelerator for software DAB demodulators.
It consists of one FFT (Fast Fourier Transform) module and one

decoder

quoted

quoted

quoted

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

quoted

quoted

quoted

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@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

+++++++++++++++++++++++++++++++

quoted

quoted

quoted

 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.

quoted

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

quoted

quoted

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

quoted

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

quoted

(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

quoted

be accessible by developers, and when we have everything we need (a

fully

quoted

fledged processing framework), we will able to integrate it better with
the other components (if possible).

quoted

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

quoted

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.

V4L2 MEM2MEM seems good for this in general, however the DAB IP is going
to be shared by multiple processing pipelines (as usually we have several
DRIF interfaces, and only 1 DAB IP), and for what concerns FFT specifically
there is only 1 FFT module inside the DAB IP.
My understanding is that the capabilities of V4L2 MEM2MEM devices are
configured for the specific pipeline, but in the this context user space
would have to continuously switch the capabilities of the DAB IP (at the
right moment) to allow processing for data streams requiring different
capabilities.

Am I wrong?

quoted

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

quoted

that the app can go on and use the processor to do some work, while the

DAB

quoted

IP processes things.
A framework to connect and exchange processing blocks (either SW or HW)

and

quoted

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?

I was referring to a user space framework (I should have been more specific
with my previous email).

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.

I think an interim solution would allow us and users to evaluate things a
little bit better, so that we can integrate this IP with V4L2 later on.

Thanks,
Fab

Thanks,
Ezequiel

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