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

flat view

From: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Date: 2021-03-03 13:50:47
Also in: linux-arm-kernel, linux-devicetree, linux-media, linux-renesas-soc, lkml

Hi Laurent,

Thanks for your feedback!

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Sent: 02 March 2021 12:32
Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-
Car devices

Hi Fabrizio,

On Tue, Mar 02, 2021 at 12:20:17PM +0000, Fabrizio Castro wrote:

quoted

On 02 March 2021 11:17, Ezequiel Garcia wrote:

quoted

On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro wrote:

quoted

On 26 February 2021 10:38, Arnd Bergmann wrote:

quoted

On Thu, Feb 25, 2021 at 11:51 PM Fabrizio Castro wrote:

quoted

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

devices is

quoted

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

decoder

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

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

 drivers/misc/rcar_dab/rcar_dev.h | 116 ++++++++++++++++++++
 drivers/misc/rcar_dab/rcar_fft.c | 160

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

quoted

 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

quoted

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

have a user-level API but instead get called by the DAB radio

driver.

quoted

I hear you, the trouble is that the modules of this IP should be

seen

quoted

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

quoted

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

quoted

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

quoted

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

quoted

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

quoted

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

quoted

DRIF interfaces, and only 1 DAB IP), and for what concerns FFT

specifically

quoted

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?

V4L2 M2M devices can be opened multiple times, but different processes,
which can configure the device in different ways, and submit jobs that
are then scheduled by the V4L2 M2M framework.

I'll give it a try in due time then.

I think the clock related patches are worth merging.

Thanks,
Fab

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

quoted

interface (via driver drivers/media/platform/rcar_drif.c, or from

other

quoted

sources since this IP is decoupled from DRIF), and then when it's

time

quoted

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

quoted

in the great scheme of things, in its absence a simple driver can

help

quoted

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

quoted

with my previous email).

quoted

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

quoted

little bit better, so that we can integrate this IP with V4L2 later on.

--
Regards,

Laurent Pinchart

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help