public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Fabrizio Castro <fabrizio.castro.jz@renesas.com>,
	Rob Herring <robh+dt@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux API <linux-api@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Chris Paterson <Chris.Paterson2@renesas.com>,
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	Dirk Behme <Dirk.Behme@de.bosch.com>,
	Peter Erben <Peter.Erben@de.bosch.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Date: Fri, 26 Feb 2021 15:05:16 +0200	[thread overview]
Message-ID: <YDjyDB/l6dVoodKZ@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAK8P3a1+CZTAcR5T=gN565Q8=CdZnu5KYsAijKXLY8taofEpGg@mail.gmail.com>

Hi Fabrizio,

Thank you for the patch.

On Fri, Feb 26, 2021 at 11:37:44AM +0100, Arnd Bergmann wrote:
> On Thu, Feb 25, 2021 at 11:51 PM Fabrizio Castro 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@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 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.
> 
> 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?

I second Arnd here, a standard API would be best.

> > +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.
> 
> > +
> > +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.
> 
> > +
> > +       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.
> 
> > +
> > +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.

We've suffered enough with DMA to user pointers. Let's use dmabuf
instead.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2021-02-26 13:06 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 22:51 [PATCH 0/7] Add FFT Support for R-Car Gen3 devices Fabrizio Castro
2021-02-25 22:51 ` [PATCH 1/7] clk: renesas: r8a77990: Add DAB clock Fabrizio Castro
2021-02-26  8:34   ` Geert Uytterhoeven
2021-03-01 14:47     ` Fabrizio Castro
2021-03-03 10:22       ` Fabrizio Castro
2021-02-25 22:51 ` [PATCH 2/7] clk: renesas: r8a77965: " Fabrizio Castro
2021-02-26  8:45   ` Geert Uytterhoeven
2021-02-26 12:48     ` Laurent Pinchart
2021-03-01 15:01       ` Fabrizio Castro
2021-03-03 10:23         ` Fabrizio Castro
2021-03-01 14:58     ` Fabrizio Castro
2021-02-25 22:51 ` [PATCH 3/7] dt-bindings: misc: Add binding for R-Car DAB Fabrizio Castro
2021-02-26  8:41   ` Geert Uytterhoeven
2021-03-01 15:10     ` Fabrizio Castro
2021-02-26  9:06   ` Sergei Shtylyov
2021-03-01 15:11     ` Fabrizio Castro
2021-02-26 13:01   ` Laurent Pinchart
2021-03-01 15:13     ` Fabrizio Castro
2021-02-25 22:51 ` [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices Fabrizio Castro
2021-02-26  9:34   ` Geert Uytterhoeven
2021-03-01 16:19     ` Fabrizio Castro
2021-02-26 10:37   ` Arnd Bergmann
2021-02-26 13:05     ` Laurent Pinchart [this message]
2021-03-01 17:54       ` Fabrizio Castro
2021-03-01 17:26     ` Fabrizio Castro
2021-03-02 11:16       ` Ezequiel Garcia
2021-03-02 12:20         ` Fabrizio Castro
2021-03-02 12:32           ` Laurent Pinchart
2021-03-03 10:20             ` Fabrizio Castro
2021-03-03 10:26               ` Geert Uytterhoeven
2021-03-03 10:43                 ` Fabrizio Castro
2021-02-25 22:51 ` [PATCH 5/7] arm64: dts: renesas: r8a77990: Add DAB support Fabrizio Castro
2021-02-26  9:37   ` Geert Uytterhoeven
2021-03-01 14:51     ` Fabrizio Castro
2021-02-26 12:47   ` Laurent Pinchart
2021-03-01 14:53     ` Fabrizio Castro
2021-02-25 22:51 ` [PATCH 6/7] arm64: dts: renesas: r8a77965: " Fabrizio Castro
2021-02-26  9:37   ` Geert Uytterhoeven
2021-03-01 14:54     ` Fabrizio Castro
2021-02-26 12:47   ` Laurent Pinchart
2021-03-01 14:55     ` Fabrizio Castro
2021-02-25 22:51 ` [PATCH 7/7] arm64: configs: Add R-Car " Fabrizio Castro
2021-02-26 12:52   ` Laurent Pinchart
2021-02-26 13:05     ` Geert Uytterhoeven
2021-02-26 12:20 ` [PATCH 0/7] Add FFT Support for R-Car Gen3 devices Laurent Pinchart
2021-03-01 14:50   ` Fabrizio Castro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YDjyDB/l6dVoodKZ@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=Chris.Paterson2@renesas.com \
    --cc=Dirk.Behme@de.bosch.com \
    --cc=Peter.Erben@de.bosch.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabrizio.castro.jz@renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=phil.edworthy@renesas.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=robh+dt@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox