[PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Fabrizio Castro
fabrizio.castro.jz at renesas.com
Mon Mar 1 17:26:31 GMT 2021
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.
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
us and users to integrate DAB acceleration within an interim DAB processing
pipeline, and that will lead to better interfaces in the future.
>
> > +static long rcar_dab_unlocked_ioctl(struct file *file, unsigned int
> cmd,
> > + unsigned long arg)
> > +{
> > + void __user *argp = (void __user *)arg;
> > + struct rcar_dab *dab;
> > + int ret;
> > +
> > + dab = container_of(file->private_data, struct rcar_dab, misc);
> > +
> > + switch (cmd) {
> > + case RCAR_DAB_IOC_FFT:
> > + if (!access_ok(argp, sizeof(struct rcar_dab_fft_req)))
> > + return -EFAULT;
> > + ret = rcar_dab_fft(dab, argp);
> > + break;
> > + default:
> > + ret = -ENOTTY;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static const struct file_operations rcar_dab_fops = {
> > + .owner = THIS_MODULE,
> > + .unlocked_ioctl = rcar_dab_unlocked_ioctl,
> > +};
>
> There should be a '.compat_ioctl = compat_ptr_ioctl'
> entry, provided that the arguments are compatible between
> 32-bit and 64-bit user space.
Will add
>
> > +
> > +static int rcar_dab_fft_init(struct rcar_dab *dab, struct
> rcar_dab_fft_req *fft)
> > +{
> > + u32 mode;
> > +
> > + for (mode = 0; mode < ARRAY_SIZE(rcar_dab_fft_size_lut); mode++)
> > + if (rcar_dab_fft_size_lut[mode] == fft->points)
> > + break;
> > + if (mode == ARRAY_SIZE(rcar_dab_fft_size_lut))
> > + return -EINVAL;
> > + if (fft->ofdm_number == 0)
> > + return -EINVAL;
> > +
> > + rcar_dab_write(dab, RCAR_DAB_FFTSSR, mode);
> > + rcar_dab_write(dab, RCAR_DAB_FFTNUMOFDMR, fft->ofdm_number);
> > + rcar_dab_write(dab, RCAR_DAB_FFTINADDR, (u32)dab-
> >fft.dma_input_buf);
> > + rcar_dab_write(dab, RCAR_DAB_FFTOUTADDR, (u32)dab-
> >fft.dma_output_buf);
>
> Maybe use lower_32_bits() instead of the (u32) cast.
>
> For clarity, you may also want to specifically ask for a 32-bit DMA mask
> in the probe function, with a comment that describes what the hardware
> limitation is.
Thanks.
>
> > +
> > + if (copy_from_user(dab->fft.input_buffer, fft_req-
> >input_address,
> > + buffer_size)) {
> > + mutex_unlock(&dab->fft.lock);
> > + return -EFAULT;
> > + }
> > +
> > + dab->fft.done = false;
> > + ret = rcar_dab_fft_init(dab, fft_req);
> > + if (ret) {
> > + mutex_unlock(&dab->fft.lock);
> > + return ret;
> > + }
> > +
> > + rcar_dab_fft_enable(dab);
> > + wait_event_interruptible_timeout(dab->fft.wait, dab->fft.done,
> HZ);
> > + if (!dab->fft.done) {
> > + rcar_dab_fft_disable(dab);
> > + ret = -EFAULT;
>
> -EFAULT doesn't look like the right error for timeout or signal
> handling. Better check the return code from
> wait_event_interruptible_timeout()
> instead.
Will do
>
> > +
> > +struct rcar_dab_fft_req {
> > + int points; /*
> > + * The number of points to use.
> > + * Legal values are 256, 512,
> 1024, and
> > + * 2048.
> > + */
> > + unsigned char ofdm_number; /*
> > + * Orthogonal Frequency Division
> > + * Multiplexing (OFDM).
> > + * Minimum value is 1, maximum
> value is
> > + * 255.
> > + */
> > + void __user *input_address; /*
> > + * User space address for the
> input
> > + * buffer.
> > + */
> > + void __user *output_address; /*
> > + * User space address for the
> output
> > + * buffer.
> > + */
> > +};
>
> Please read Documentation/driver-api/ioctl.rst and make this a portable
> data structure.
Thanks,
Fab
>
> Arnd
More information about the linux-arm-kernel
mailing list