dmaengine Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
@ 2020-03-06 13:10 Sergey.Semin
  2020-03-06 13:29 ` Andy Shevchenko
  0 siblings, 1 reply; 8+ messages in thread
From: Sergey.Semin @ 2020-03-06 13:10 UTC (permalink / raw)
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Maxim Kaurkin,
	Pavel Parkhomenko, Ramil Zaripov, Ekaterina Skachko,
	Vadim Vlasov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
	Viresh Kumar, Andy Shevchenko, Dan Williams, Vinod Koul,
	Rob Herring, Mark Rutland, dmaengine, devicetree, linux-kernel

From: Serge Semin <fancer.lancer@gmail.com>

Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
with currently implemented in the kernel DW DMAC driver, but there are some
peculiarities which must be taken into account in order to have the device
fully supported.

First of all traditionally we replaced the legacy plain text-based dt-binding
file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
channels, which alas have different max burst length configuration.
In particular first two channels may burst up to 128 bits (16 bytes) at a time
while the rest of them just up to 32 bits. We must make sure that the DMA
subsystem doesn't set values exceeding these limitations otherwise the
controller will hang up. In third currently we discovered the problem in using
the DW APB SPI driver together with DW DMAC. The problem happens if there is no
natively implemented multi-block LLP transfers support and the SPI-transfer
length exceeds the max lock size. In this case due to asynchronous handling of
Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
the DMAC to asynchronously execute the transfers we'd have to at least warn
the user of the possible errors.

Finally there is a bug in the algorithm of the nollp flag detection.
In particular even if DW DMAC parameters state the multi-block transfers
support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
by the driver true multi-block LLP functionality unusable. This happens cause'
if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
contiguous multi-block transfers will be only supported. We must take the
flag into account when detecting the LLP support otherwise the driver just
won't work correctly.

This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
commit 98d54f81e36b ("Linux 5.6-rc4").

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Viresh Kumar <vireshk@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: dmaengine@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Serge Semin (5):
  dt-bindings: dma: dw: Replace DW DMAC legacy bindings with YAML-based
    one
  dt-bindings: dma: dw: Add max burst transaction length property
    bindings
  dmaengine: dw: Add LLP and block size config accessors
  dmaengine: dw: Introduce max burst length hw config
  dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config

 .../bindings/dma/snps,dma-spear1340.yaml      | 180 ++++++++++++++++++
 .../devicetree/bindings/dma/snps-dma.txt      |  69 -------
 drivers/dma/dw/core.c                         |  24 ++-
 drivers/dma/dw/dw.c                           |   1 +
 drivers/dma/dw/of.c                           |   9 +
 drivers/dma/dw/regs.h                         |   3 +
 include/linux/platform_data/dma-dw.h          |  22 +++
 7 files changed, 238 insertions(+), 70 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
 delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt

-- 
2.25.1


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
  2020-03-06 13:10 [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account Sergey.Semin
@ 2020-03-06 13:29 ` Andy Shevchenko
  2020-03-06 13:30   ` Andy Shevchenko
       [not found]   ` <20200306133756.0F74C8030793@mail.baikalelectronics.ru>
  0 siblings, 2 replies; 8+ messages in thread
From: Andy Shevchenko @ 2020-03-06 13:29 UTC (permalink / raw)
  To: Sergey.Semin
  Cc: Serge Semin, Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko,
	Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov,
	Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Viresh Kumar,
	Dan Williams, Vinod Koul, Rob Herring, Mark Rutland, dmaengine,
	devicetree, linux-kernel

On Fri, Mar 06, 2020 at 04:10:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote:
> From: Serge Semin <fancer.lancer@gmail.com>
> 
> Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> with currently implemented in the kernel DW DMAC driver, but there are some
> peculiarities which must be taken into account in order to have the device
> fully supported.
> 
> First of all traditionally we replaced the legacy plain text-based dt-binding
> file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> channels, which alas have different max burst length configuration.
> In particular first two channels may burst up to 128 bits (16 bytes) at a time
> while the rest of them just up to 32 bits. We must make sure that the DMA
> subsystem doesn't set values exceeding these limitations otherwise the
> controller will hang up. In third currently we discovered the problem in using
> the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> natively implemented multi-block LLP transfers support and the SPI-transfer
> length exceeds the max lock size. In this case due to asynchronous handling of
> Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> the DMAC to asynchronously execute the transfers we'd have to at least warn
> the user of the possible errors.
> 
> Finally there is a bug in the algorithm of the nollp flag detection.
> In particular even if DW DMAC parameters state the multi-block transfers
> support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> by the driver true multi-block LLP functionality unusable. This happens cause'
> if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> contiguous multi-block transfers will be only supported. We must take the
> flag into account when detecting the LLP support otherwise the driver just
> won't work correctly.
> 
> This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> commit 98d54f81e36b ("Linux 5.6-rc4").

Thank you for your series!

I'll definitely review it, but it will take time. So, I think due to late
submission this is material at least for v5.8.

> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
> Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Viresh Kumar <vireshk@kernel.org>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: dmaengine@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> Serge Semin (5):
>   dt-bindings: dma: dw: Replace DW DMAC legacy bindings with YAML-based
>     one
>   dt-bindings: dma: dw: Add max burst transaction length property
>     bindings
>   dmaengine: dw: Add LLP and block size config accessors
>   dmaengine: dw: Introduce max burst length hw config
>   dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
> 
>  .../bindings/dma/snps,dma-spear1340.yaml      | 180 ++++++++++++++++++
>  .../devicetree/bindings/dma/snps-dma.txt      |  69 -------
>  drivers/dma/dw/core.c                         |  24 ++-
>  drivers/dma/dw/dw.c                           |   1 +
>  drivers/dma/dw/of.c                           |   9 +
>  drivers/dma/dw/regs.h                         |   3 +
>  include/linux/platform_data/dma-dw.h          |  22 +++
>  7 files changed, 238 insertions(+), 70 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
>  delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt
> 
> -- 
> 2.25.1
> 

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
  2020-03-06 13:29 ` Andy Shevchenko
@ 2020-03-06 13:30   ` Andy Shevchenko
  2020-03-06 13:43     ` Vinod Koul
       [not found]     ` <20200306135050.40094803087C@mail.baikalelectronics.ru>
       [not found]   ` <20200306133756.0F74C8030793@mail.baikalelectronics.ru>
  1 sibling, 2 replies; 8+ messages in thread
From: Andy Shevchenko @ 2020-03-06 13:30 UTC (permalink / raw)
  To: Sergey.Semin
  Cc: Serge Semin, Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko,
	Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov,
	Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Viresh Kumar,
	Dan Williams, Vinod Koul, Rob Herring, Mark Rutland, dmaengine,
	devicetree, linux-kernel

On Fri, Mar 06, 2020 at 03:29:12PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 06, 2020 at 04:10:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote:
> > From: Serge Semin <fancer.lancer@gmail.com>
> > 
> > Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> > peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> > with currently implemented in the kernel DW DMAC driver, but there are some
> > peculiarities which must be taken into account in order to have the device
> > fully supported.
> > 
> > First of all traditionally we replaced the legacy plain text-based dt-binding
> > file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> > channels, which alas have different max burst length configuration.
> > In particular first two channels may burst up to 128 bits (16 bytes) at a time
> > while the rest of them just up to 32 bits. We must make sure that the DMA
> > subsystem doesn't set values exceeding these limitations otherwise the
> > controller will hang up. In third currently we discovered the problem in using
> > the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> > natively implemented multi-block LLP transfers support and the SPI-transfer
> > length exceeds the max lock size. In this case due to asynchronous handling of
> > Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> > overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> > the DMAC to asynchronously execute the transfers we'd have to at least warn
> > the user of the possible errors.
> > 
> > Finally there is a bug in the algorithm of the nollp flag detection.
> > In particular even if DW DMAC parameters state the multi-block transfers
> > support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> > by the driver true multi-block LLP functionality unusable. This happens cause'
> > if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> > contiguous multi-block transfers will be only supported. We must take the
> > flag into account when detecting the LLP support otherwise the driver just
> > won't work correctly.
> > 
> > This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> > commit 98d54f81e36b ("Linux 5.6-rc4").
> 
> Thank you for your series!
> 
> I'll definitely review it, but it will take time. So, I think due to late
> submission this is material at least for v5.8.

One thing that I can tell immediately is the broken email thread in this series.
Whenever you do a series, use `git format-patch --cover-letter --thread ...`,
so, it will link the mail properly.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
  2020-03-06 13:30   ` Andy Shevchenko
@ 2020-03-06 13:43     ` Vinod Koul
       [not found]     ` <20200306135050.40094803087C@mail.baikalelectronics.ru>
  1 sibling, 0 replies; 8+ messages in thread
From: Vinod Koul @ 2020-03-06 13:43 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Sergey.Semin, Serge Semin, Alexey Malahov, Maxim Kaurkin,
	Pavel Parkhomenko, Ramil Zaripov, Ekaterina Skachko,
	Vadim Vlasov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
	Viresh Kumar, Dan Williams, Rob Herring, Mark Rutland, dmaengine,
	devicetree, linux-kernel

On 06-03-20, 15:30, Andy Shevchenko wrote:
> On Fri, Mar 06, 2020 at 03:29:12PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 06, 2020 at 04:10:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote:
> > > From: Serge Semin <fancer.lancer@gmail.com>
> > > 
> > > Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> > > peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> > > with currently implemented in the kernel DW DMAC driver, but there are some
> > > peculiarities which must be taken into account in order to have the device
> > > fully supported.
> > > 
> > > First of all traditionally we replaced the legacy plain text-based dt-binding
> > > file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> > > channels, which alas have different max burst length configuration.
> > > In particular first two channels may burst up to 128 bits (16 bytes) at a time
> > > while the rest of them just up to 32 bits. We must make sure that the DMA
> > > subsystem doesn't set values exceeding these limitations otherwise the
> > > controller will hang up. In third currently we discovered the problem in using
> > > the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> > > natively implemented multi-block LLP transfers support and the SPI-transfer
> > > length exceeds the max lock size. In this case due to asynchronous handling of
> > > Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> > > overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> > > the DMAC to asynchronously execute the transfers we'd have to at least warn
> > > the user of the possible errors.
> > > 
> > > Finally there is a bug in the algorithm of the nollp flag detection.
> > > In particular even if DW DMAC parameters state the multi-block transfers
> > > support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> > > by the driver true multi-block LLP functionality unusable. This happens cause'
> > > if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> > > contiguous multi-block transfers will be only supported. We must take the
> > > flag into account when detecting the LLP support otherwise the driver just
> > > won't work correctly.
> > > 
> > > This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> > > commit 98d54f81e36b ("Linux 5.6-rc4").
> > 
> > Thank you for your series!
> > 
> > I'll definitely review it, but it will take time. So, I think due to late
> > submission this is material at least for v5.8.
> 
> One thing that I can tell immediately is the broken email thread in this series.
> Whenever you do a series, use `git format-patch --cover-letter --thread ...`,
> so, it will link the mail properly.

And all the dmaengine specific patches should be sent to dmaengine list,
I see only few of them on the list.. that confuses tools like
patchwork..

Pls fix these and resubmit

Thanks
-- 
~Vinod

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
       [not found]   ` <20200306133756.0F74C8030793@mail.baikalelectronics.ru>
@ 2020-03-06 13:47     ` Sergey Semin
  2020-03-06 14:11       ` Andy Shevchenko
       [not found]       ` <20200306141135.9C4F380307C2@mail.baikalelectronics.ru>
  0 siblings, 2 replies; 8+ messages in thread
From: Sergey Semin @ 2020-03-06 13:47 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko, Ramil Zaripov,
	Ekaterina Skachko, Vadim Vlasov, Thomas Bogendoerfer,
	Paul Burton, Ralf Baechle, Viresh Kumar, Dan Williams,
	Vinod Koul, Rob Herring, Mark Rutland, dmaengine, devicetree,
	linux-kernel

On Fri, Mar 06, 2020 at 03:30:35PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 06, 2020 at 03:29:12PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 06, 2020 at 04:10:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote:
> > > From: Serge Semin <fancer.lancer@gmail.com>
> > > 
> > > Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> > > peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> > > with currently implemented in the kernel DW DMAC driver, but there are some
> > > peculiarities which must be taken into account in order to have the device
> > > fully supported.
> > > 
> > > First of all traditionally we replaced the legacy plain text-based dt-binding
> > > file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> > > channels, which alas have different max burst length configuration.
> > > In particular first two channels may burst up to 128 bits (16 bytes) at a time
> > > while the rest of them just up to 32 bits. We must make sure that the DMA
> > > subsystem doesn't set values exceeding these limitations otherwise the
> > > controller will hang up. In third currently we discovered the problem in using
> > > the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> > > natively implemented multi-block LLP transfers support and the SPI-transfer
> > > length exceeds the max lock size. In this case due to asynchronous handling of
> > > Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> > > overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> > > the DMAC to asynchronously execute the transfers we'd have to at least warn
> > > the user of the possible errors.
> > > 
> > > Finally there is a bug in the algorithm of the nollp flag detection.
> > > In particular even if DW DMAC parameters state the multi-block transfers
> > > support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> > > by the driver true multi-block LLP functionality unusable. This happens cause'
> > > if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> > > contiguous multi-block transfers will be only supported. We must take the
> > > flag into account when detecting the LLP support otherwise the driver just
> > > won't work correctly.
> > > 
> > > This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> > > commit 98d54f81e36b ("Linux 5.6-rc4").
> > 
> > Thank you for your series!
> > 
> > I'll definitely review it, but it will take time. So, I think due to late
> > submission this is material at least for v5.8.
> 

Hello Andy,
Thanks for the quick response. Looking forward to get the patches
reviewed and move on with the next patchset I'll send after this. It concerns
DW APB SSI driver, which uses the changes introduced by this one. So the
sooner we finished with this patchset the better. Although I understand
that it may take some time. I've just sent over 12 patchset, which have a lot
of fixups and new drivers.)

> One thing that I can tell immediately is the broken email thread in this series.
> Whenever you do a series, use `git format-patch --cover-letter --thread ...`,
> so, it will link the mail properly.
> 

I've got thread=true in my gitconfig file, so each email should have
the proper reference and in-reply-to to the cover-letter (I see it from
the log). The problem popped up from a different place. For some reason the
automatic CC/To list extraction command didn't do the job right, so we ended
up with lacking of mailing lists in Cc's in this patchset. The command look like
this:

git send-email --cc-cmd "scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nom" \
                   --to-cmd "scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nol" \
                   --from "Serge Semin <Sergey.Semin at baikalelectronics.ru>" \
                   --smtp-server-option="-abaikal" --cover-letter -5

Regards,
-Sergey

> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
  2020-03-06 13:47     ` Sergey Semin
@ 2020-03-06 14:11       ` Andy Shevchenko
       [not found]       ` <20200306141135.9C4F380307C2@mail.baikalelectronics.ru>
  1 sibling, 0 replies; 8+ messages in thread
From: Andy Shevchenko @ 2020-03-06 14:11 UTC (permalink / raw)
  To: Sergey Semin
  Cc: Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko, Ramil Zaripov,
	Ekaterina Skachko, Vadim Vlasov, Thomas Bogendoerfer,
	Paul Burton, Ralf Baechle, Viresh Kumar, Dan Williams,
	Vinod Koul, Rob Herring, Mark Rutland, dmaengine, devicetree,
	linux-kernel

On Fri, Mar 06, 2020 at 04:47:20PM +0300, Sergey Semin wrote:
> On Fri, Mar 06, 2020 at 03:30:35PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 06, 2020 at 03:29:12PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 06, 2020 at 04:10:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote:
> > > > From: Serge Semin <fancer.lancer@gmail.com>
> > > > 
> > > > Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> > > > peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> > > > with currently implemented in the kernel DW DMAC driver, but there are some
> > > > peculiarities which must be taken into account in order to have the device
> > > > fully supported.
> > > > 
> > > > First of all traditionally we replaced the legacy plain text-based dt-binding
> > > > file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> > > > channels, which alas have different max burst length configuration.
> > > > In particular first two channels may burst up to 128 bits (16 bytes) at a time
> > > > while the rest of them just up to 32 bits. We must make sure that the DMA
> > > > subsystem doesn't set values exceeding these limitations otherwise the
> > > > controller will hang up. In third currently we discovered the problem in using
> > > > the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> > > > natively implemented multi-block LLP transfers support and the SPI-transfer
> > > > length exceeds the max lock size. In this case due to asynchronous handling of
> > > > Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> > > > overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> > > > the DMAC to asynchronously execute the transfers we'd have to at least warn
> > > > the user of the possible errors.
> > > > 
> > > > Finally there is a bug in the algorithm of the nollp flag detection.
> > > > In particular even if DW DMAC parameters state the multi-block transfers
> > > > support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> > > > by the driver true multi-block LLP functionality unusable. This happens cause'
> > > > if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> > > > contiguous multi-block transfers will be only supported. We must take the
> > > > flag into account when detecting the LLP support otherwise the driver just
> > > > won't work correctly.
> > > > 
> > > > This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> > > > commit 98d54f81e36b ("Linux 5.6-rc4").
> > > 
> > > Thank you for your series!
> > > 
> > > I'll definitely review it, but it will take time. So, I think due to late
> > > submission this is material at least for v5.8.
> > 
> 
> Hello Andy,
> Thanks for the quick response. Looking forward to get the patches
> reviewed and move on with the next patchset I'll send after this. It concerns
> DW APB SSI driver, which uses the changes introduced by this one.

> So the
> sooner we finished with this patchset the better.

Everybody will win, but review will take as long as it take. And for sure it
will miss v5.7 release cycle. Because too many patch sets sent at once
followed by schedule, we almost at v5.6-rc5.

> Although I understand
> that it may take some time. I've just sent over 12 patchset, which have a lot
> of fixups and new drivers.)
> 
> > One thing that I can tell immediately is the broken email thread in this series.
> > Whenever you do a series, use `git format-patch --cover-letter --thread ...`,
> > so, it will link the mail properly.
> > 
> 
> I've got thread=true in my gitconfig file, so each email should have
> the proper reference and in-reply-to to the cover-letter (I see it from
> the log). The problem popped up from a different place. For some reason the
> automatic CC/To list extraction command didn't do the job right, so we ended
> up with lacking of mailing lists in Cc's in this patchset. The command look like
> this:
> 
> git send-email --cc-cmd "scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nom" \
>                    --to-cmd "scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nol" \
>                    --from "Serge Semin <Sergey.Semin at baikalelectronics.ru>" \
>                    --smtp-server-option="-abaikal" --cover-letter -5

I'm talking about one which makes your Message-Id/Reference headers broken
between cover letter and the rest of the series. It might be because of missed
patches in the chain.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
       [not found]     ` <20200306135050.40094803087C@mail.baikalelectronics.ru>
@ 2020-03-09 21:45       ` Sergey Semin
  0 siblings, 0 replies; 8+ messages in thread
From: Sergey Semin @ 2020-03-09 21:45 UTC (permalink / raw)
  To: Vinod Koul
  Cc: Andy Shevchenko, Alexey Malahov, Maxim Kaurkin,
	Pavel Parkhomenko, Ramil Zaripov, Ekaterina Skachko,
	Vadim Vlasov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
	Viresh Kumar, Dan Williams, Rob Herring, Mark Rutland, dmaengine,
	devicetree, linux-kernel

On Fri, Mar 06, 2020 at 07:13:12PM +0530, Vinod Koul wrote:
> On 06-03-20, 15:30, Andy Shevchenko wrote:
> > On Fri, Mar 06, 2020 at 03:29:12PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 06, 2020 at 04:10:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote:
> > > > From: Serge Semin <fancer.lancer@gmail.com>
> > > > 
> > > > Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> > > > peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> > > > with currently implemented in the kernel DW DMAC driver, but there are some
> > > > peculiarities which must be taken into account in order to have the device
> > > > fully supported.
> > > > 
> > > > First of all traditionally we replaced the legacy plain text-based dt-binding
> > > > file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> > > > channels, which alas have different max burst length configuration.
> > > > In particular first two channels may burst up to 128 bits (16 bytes) at a time
> > > > while the rest of them just up to 32 bits. We must make sure that the DMA
> > > > subsystem doesn't set values exceeding these limitations otherwise the
> > > > controller will hang up. In third currently we discovered the problem in using
> > > > the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> > > > natively implemented multi-block LLP transfers support and the SPI-transfer
> > > > length exceeds the max lock size. In this case due to asynchronous handling of
> > > > Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> > > > overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> > > > the DMAC to asynchronously execute the transfers we'd have to at least warn
> > > > the user of the possible errors.
> > > > 
> > > > Finally there is a bug in the algorithm of the nollp flag detection.
> > > > In particular even if DW DMAC parameters state the multi-block transfers
> > > > support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> > > > by the driver true multi-block LLP functionality unusable. This happens cause'
> > > > if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> > > > contiguous multi-block transfers will be only supported. We must take the
> > > > flag into account when detecting the LLP support otherwise the driver just
> > > > won't work correctly.
> > > > 
> > > > This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> > > > commit 98d54f81e36b ("Linux 5.6-rc4").
> > > 
> > > Thank you for your series!
> > > 
> > > I'll definitely review it, but it will take time. So, I think due to late
> > > submission this is material at least for v5.8.
> > 
> > One thing that I can tell immediately is the broken email thread in this series.
> > Whenever you do a series, use `git format-patch --cover-letter --thread ...`,
> > so, it will link the mail properly.
> 
> And all the dmaengine specific patches should be sent to dmaengine list,
> I see only few of them on the list.. that confuses tools like
> patchwork..
> 
> Pls fix these and resubmit
> 

Folks. I've found out what was wrong with the emails threading. As I
said my gitconfig had the next settings set: chainreplyto = false,
thread = true. So the emails should have been formatted as expected by
the requirements. And they were on my emails client side, so I didn't see
the problem you've got.

It wasn't a first time I was submitting patches to the kernel, but it was
a first time of me using the corporate exchange server for it. It turned out
the damn server changed the Message-Id field of the emails header on the
way of transmitting the messages. If you take a look at the non-cover-letter
emails you've got from me you'll see that they actually have the In-Reply-To
and References fields with Id's referring to the original Message-Id. After
our system administrator fixes that problem and we come up with solutions
for the issues you've found in the patches I'll definitely resend the
patchset. This time I'll also make sure the emailing lists are also included
in Cc. Sorry for the inconvenience.

Regards,
-Sergey

> Thanks
> -- 
> ~Vinod

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
       [not found]       ` <20200306141135.9C4F380307C2@mail.baikalelectronics.ru>
@ 2020-03-09 22:08         ` Sergey Semin
  0 siblings, 0 replies; 8+ messages in thread
From: Sergey Semin @ 2020-03-09 22:08 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko, Ramil Zaripov,
	Ekaterina Skachko, Vadim Vlasov, Thomas Bogendoerfer,
	Paul Burton, Ralf Baechle, Viresh Kumar, Dan Williams,
	Vinod Koul, Rob Herring, Mark Rutland, dmaengine, devicetree,
	linux-kernel

On Fri, Mar 06, 2020 at 04:11:28PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 06, 2020 at 04:47:20PM +0300, Sergey Semin wrote:
> > On Fri, Mar 06, 2020 at 03:30:35PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 06, 2020 at 03:29:12PM +0200, Andy Shevchenko wrote:
> > > > On Fri, Mar 06, 2020 at 04:10:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote:
> > > > > From: Serge Semin <fancer.lancer@gmail.com>
> > > > > 
> > > > > Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> > > > > peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> > > > > with currently implemented in the kernel DW DMAC driver, but there are some
> > > > > peculiarities which must be taken into account in order to have the device
> > > > > fully supported.
> > > > > 
> > > > > First of all traditionally we replaced the legacy plain text-based dt-binding
> > > > > file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> > > > > channels, which alas have different max burst length configuration.
> > > > > In particular first two channels may burst up to 128 bits (16 bytes) at a time
> > > > > while the rest of them just up to 32 bits. We must make sure that the DMA
> > > > > subsystem doesn't set values exceeding these limitations otherwise the
> > > > > controller will hang up. In third currently we discovered the problem in using
> > > > > the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> > > > > natively implemented multi-block LLP transfers support and the SPI-transfer
> > > > > length exceeds the max lock size. In this case due to asynchronous handling of
> > > > > Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> > > > > overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> > > > > the DMAC to asynchronously execute the transfers we'd have to at least warn
> > > > > the user of the possible errors.
> > > > > 
> > > > > Finally there is a bug in the algorithm of the nollp flag detection.
> > > > > In particular even if DW DMAC parameters state the multi-block transfers
> > > > > support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> > > > > by the driver true multi-block LLP functionality unusable. This happens cause'
> > > > > if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> > > > > contiguous multi-block transfers will be only supported. We must take the
> > > > > flag into account when detecting the LLP support otherwise the driver just
> > > > > won't work correctly.
> > > > > 
> > > > > This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> > > > > commit 98d54f81e36b ("Linux 5.6-rc4").
> > > > 
> > > > Thank you for your series!
> > > > 
> > > > I'll definitely review it, but it will take time. So, I think due to late
> > > > submission this is material at least for v5.8.
> > > 
> > 
> > Hello Andy,
> > Thanks for the quick response. Looking forward to get the patches
> > reviewed and move on with the next patchset I'll send after this. It concerns
> > DW APB SSI driver, which uses the changes introduced by this one.
> 
> > So the
> > sooner we finished with this patchset the better.
> 
> Everybody will win, but review will take as long as it take. And for sure it
> will miss v5.7 release cycle. Because too many patch sets sent at once
> followed by schedule, we almost at v5.6-rc5.
> 

Yeah. 13 patchsets is a lot of work to review. I was just saying, that
even though there are many patches sent, there are even more being
scheduled for submission after that, which rely on the alterations
provided by these patches. Though the pacthes dependency may change
seeing you have issues regarding some of them.)

> > Although I understand
> > that it may take some time. I've just sent over 12 patchset, which have a lot
> > of fixups and new drivers.)
> > 
> > > One thing that I can tell immediately is the broken email thread in this series.
> > > Whenever you do a series, use `git format-patch --cover-letter --thread ...`,
> > > so, it will link the mail properly.
> > > 
> > 
> > I've got thread=true in my gitconfig file, so each email should have
> > the proper reference and in-reply-to to the cover-letter (I see it from
> > the log). The problem popped up from a different place. For some reason the
> > automatic CC/To list extraction command didn't do the job right, so we ended
> > up with lacking of mailing lists in Cc's in this patchset. The command look like
> > this:
> > 
> > git send-email --cc-cmd "scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nom" \
> >                    --to-cmd "scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nol" \
> >                    --from "Serge Semin <Sergey.Semin at baikalelectronics.ru>" \
> >                    --smtp-server-option="-abaikal" --cover-letter -5
> 
> I'm talking about one which makes your Message-Id/Reference headers broken
> between cover letter and the rest of the series. It might be because of missed
> patches in the chain.
> 

Ok. Now I see what you meant. First I had a thought there was some
misunderstanding on your or my side, because my neomutt client didn't
show any Ids confusion. But after another maintainer complained about
the same problem I realized that the issue must be at someplace I
couldn't have noticed. Then I thought that the outgoing email server
could have changed the order of the sent emails. But it turned out the
problem was in the message Ids replacement performed by our corporate
exchange server. Please see the email I've sent in reply to the Vinod
comment regarding the emailing list Ccing. It describes what was really
wrong with the threading config.

Regards,
-Segey

> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-06 13:10 [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account Sergey.Semin
2020-03-06 13:29 ` Andy Shevchenko
2020-03-06 13:30   ` Andy Shevchenko
2020-03-06 13:43     ` Vinod Koul
     [not found]     ` <20200306135050.40094803087C@mail.baikalelectronics.ru>
2020-03-09 21:45       ` Sergey Semin
     [not found]   ` <20200306133756.0F74C8030793@mail.baikalelectronics.ru>
2020-03-06 13:47     ` Sergey Semin
2020-03-06 14:11       ` Andy Shevchenko
     [not found]       ` <20200306141135.9C4F380307C2@mail.baikalelectronics.ru>
2020-03-09 22:08         ` Sergey Semin

dmaengine Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dmaengine/0 dmaengine/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dmaengine dmaengine/ https://lore.kernel.org/dmaengine \
		dmaengine@vger.kernel.org
	public-inbox-index dmaengine

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.dmaengine


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git