From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F382C433DB for ; Fri, 26 Feb 2021 13:06:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2C40164F1A for ; Fri, 26 Feb 2021 13:06:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230304AbhBZNGe (ORCPT ); Fri, 26 Feb 2021 08:06:34 -0500 Received: from perceval.ideasonboard.com ([213.167.242.64]:49382 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229550AbhBZNG0 (ORCPT ); Fri, 26 Feb 2021 08:06:26 -0500 Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 438F6580; Fri, 26 Feb 2021 14:05:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1614344743; bh=Pn1GXf496O59uPaYl6Kxb/FwBF+ERmIgv38ha8Jcl/E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AuZRBC/3EctvpMjBlzYhC9ZycLOxegiRu95vr8qxIHUUXBzx5yO2qx/pfpw+UKJtB bS3EAh05N6xfEXLinLLFdtXaHlFYsY26hGX/O4BYtbyRtVMReCYidGaiEsb/qDhsvU H8f0zXkYoNggy4PuccawOn9rEasjD2PM3QsVowYc= Date: Fri, 26 Feb 2021 15:05:16 +0200 From: Laurent Pinchart To: Arnd Bergmann Cc: Fabrizio Castro , Rob Herring , Arnd Bergmann , Geert Uytterhoeven , Greg Kroah-Hartman , Linux-Renesas , DTML , Linux ARM , Linux API , "linux-kernel@vger.kernel.org" , Catalin Marinas , Will Deacon , Chris Paterson , Prabhakar Mahadev Lad , Phil Edworthy , Dirk Behme , Peter Erben , Linux Media Mailing List Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices Message-ID: References: <20210225225147.29920-1-fabrizio.castro.jz@renesas.com> <20210225225147.29920-5-fabrizio.castro.jz@renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > --- > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCDE2C433DB for ; Fri, 26 Feb 2021 13:07:15 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7A72964EEE for ; Fri, 26 Feb 2021 13:07:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A72964EEE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zf9TvWCxduEclsBIfymvzTWNI5wmOoC142vDCzapAKg=; b=bKk6b4ZPhUH01q7d+NJPmohMg cAhDBYLX/uEMwra58oWzO6thRlCLxR0x0hAJTs6XwGKVfk67oVHrMIrVBS4vtJkQEORQILxO123K1 y651rUQx5m1nqJNkJxXvI5Ap9lvBkdnk5Q6LfPnsWmuXwiSHqHNPTKWpDhZHbUZfTXWiZJ0T5+2Th NR5EUQ8skOJuQbw+/rL1tiwLBv0DXDP6vGYYUcUnBsaz7Hs2ruhM3itWr8u+NYMcRMsF6hWqwC4z3 Mxx+OsqHyixVkLODZ/vE9Q905rxba0jg62WqErXZQD5u3GlHu1HcWv4DOg3DFgYMqGRbAtg+9OPAq xaiXXs8vQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFcoW-00083L-Al; Fri, 26 Feb 2021 13:05:48 +0000 Received: from perceval.ideasonboard.com ([2001:4b98:dc2:55:216:3eff:fef7:d647]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFcoT-00082W-K5 for linux-arm-kernel@lists.infradead.org; Fri, 26 Feb 2021 13:05:46 +0000 Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 438F6580; Fri, 26 Feb 2021 14:05:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1614344743; bh=Pn1GXf496O59uPaYl6Kxb/FwBF+ERmIgv38ha8Jcl/E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AuZRBC/3EctvpMjBlzYhC9ZycLOxegiRu95vr8qxIHUUXBzx5yO2qx/pfpw+UKJtB bS3EAh05N6xfEXLinLLFdtXaHlFYsY26hGX/O4BYtbyRtVMReCYidGaiEsb/qDhsvU H8f0zXkYoNggy4PuccawOn9rEasjD2PM3QsVowYc= Date: Fri, 26 Feb 2021 15:05:16 +0200 From: Laurent Pinchart To: Arnd Bergmann Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices Message-ID: References: <20210225225147.29920-1-fabrizio.castro.jz@renesas.com> <20210225225147.29920-5-fabrizio.castro.jz@renesas.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210226_080545_776787_BCB44203 X-CRM114-Status: GOOD ( 38.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: DTML , Chris Paterson , Phil Edworthy , Catalin Marinas , Arnd Bergmann , Geert Uytterhoeven , Greg Kroah-Hartman , Peter Erben , "linux-kernel@vger.kernel.org" , Fabrizio Castro , Prabhakar Mahadev Lad , Linux-Renesas , Dirk Behme , Rob Herring , Linux API , Will Deacon , Linux ARM , Linux Media Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > > --- > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel