RE: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hi Geert,
> From: Geert Uytterhoeven
> Sent: 03 March 2021 10:27
> Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-
> Car devices
>
> Hi Fabrizio,
>
> On Wed, Mar 3, 2021 at 11:20 AM Fabrizio Castro
> wrote:
> > > From: Laurent Pinchart
> > > Sent: 02 March 2021 12:32
> > > Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas
> R-
> > > Car devices
> > >
> > > On Tue, Mar 02, 2021 at 12:20:17PM +, Fabrizio Castro wrote:
> > > > On 02 March 2021 11:17, Ezequiel Garcia wrote:
> > > > > On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro wrote:
> > > > > > On 26 February 2021 10:38, 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
>
>
> [...]
>
> > I think the clock related patches are worth merging.
>
> Indeed. I had already marked them to be applied, after you received
> confirmation about the parent clocks.
Thanks,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker.
> But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hi Fabrizio,
On Wed, Mar 3, 2021 at 11:20 AM Fabrizio Castro
wrote:
> > From: Laurent Pinchart
> > Sent: 02 March 2021 12:32
> > Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-
> > Car devices
> >
> > On Tue, Mar 02, 2021 at 12:20:17PM +, Fabrizio Castro wrote:
> > > On 02 March 2021 11:17, Ezequiel Garcia wrote:
> > > > On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro wrote:
> > > > > On 26 February 2021 10:38, 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
[...]
> I think the clock related patches are worth merging.
Indeed. I had already marked them to be applied, after you received
confirmation about the parent clocks.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hi Laurent, Thanks for your feedback! > From: Laurent Pinchart > 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 +, Fabrizio Castro wrote: > > On 02 March 2021 11:17, Ezequiel Garcia wrote: > > > On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro wrote: > > > > On 26 February 2021 10:38, 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 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. > > > > > > 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,
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 +, Fabrizio Castro wrote: > On 02 March 2021 11:17, Ezequiel Garcia wrote: > > On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro wrote: > > > On 26 February 2021 10:38, 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 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. > > > > 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 > DRIF interfaces, and only 1 DAB IP), and for what concerns FFT specifically > 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. > > > 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
RE: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hello Ezequiel, Thanks for your feedback! > From: Ezequiel Garcia > Sent: 02 March 2021 11:17 > Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R- > Car devices > > Hello everyone, > > On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro > wrote: > > > > Hi Arnd, > > > > Thanks for your feedback! > > > > > From: Arnd Bergmann > > > 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 > > > 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 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. > > 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 DRIF interfaces, and only 1 DAB IP), and for what concerns FFT specifically 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 capab
Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hello everyone, On Mon, 1 Mar 2021 at 14:36, Fabrizio Castro wrote: > > Hi Arnd, > > Thanks for your feedback! > > > From: Arnd Bergmann > > 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 > > 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 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. That sounds like something that can fit V4L2 MEM2MEM driver. You queue two buffers and an operation, and then run a job. > 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 I'm not entirely sure we are missing a framework. What's missing in V4L2 MEM2MEM? 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. Thanks, Ezequiel
RE: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> 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
> > > ---
> > > 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.
> >
> > > +
> &g
RE: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hi Arnd,
Thanks for your feedback!
> From: Arnd Bergmann
> 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
> 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 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 = {
> >
RE: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hi Geert,
Thanks for your feedback!
> From: Geert Uytterhoeven
> Sent: 26 February 2021 09:34
> Subject: Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-
> Car devices
>
> Hi Fabrizio,
>
> On Thu, Feb 25, 2021 at 11:53 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
>
> Thanks for your patch!
>
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -461,4 +461,5 @@ source "drivers/misc/bcm-vk/Kconfig"
> > source "drivers/misc/cardreader/Kconfig"
> > source "drivers/misc/habanalabs/Kconfig"
> > source "drivers/misc/uacce/Kconfig"
> > +source "drivers/misc/rcar_dab/Kconfig"
>
> rcar-dab?
I will change the directory name
>
>
> > --- /dev/null
> > +++ b/drivers/misc/rcar_dab/Kconfig
> > @@ -0,0 +1,11 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# R-Car DAB Hardware Accelerator
> > +#
> > +
> > +config RCAR_DAB
>
> DAB_RCAR?
Agreed
>
> > + tristate "DAB accelerator for Renesas R-Car devices"
> > + depends on ARCH_R8A77990 || ARCH_R8A77965
>
> || COMPILE_TEST
Will do
>
> > + help
> > + Some R-Car devices come with an IP to accelerate DAB decoding.
> > + Enable this option to add driver support.
>
> > --- /dev/null
> > +++ b/drivers/misc/rcar_dab/rcar_dev.c
> > @@ -0,0 +1,176 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * R-Car Gen3 DAB hardware accelerator driver
> > + *
> > + * Copyright (C) 2021 Renesas Electronics Corporation
> > + *
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include "rcar_dev.h"
> > +
> > +irqreturn_t rcar_dab_irq(int irq, void *devid)
>
> static, as discovered by the robot.
Yep
>
> > +{
> > + struct rcar_dab *dab = devid;
> > + u32 intsr, intcr1;
> > +
> > + spin_lock(>shared_regs_lock);
> > +
> > + intcr1 = rcar_dab_read(dab, RCAR_DAB_INTCR1);
> > + rcar_dab_write(dab, RCAR_DAB_INTCR1, 0x03FF);
>
> Magic value (setting undocumented bits?), please use a define.
The documentation (Section 44B.2.21 of the R-Car Gen3 HW User
manual) says to write (reserved) bits 31 to 10 as 0, to write
(reserved) bits 9 to 3 as 1, and the remaining 3 bits (2 to 0),
are interrupt masking bits set to 1 in this case to temporarily
disable interrupts.
I can of course add a define for this.
>
> > +
> > + intsr = rcar_dab_read(dab, RCAR_DAB_INTSR);
> > + if (!intsr) {
> > + rcar_dab_write(dab, RCAR_DAB_INTCR1, intcr1);
> > + spin_unlock(>shared_regs_lock);
> > + return IRQ_NONE;
> > + }
> > +
> > + /* Re-enable interrupts that haven't fired */
> > + rcar_dab_write(dab, RCAR_DAB_INTCR1, 0x3FF & (intsr | intcr1));
> > + /* Clear interrupts */
> > + rcar_dab_write(dab, RCAR_DAB_INTSR, 0x7 & ~intsr);
>
> More magic values.
As per section 44B.2.20 from the R-Car Gen3 HW User Manual,
Bit 31 to 3 are reserved and reads and writes as 0, and a
0 has to be written to bits 2 to 0 to clear the interrupts.
I will use a define for this as well.
>
> > +
> > + spin_unlock(>shared_regs_lock);
> > +
> > + if (intsr & RCAR_DAB_INTSR_FFT_DONE)
> > + rcar_dab_fft_irq(dab);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +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) {
> > +
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
> > ---
> > 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(>fft.lock);
> > + return -EFAULT;
> > + }
> > +
> > + dab->fft.done = false;
> > + ret = rcar_dab_fft_init(dab, fft_req);
> > + if (ret) {
> > + mutex_unlock(>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; /*
> >
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
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?
> +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(>fft.lock);
> + return -EFAULT;
> + }
> +
> + dab->fft.done = false;
> + ret = rcar_dab_fft_init(dab, fft_req);
> + if (ret) {
> + mutex_unlock(>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; /*
> +
Re: [PATCH 4/7] misc: Add driver for DAB IP found on Renesas R-Car devices
Hi Fabrizio,
On Thu, Feb 25, 2021 at 11:53 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
Thanks for your patch!
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -461,4 +461,5 @@ source "drivers/misc/bcm-vk/Kconfig"
> source "drivers/misc/cardreader/Kconfig"
> source "drivers/misc/habanalabs/Kconfig"
> source "drivers/misc/uacce/Kconfig"
> +source "drivers/misc/rcar_dab/Kconfig"
rcar-dab?
> --- /dev/null
> +++ b/drivers/misc/rcar_dab/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# R-Car DAB Hardware Accelerator
> +#
> +
> +config RCAR_DAB
DAB_RCAR?
> + tristate "DAB accelerator for Renesas R-Car devices"
> + depends on ARCH_R8A77990 || ARCH_R8A77965
|| COMPILE_TEST
> + help
> + Some R-Car devices come with an IP to accelerate DAB decoding.
> + Enable this option to add driver support.
> --- /dev/null
> +++ b/drivers/misc/rcar_dab/rcar_dev.c
> @@ -0,0 +1,176 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * R-Car Gen3 DAB hardware accelerator driver
> + *
> + * Copyright (C) 2021 Renesas Electronics Corporation
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include "rcar_dev.h"
> +
> +irqreturn_t rcar_dab_irq(int irq, void *devid)
static, as discovered by the robot.
> +{
> + struct rcar_dab *dab = devid;
> + u32 intsr, intcr1;
> +
> + spin_lock(>shared_regs_lock);
> +
> + intcr1 = rcar_dab_read(dab, RCAR_DAB_INTCR1);
> + rcar_dab_write(dab, RCAR_DAB_INTCR1, 0x03FF);
Magic value (setting undocumented bits?), please use a define.
> +
> + intsr = rcar_dab_read(dab, RCAR_DAB_INTSR);
> + if (!intsr) {
> + rcar_dab_write(dab, RCAR_DAB_INTCR1, intcr1);
> + spin_unlock(>shared_regs_lock);
> + return IRQ_NONE;
> + }
> +
> + /* Re-enable interrupts that haven't fired */
> + rcar_dab_write(dab, RCAR_DAB_INTCR1, 0x3FF & (intsr | intcr1));
> + /* Clear interrupts */
> + rcar_dab_write(dab, RCAR_DAB_INTSR, 0x7 & ~intsr);
More magic values.
> +
> + spin_unlock(>shared_regs_lock);
> +
> + if (intsr & RCAR_DAB_INTSR_FFT_DONE)
> + rcar_dab_fft_irq(dab);
> +
> + return IRQ_HANDLED;
> +}
> +
> +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);
Do you envision ever using the FFT operation from kernel space?
Might be easier if you handle the copy_{from,to}_user() here.
> + break;
> + default:
> + ret = -ENOTTY;
> + }
> +
> + return ret;
> +}
> +
> +static const struct file_operations rcar_dab_fops = {
> + .owner = THIS_MODULE,
> + .unlocked_ioctl = rcar_dab_unlocked_ioctl,
Does this need compat_ioctl handling?
> +};
> +
> +static int rcar_dab_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct rcar_dab *dab;
> + int ret, irq;
> +
> + dab = devm_kzalloc(dev, sizeof(*dab), GFP_KERNEL);
> + if (!dab)
> + return -ENOMEM;
> + dab->pdev = pdev;
> +
> + dab->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(dab->base))
> + return PTR_ERR(dab->base);
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(dev, "Can't get the irq.\n");
> + return -EINVAL;
> + }
> +
> + dab->clk = devm_clk_get(>dev, "dab");
> + if (IS_ERR(dab->clk)) {
> + ret = PTR_ERR(dab->clk);
> + dev_err(dev, "Can't get the clock (%d).\n", ret);
> + return ret;
> + }
> +
> + spin_lock_init(>shared_regs_lock);
> +
> + ret = clk_prepare_enable(dab->clk);
Does the module clock need to be enabled all the time?
What about using Runtime PM instead of explicit clock handling, so your
driver will keep on working on future SoCs where the DAB block is part of
a
