| Message ID | 20200526225022.20405-9-Sergey.Semin@baikalelectronics.ru (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account | expand |
On Wed, May 27, 2020 at 01:50:19AM +0300, Serge Semin wrote: > Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may > have non-uniform DMA capabilities per device channels, let's add > the DW DMA specific device_caps callback to expose that specifics up to > the DMA consumer. It's a dummy function for now. We'll fill it in with > capabilities overrides in the next commits. I think per se it is not worth to have it separated. Squash into the next one.
On Thu, May 28, 2020 at 05:53:03PM +0300, Andy Shevchenko wrote: > On Wed, May 27, 2020 at 01:50:19AM +0300, Serge Semin wrote: > > Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may > > have non-uniform DMA capabilities per device channels, let's add > > the DW DMA specific device_caps callback to expose that specifics up to > > the DMA consumer. It's a dummy function for now. We'll fill it in with > > capabilities overrides in the next commits. > > I think per se it is not worth to have it separated. Squash into the next one. bikeshadding? There is no any difference whether I add a dummy callback, then fill it in in a following up patch, or have the callback added together with some content. Let's see what Vinod thinks of it. Until then I'll stick with the current solution. -Sergey > > -- > With Best Regards, > Andy Shevchenko > >
On Thu, May 28, 2020 at 6:30 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote: > > On Thu, May 28, 2020 at 05:53:03PM +0300, Andy Shevchenko wrote: > > On Wed, May 27, 2020 at 01:50:19AM +0300, Serge Semin wrote: > > > Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may > > > have non-uniform DMA capabilities per device channels, let's add > > > the DW DMA specific device_caps callback to expose that specifics up to > > > the DMA consumer. It's a dummy function for now. We'll fill it in with > > > capabilities overrides in the next commits. > > > > I think per se it is not worth to have it separated. Squash into the next one. > > bikeshadding? Actually no. > There is no any difference whether I add a dummy callback, then > fill it in in a following up patch, or have the callback added together > with some content. Let's see what Vinod thinks of it. Until then I'll stick with > the current solution. The rule of thumb that we don't add dead code or code which is useless per se. Go ahead and provide it with some usefulness.
On Thu, May 28, 2020 at 11:29:16PM +0300, Andy Shevchenko wrote: > On Thu, May 28, 2020 at 6:30 PM Serge Semin > <Sergey.Semin@baikalelectronics.ru> wrote: > > > > On Thu, May 28, 2020 at 05:53:03PM +0300, Andy Shevchenko wrote: > > > On Wed, May 27, 2020 at 01:50:19AM +0300, Serge Semin wrote: > > > > Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may > > > > have non-uniform DMA capabilities per device channels, let's add > > > > the DW DMA specific device_caps callback to expose that specifics up to > > > > the DMA consumer. It's a dummy function for now. We'll fill it in with > > > > capabilities overrides in the next commits. > > > > > > I think per se it is not worth to have it separated. Squash into the next one. > > > > bikeshadding? > > Actually no. > > > There is no any difference whether I add a dummy callback, then > > fill it in in a following up patch, or have the callback added together > > with some content. Let's see what Vinod thinks of it. Until then I'll stick with > > the current solution. > > The rule of thumb that we don't add dead code or code which is useless > per se. Go ahead and provide it with some usefulness. Actually yes. I've seen examples, which preparation patches first added prototypes with empty functionality, that in follow-up patches have been filled with a required code. I've seen Greg accepted such approach. So it's absolutely normal and acceptable. -Sergey > > -- > With Best Regards, > Andy Shevchenko
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c index fb95920c429e..ceded21537e2 100644 --- a/drivers/dma/dw/core.c +++ b/drivers/dma/dw/core.c @@ -1049,6 +1049,11 @@ static void dwc_free_chan_resources(struct dma_chan *chan) dev_vdbg(chan2dev(chan), "%s: done\n", __func__); } +static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps) +{ + +} + int do_dma_probe(struct dw_dma_chip *chip) { struct dw_dma *dw = chip->dw; @@ -1214,6 +1219,7 @@ int do_dma_probe(struct dw_dma_chip *chip) dw->dma.device_prep_dma_memcpy = dwc_prep_dma_memcpy; dw->dma.device_prep_slave_sg = dwc_prep_slave_sg; + dw->dma.device_caps = dwc_caps; dw->dma.device_config = dwc_config; dw->dma.device_pause = dwc_pause; dw->dma.device_resume = dwc_resume;
Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may have non-uniform DMA capabilities per device channels, let's add the DW DMA specific device_caps callback to expose that specifics up to the DMA consumer. It's a dummy function for now. We'll fill it in with capabilities overrides in the next commits. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org --- Changelog v3: - This is a new patch created as a result of the discussion with Vinud and Andy in the framework of DW DMA burst and LLP capabilities. --- drivers/dma/dw/core.c | 6 ++++++ 1 file changed, 6 insertions(+)