From: Fabrizio Castro <fabrizio.castro.jz@renesas.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Arnd Bergmann <arnd@kernel.org> Cc: 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>, "REE dirk.behme@de.bosch.com" <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: Mon, 1 Mar 2021 17:54:22 +0000 [thread overview] Message-ID: <OSAPR01MB27374ACC15B53B3C4E43F718C29A9@OSAPR01MB2737.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <YDjyDB/l6dVoodKZ@pendragon.ideasonboard.com> Hi Laurent, Thank you for your feedback! > From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Sent: 26 February 2021 13:05 > Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R- > Car devices > > 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. Will give it a try Thanks, Fab > > -- > Regards, > > Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Fabrizio Castro <fabrizio.castro.jz@renesas.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Arnd Bergmann <arnd@kernel.org> Cc: DTML <devicetree@vger.kernel.org>, Chris Paterson <Chris.Paterson2@renesas.com>, Phil Edworthy <phil.edworthy@renesas.com>, Catalin Marinas <catalin.marinas@arm.com>, Arnd Bergmann <arnd@arndb.de>, Geert Uytterhoeven <geert+renesas@glider.be>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Peter Erben <Peter.Erben@de.bosch.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, "REE dirk.behme@de.bosch.com" <dirk.behme@de.bosch.com>, Rob Herring <robh+dt@kernel.org>, Linux API <linux-api@vger.kernel.org>, Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, 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: Mon, 1 Mar 2021 17:54:22 +0000 [thread overview] Message-ID: <OSAPR01MB27374ACC15B53B3C4E43F718C29A9@OSAPR01MB2737.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <YDjyDB/l6dVoodKZ@pendragon.ideasonboard.com> Hi Laurent, Thank you for your feedback! > From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Sent: 26 February 2021 13:05 > Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R- > Car devices > > 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. Will give it a try Thanks, Fab > > -- > Regards, > > Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-01 23:13 UTC|newest] Thread overview: 94+ 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 ` Fabrizio Castro 2021-02-25 22:51 ` [PATCH 1/7] clk: renesas: r8a77990: Add DAB clock Fabrizio Castro 2021-02-25 22:51 ` Fabrizio Castro 2021-02-26 8:34 ` Geert Uytterhoeven 2021-02-26 8:34 ` Geert Uytterhoeven 2021-03-01 14:47 ` Fabrizio Castro 2021-03-01 14:47 ` Fabrizio Castro 2021-03-03 10:22 ` Fabrizio Castro 2021-03-03 10:22 ` Fabrizio Castro 2021-02-25 22:51 ` [PATCH 2/7] clk: renesas: r8a77965: " Fabrizio Castro 2021-02-25 22:51 ` Fabrizio Castro 2021-02-26 8:45 ` Geert Uytterhoeven 2021-02-26 8:45 ` Geert Uytterhoeven 2021-02-26 12:48 ` Laurent Pinchart 2021-02-26 12:48 ` Laurent Pinchart 2021-03-01 15:01 ` Fabrizio Castro 2021-03-01 15:01 ` Fabrizio Castro 2021-03-03 10:23 ` Fabrizio Castro 2021-03-03 10:23 ` Fabrizio Castro 2021-03-01 14:58 ` 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-25 22:51 ` Fabrizio Castro 2021-02-26 8:41 ` Geert Uytterhoeven 2021-02-26 8:41 ` Geert Uytterhoeven 2021-03-01 15:10 ` Fabrizio Castro 2021-03-01 15:10 ` Fabrizio Castro 2021-02-26 9:06 ` Sergei Shtylyov 2021-02-26 9:06 ` Sergei Shtylyov 2021-03-01 15:11 ` Fabrizio Castro 2021-03-01 15:11 ` Fabrizio Castro 2021-02-26 13:01 ` Laurent Pinchart 2021-02-26 13:01 ` Laurent Pinchart 2021-03-01 15:13 ` Fabrizio Castro 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-25 22:51 ` Fabrizio Castro 2021-02-26 4:57 ` kernel test robot 2021-02-26 4:57 ` kernel test robot 2021-02-26 9:34 ` Geert Uytterhoeven 2021-02-26 9:34 ` Geert Uytterhoeven 2021-03-01 16:19 ` Fabrizio Castro 2021-03-01 16:19 ` Fabrizio Castro 2021-02-26 10:37 ` Arnd Bergmann 2021-02-26 10:37 ` Arnd Bergmann 2021-02-26 13:05 ` Laurent Pinchart 2021-02-26 13:05 ` Laurent Pinchart 2021-03-01 17:54 ` Fabrizio Castro [this message] 2021-03-01 17:54 ` Fabrizio Castro 2021-03-01 17:26 ` Fabrizio Castro 2021-03-01 17:26 ` Fabrizio Castro 2021-03-02 11:16 ` Ezequiel Garcia 2021-03-02 11:16 ` Ezequiel Garcia 2021-03-02 12:20 ` Fabrizio Castro 2021-03-02 12:20 ` Fabrizio Castro 2021-03-02 12:32 ` Laurent Pinchart 2021-03-02 12:32 ` Laurent Pinchart 2021-03-03 10:20 ` Fabrizio Castro 2021-03-03 10:20 ` Fabrizio Castro 2021-03-03 10:26 ` Geert Uytterhoeven 2021-03-03 10:26 ` Geert Uytterhoeven 2021-03-03 10:43 ` Fabrizio Castro 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-25 22:51 ` Fabrizio Castro 2021-02-26 9:37 ` Geert Uytterhoeven 2021-02-26 9:37 ` Geert Uytterhoeven 2021-03-01 14:51 ` Fabrizio Castro 2021-03-01 14:51 ` Fabrizio Castro 2021-02-26 12:47 ` Laurent Pinchart 2021-02-26 12:47 ` Laurent Pinchart 2021-03-01 14:53 ` Fabrizio Castro 2021-03-01 14:53 ` Fabrizio Castro 2021-02-25 22:51 ` [PATCH 6/7] arm64: dts: renesas: r8a77965: " Fabrizio Castro 2021-02-25 22:51 ` Fabrizio Castro 2021-02-26 9:37 ` Geert Uytterhoeven 2021-02-26 9:37 ` Geert Uytterhoeven 2021-03-01 14:54 ` Fabrizio Castro 2021-03-01 14:54 ` Fabrizio Castro 2021-02-26 12:47 ` Laurent Pinchart 2021-02-26 12:47 ` Laurent Pinchart 2021-03-01 14:55 ` Fabrizio Castro 2021-03-01 14:55 ` Fabrizio Castro 2021-02-25 22:51 ` [PATCH 7/7] arm64: configs: Add R-Car " Fabrizio Castro 2021-02-25 22:51 ` Fabrizio Castro 2021-02-26 12:52 ` Laurent Pinchart 2021-02-26 12:52 ` Laurent Pinchart 2021-02-26 13:05 ` Geert Uytterhoeven 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-02-26 12:20 ` Laurent Pinchart 2021-03-01 14:50 ` Fabrizio Castro 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=OSAPR01MB27374ACC15B53B3C4E43F718C29A9@OSAPR01MB2737.jpnprd01.prod.outlook.com \ --to=fabrizio.castro.jz@renesas.com \ --cc=Chris.Paterson2@renesas.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=dirk.behme@de.bosch.com \ --cc=geert+renesas@glider.be \ --cc=gregkh@linuxfoundation.org \ --cc=laurent.pinchart@ideasonboard.com \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.