[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200529140738.l57z24xylcnxk6m2@mobilestation>
Date: Fri, 29 May 2020 17:07:38 +0300
From: Serge Semin <Sergey.Semin@...kalelectronics.ru>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC: Serge Semin <fancer.lancer@...il.com>,
Vinod Koul <vkoul@...nel.org>,
Viresh Kumar <vireshk@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Arnd Bergmann <arnd@...db.de>,
Rob Herring <robh+dt@...nel.org>, <linux-mips@...r.kernel.org>,
<devicetree@...r.kernel.org>, <dmaengine@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 05/11] dmaengine: Introduce DMA-device device_caps
callback
On Fri, May 29, 2020 at 03:12:03PM +0300, Andy Shevchenko wrote:
> On Fri, May 29, 2020 at 01:23:55AM +0300, Serge Semin wrote:
> > There are DMA devices (like ours version of Synopsys DW DMAC) which have
> > DMA capabilities non-uniformly redistributed amongst the device channels.
> > In order to provide a way of exposing the channel-specific parameters to
> > the DMA engine consumers, we introduce a new DMA-device callback. In case
> > if provided it gets called from the dma_get_slave_caps() method and is
> > able to override the generic DMA-device capabilities.
>
> I thought there is a pattern to return something, but it seems none.
> So, I have nothing against it to return void.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
>
> But consider one comment below.
>
> > Signed-off-by: Serge Semin <Sergey.Semin@...kalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
> > Cc: Arnd Bergmann <arnd@...db.de>
> > Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > Cc: Rob Herring <robh+dt@...nel.org>
> > Cc: linux-mips@...r.kernel.org
> > Cc: devicetree@...r.kernel.org
> >
> > ---
> >
> > Changelog v3:
> > - This is a new patch created as a result of the discussion with Vinod and
> > Andy in the framework of DW DMA burst and LLP capabilities.
> > ---
> > drivers/dma/dmaengine.c | 3 +++
> > include/linux/dmaengine.h | 2 ++
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> > index ad56ad58932c..edbb11d56cde 100644
> > --- a/drivers/dma/dmaengine.c
> > +++ b/drivers/dma/dmaengine.c
> > @@ -599,6 +599,9 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
> > caps->cmd_resume = !!device->device_resume;
> > caps->cmd_terminate = !!device->device_terminate_all;
> >
>
> Perhaps a comment to explain that this is channel specific correction /
> override / you name it on top of device level capabilities?
>
> > + if (device->device_caps)
> > + device->device_caps(chan, caps);
> > +
Agreed. I also forgot to add a doc-comment above the struct dma_device
definition.
-Sergey
> > return 0;
> > }
> > EXPORT_SYMBOL_GPL(dma_get_slave_caps);
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index a7e4d8dfdd19..b303e59929e5 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -899,6 +899,8 @@ struct dma_device {
> > struct dma_chan *chan, dma_addr_t dst, u64 data,
> > unsigned long flags);
> >
> > + void (*device_caps)(struct dma_chan *chan,
> > + struct dma_slave_caps *caps);
> > int (*device_config)(struct dma_chan *chan,
> > struct dma_slave_config *config);
> > int (*device_pause)(struct dma_chan *chan);
> > --
> > 2.26.2
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Powered by blists - more mailing lists