[PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Laurent Pinchart]

Hello,

This patch sets adds a new driver for the DMA controller found in the R-Car
Gen2 SoCs under the name "Direct Memory Access Controller for System
(SYS-DMAC)". Support for the "Realtime Direct Memory Access Controller
(RT-DMAC)" and "Direct Memory Access Controller for Audio (Audio-DMAC)" will
be added later.

For the rationale of why a new driver is needed, and performance figures,
please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2 DMA Controller
driver") [1].

Support for hardware descriptors lists is not included in this series to keep
it simple and hopefully get it merged in v3.19. I'll post it as a separate
series. No change to the DT bindings will be needed.

The first three patches should go through the DMA engine tree, while the last
six patches should go through the Renesas tree. Simon, as the DT bindings have
been merged already, I believe you can queue up the arch patches without
waiting for the driver patches to be merged.

Known issues are

- Untested cyclic DMA transfers. I've done my best to fix the related issues
  from v2, but I haven't been able to test audio with the R-Car platforms (see
  [2]). Morimoto-san, if you could help me with audio testing I'd be grateful.

- Stub system PM implementation. I'm working on this.

- Risk of conflict with Maxime's DMA engine rework series.

I believe the first two issues are not show stoppers. I can rebase the patches
if Maxime's patches get merged first.

Changes since v2: 
 
- Replace several occurrences of size_t with unsigned int
- Remove unneeded local variable initialization
- Compute maximum transfer size at runtime
- Typo fixes
- Replace WARN_ON with WARN_ON_ONCE in interrupt handler
- Validate the number of channels
- Reset the device before enabling interrupts
- Use DMA_SLAVE_BUSWIDTH_* constants instead of numerical values
- Use devm_kasprintf
- Update to the new prep_dma_cyclic API
- Filter out channels from unrelated devices
- Fix typo in register definition
- Rename rcar_dmac_hw_desc to rcar_dmac_xfer_chunk
- Ignore the deprecated dma_slave_config direction field
- Allocate memory with GFP_NOWAIT in prep handlers
- Split runtime and system PM
- Move runtime PM to channel alloc/fre

Changes since v1:

- Allocate IRQ name strings dynamically
- Only call the callback function if one is supplied
- Don't overallocate sg list entries
- Allocate sg list entries with GFP_KERNEL
- Don't manage function clock manually
- Make channel filter ignore unrelated devices
- Document why the cyclic sg list is kcalloc'ed
- Remove ch15 from interrupt names in DT
- Replace CONFIG_OF with OF in Kconfig

[1] http://www.spinics.net/lists/linux-sh/msg33768.html
[2] http://www.spinics.net/lists/linux-sh/msg36474.html

Laurent Pinchart (9):
  dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
  dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
  dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
    driver
  ARM: shmobile: r8a7790: Rename mmcif node to mmc
  ARM: shmobile: r8a7791: Add MMCIF0 DT node
  ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
  ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
  ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
  ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes

 .../devicetree/bindings/dma/renesas,rcar-dmac.txt  |    3 -
 arch/arm/boot/dts/r8a7790.dtsi                     |   14 +-
 arch/arm/boot/dts/r8a7791.dtsi                     |   17 +
 drivers/dma/sh/Kconfig                             |    8 +
 drivers/dma/sh/Makefile                            |    1 +
 drivers/dma/sh/rcar-dmac.c                         | 1533 ++++++++++++++++++++
 include/linux/dmaengine.h                          |    3 +
 7 files changed, 1575 insertions(+), 4 deletions(-)
 create mode 100644 drivers/dma/sh/rcar-dmac.c

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Simon Horman]

On Sun, Oct 26, 2014 at 07:40:07PM +0200, Laurent Pinchart wrote:
> Hello,
> 
> This patch sets adds a new driver for the DMA controller found in the R-Car
> Gen2 SoCs under the name "Direct Memory Access Controller for System
> (SYS-DMAC)". Support for the "Realtime Direct Memory Access Controller
> (RT-DMAC)" and "Direct Memory Access Controller for Audio (Audio-DMAC)" will
> be added later.
> 
> For the rationale of why a new driver is needed, and performance figures,
> please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2 DMA Controller
> driver") [1].
> 
> Support for hardware descriptors lists is not included in this series to keep
> it simple and hopefully get it merged in v3.19. I'll post it as a separate
> series. No change to the DT bindings will be needed.
> 
> The first three patches should go through the DMA engine tree, while the last
> six patches should go through the Renesas tree. Simon, as the DT bindings have
> been merged already, I believe you can queue up the arch patches without
> waiting for the driver patches to be merged.

Thanks, I have queued up those patches: the last 6 of this series.

> Known issues are
> 
> - Untested cyclic DMA transfers. I've done my best to fix the related issues
>   from v2, but I haven't been able to test audio with the R-Car platforms (see
>   [2]). Morimoto-san, if you could help me with audio testing I'd be grateful.
> 
> - Stub system PM implementation. I'm working on this.
> 
> - Risk of conflict with Maxime's DMA engine rework series.
> 
> I believe the first two issues are not show stoppers. I can rebase the patches
> if Maxime's patches get merged first.
> 
> Changes since v2: 
>  
> - Replace several occurrences of size_t with unsigned int
> - Remove unneeded local variable initialization
> - Compute maximum transfer size at runtime
> - Typo fixes
> - Replace WARN_ON with WARN_ON_ONCE in interrupt handler
> - Validate the number of channels
> - Reset the device before enabling interrupts
> - Use DMA_SLAVE_BUSWIDTH_* constants instead of numerical values
> - Use devm_kasprintf
> - Update to the new prep_dma_cyclic API
> - Filter out channels from unrelated devices
> - Fix typo in register definition
> - Rename rcar_dmac_hw_desc to rcar_dmac_xfer_chunk
> - Ignore the deprecated dma_slave_config direction field
> - Allocate memory with GFP_NOWAIT in prep handlers
> - Split runtime and system PM
> - Move runtime PM to channel alloc/fre
> 
> Changes since v1:
> 
> - Allocate IRQ name strings dynamically
> - Only call the callback function if one is supplied
> - Don't overallocate sg list entries
> - Allocate sg list entries with GFP_KERNEL
> - Don't manage function clock manually
> - Make channel filter ignore unrelated devices
> - Document why the cyclic sg list is kcalloc'ed
> - Remove ch15 from interrupt names in DT
> - Replace CONFIG_OF with OF in Kconfig
> 
> [1] http://www.spinics.net/lists/linux-sh/msg33768.html
> [2] http://www.spinics.net/lists/linux-sh/msg36474.html
> 
> Laurent Pinchart (9):
>   dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
>   dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
>   dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
>     driver
>   ARM: shmobile: r8a7790: Rename mmcif node to mmc
>   ARM: shmobile: r8a7791: Add MMCIF0 DT node
>   ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
>   ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
>   ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
>   ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes
> 
>  .../devicetree/bindings/dma/renesas,rcar-dmac.txt  |    3 -
>  arch/arm/boot/dts/r8a7790.dtsi                     |   14 +-
>  arch/arm/boot/dts/r8a7791.dtsi                     |   17 +
>  drivers/dma/sh/Kconfig                             |    8 +
>  drivers/dma/sh/Makefile                            |    1 +
>  drivers/dma/sh/rcar-dmac.c                         | 1533 ++++++++++++++++++++
>  include/linux/dmaengine.h                          |    3 +
>  7 files changed, 1575 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/dma/sh/rcar-dmac.c
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Kuninori Morimoto]

Hi
Cc Simon

> Laurent Pinchart (9):
>   dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
>   dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
>   dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
>     driver
>   ARM: shmobile: r8a7790: Rename mmcif node to mmc
>   ARM: shmobile: r8a7791: Add MMCIF0 DT node
>   ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
>   ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
>   ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
>   ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes
> 
>  .../devicetree/bindings/dma/renesas,rcar-dmac.txt  |    3 -
>  arch/arm/boot/dts/r8a7790.dtsi                     |   14 +-
>  arch/arm/boot/dts/r8a7791.dtsi                     |   17 +
>  drivers/dma/sh/Kconfig                             |    8 +
>  drivers/dma/sh/Makefile                            |    1 +
>  drivers/dma/sh/rcar-dmac.c                         | 1533 ++++++++++++++++++++
>  include/linux/dmaengine.h                          |    3 +
>  7 files changed, 1575 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/dma/sh/rcar-dmac.c

On Lager board + SDHI

Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Current SDHI driver + DMAC is working, but super slow,
especially, write case....


Best regards
---
Kuninori Morimoto

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Laurent Pinchart]

Hi Morimoto-san,

On Monday 27 October 2014 20:03:56 Kuninori Morimoto wrote:
> Hi
> Cc Simon
> 
> > Laurent Pinchart (9):
> >   dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
> >   dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
> >   dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
> >   
> >     driver
> >   
> >   ARM: shmobile: r8a7790: Rename mmcif node to mmc
> >   ARM: shmobile: r8a7791: Add MMCIF0 DT node
> >   ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
> >   ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
> >   ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
> >   ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes
> >  
> >  .../devicetree/bindings/dma/renesas,rcar-dmac.txt  |    3 -
> >  arch/arm/boot/dts/r8a7790.dtsi                     |   14 +-
> >  arch/arm/boot/dts/r8a7791.dtsi                     |   17 +
> >  drivers/dma/sh/Kconfig                             |    8 +
> >  drivers/dma/sh/Makefile                            |    1 +
> >  drivers/dma/sh/rcar-dmac.c                         | 1533 +++++++++++++++
> >  include/linux/dmaengine.h                          |    3 +
> >  7 files changed, 1575 insertions(+), 4 deletions(-)
> >  create mode 100644 drivers/dma/sh/rcar-dmac.c
> 
> On Lager board + SDHI
> 
> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Thank you.

> Current SDHI driver + DMAC is working, but super slow,
> especially, write case....

*sigh* I'll test that.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Kuninori Morimoto]

Hi Laurent, Simon

> > On Lager board + SDHI
> > 
> > Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> 
> Thank you.
> 
> > Current SDHI driver + DMAC is working, but super slow,
> > especially, write case....
> 
> *sigh* I'll test that.

Maybe this is SDHI side issue (?)
Buswidth/clock/setting etc etc etc...
No one used SDHI + DMA in DT and in R-Car Gen2 today.
So, I guess it is very safety if we can ignore SDHI + DMA in upstream
-> Simon ?

Best regards
---
Kuninori Morimoto

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Magnus Damm]

Hi Laurent,

On Wed, Oct 29, 2014 at 6:02 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Morimoto-san,
>
> On Monday 27 October 2014 20:03:56 Kuninori Morimoto wrote:
>> Hi
>> Cc Simon
>>
>> > Laurent Pinchart (9):
>> >   dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
>> >   dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
>> >   dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
>> >
>> >     driver
>> >
>> >   ARM: shmobile: r8a7790: Rename mmcif node to mmc
>> >   ARM: shmobile: r8a7791: Add MMCIF0 DT node
>> >   ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
>> >   ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
>> >   ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
>> >   ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes
>> >
>> >  .../devicetree/bindings/dma/renesas,rcar-dmac.txt  |    3 -
>> >  arch/arm/boot/dts/r8a7790.dtsi                     |   14 +-
>> >  arch/arm/boot/dts/r8a7791.dtsi                     |   17 +
>> >  drivers/dma/sh/Kconfig                             |    8 +
>> >  drivers/dma/sh/Makefile                            |    1 +
>> >  drivers/dma/sh/rcar-dmac.c                         | 1533 +++++++++++++++
>> >  include/linux/dmaengine.h                          |    3 +
>> >  7 files changed, 1575 insertions(+), 4 deletions(-)
>> >  create mode 100644 drivers/dma/sh/rcar-dmac.c
>>
>> On Lager board + SDHI
>>
>> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Thank you.
>
>> Current SDHI driver + DMAC is working, but super slow,
>> especially, write case....
>
> *sigh* I'll test that.

If you have energy to deal with this then that is of course greatly appreciated.

From my point of view it is however easier to simply ignore SDHI for
now and remove those patches from this patch series. Once all the
dependencies are sorted out for the new DMAC driver and all code is
upstream then perhaps the SDHI driver is in a better shape and allows
for more easy DMA enablement.

Cheers,

/ magnus

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Magnus Damm]

On Mon, Oct 27, 2014 at 2:40 AM, Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> Hello,
>
> This patch sets adds a new driver for the DMA controller found in the R-Car
> Gen2 SoCs under the name "Direct Memory Access Controller for System
> (SYS-DMAC)". Support for the "Realtime Direct Memory Access Controller
> (RT-DMAC)" and "Direct Memory Access Controller for Audio (Audio-DMAC)" will
> be added later.
>
> For the rationale of why a new driver is needed, and performance figures,
> please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2 DMA Controller
> driver") [1].
>
> Support for hardware descriptors lists is not included in this series to keep
> it simple and hopefully get it merged in v3.19. I'll post it as a separate
> series. No change to the DT bindings will be needed.
>
> The first three patches should go through the DMA engine tree, while the last
> six patches should go through the Renesas tree. Simon, as the DT bindings have
> been merged already, I believe you can queue up the arch patches without
> waiting for the driver patches to be merged.
>
> Known issues are
>
> - Untested cyclic DMA transfers. I've done my best to fix the related issues
>   from v2, but I haven't been able to test audio with the R-Car platforms (see
>   [2]). Morimoto-san, if you could help me with audio testing I'd be grateful.
>
> - Stub system PM implementation. I'm working on this.
>
> - Risk of conflict with Maxime's DMA engine rework series.
>
> I believe the first two issues are not show stoppers. I can rebase the patches
> if Maxime's patches get merged first.
>
> Changes since v2:
>
> - Replace several occurrences of size_t with unsigned int
> - Remove unneeded local variable initialization
> - Compute maximum transfer size at runtime
> - Typo fixes
> - Replace WARN_ON with WARN_ON_ONCE in interrupt handler
> - Validate the number of channels
> - Reset the device before enabling interrupts
> - Use DMA_SLAVE_BUSWIDTH_* constants instead of numerical values
> - Use devm_kasprintf
> - Update to the new prep_dma_cyclic API
> - Filter out channels from unrelated devices
> - Fix typo in register definition
> - Rename rcar_dmac_hw_desc to rcar_dmac_xfer_chunk
> - Ignore the deprecated dma_slave_config direction field
> - Allocate memory with GFP_NOWAIT in prep handlers
> - Split runtime and system PM
> - Move runtime PM to channel alloc/fre
>
> Changes since v1:
>
> - Allocate IRQ name strings dynamically
> - Only call the callback function if one is supplied
> - Don't overallocate sg list entries
> - Allocate sg list entries with GFP_KERNEL
> - Don't manage function clock manually
> - Make channel filter ignore unrelated devices
> - Document why the cyclic sg list is kcalloc'ed
> - Remove ch15 from interrupt names in DT
> - Replace CONFIG_OF with OF in Kconfig
>
> [1] http://www.spinics.net/lists/linux-sh/msg33768.html
> [2] http://www.spinics.net/lists/linux-sh/msg36474.html
>
> Laurent Pinchart (9):
>   dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
>   dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
>   dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
>     driver
>   ARM: shmobile: r8a7790: Rename mmcif node to mmc
>   ARM: shmobile: r8a7791: Add MMCIF0 DT node
>   ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
>   ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
>   ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
>   ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes

Hi Laurent,

I've now tested this series briefly together with QSPI on Koelsch, and
on top of that I've also done a prototype back port to LTSI-3.14. All
seems well except this minor Kconfig adjustment that I needed to do to
handle the case when we only enable this driver:

--- 0001/drivers/dma/Makefile
+++ work/drivers/dma/Makefile 2014-10-29 13:14:24.000000000 +0900
@@ -20,6 +20,7 @@ obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_MX3_IPU) += ipu/
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
 obj-$(CONFIG_SH_DMAE_BASE) += sh/
+obj-$(CONFIG_RCAR_DMAC) += sh/
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_IMX_SDMA) += imx-sdma.o

Not the prettiest solution, but at least it makes the code compile
regardless of SH_DMAE_BASE.
Can you please consider folding this hunk into next version of your series?

Thanks,

/ magnus

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Laurent Pinchart]

Hi Magnus, Morimoto-san,

On Wednesday 29 October 2014 11:36:03 Magnus Damm wrote:
> On Wed, Oct 29, 2014 at 6:02 AM, Laurent Pinchart wrote:
> > On Monday 27 October 2014 20:03:56 Kuninori Morimoto wrote:
> >> Hi
> >> Cc Simon
> >> 
> >> > Laurent Pinchart (9):
> >> >   dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
> >> >   dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
> >> >   dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
> >> >   
> >> >     driver
> >> >   
> >> >   ARM: shmobile: r8a7790: Rename mmcif node to mmc
> >> >   ARM: shmobile: r8a7791: Add MMCIF0 DT node
> >> >   ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
> >> >   ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
> >> >   ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
> >> >   ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes
> >> >  
> >> >  .../devicetree/bindings/dma/renesas,rcar-dmac.txt  |    3 -
> >> >  arch/arm/boot/dts/r8a7790.dtsi                     |   14 +-
> >> >  arch/arm/boot/dts/r8a7791.dtsi                     |   17 +
> >> >  drivers/dma/sh/Kconfig                             |    8 +
> >> >  drivers/dma/sh/Makefile                            |    1 +
> >> >  drivers/dma/sh/rcar-dmac.c                         | 1533 ++++++++++++
> >> >  include/linux/dmaengine.h                          |    3 +
> >> >  7 files changed, 1575 insertions(+), 4 deletions(-)
> >> >  create mode 100644 drivers/dma/sh/rcar-dmac.c
> >> 
> >> On Lager board + SDHI
> >> 
> >> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > 
> > Thank you.
> > 
> >> Current SDHI driver + DMAC is working, but super slow,
> >> especially, write case....
> > 
> > *sigh* I'll test that.
> 
> If you have energy to deal with this then that is of course greatly
> appreciated.

I've performed quick SDHI performance tests yesterday. Read performance were 
around 7.5% lower with DMA support. Write performances varied but seemed 
similar on average.

- PIO

# time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
262144+0 records in
262144+0 records out
real    0m 6.89s
user    0m 0.19s
sys     0m 2.71s

# time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
262144+0 records in
262144+0 records out
real    0m 6.95s
user    0m 0.05s
sys     0m 2.82s

# time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
32+0 records in
32+0 records out
real    1m 55.37s
user    0m 0.00s
sys     0m 0.72s

# time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
32+0 records in
32+0 records out
real    1m 53.44s
user    0m 0.00s
sys     0m 0.71s

- DMA

# time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
32+0 records in
32+0 records out
real    0m 7.39s
user    0m 0.00s
sys     0m 0.60s

# time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
32+0 records in
32+0 records out
real    0m 7.46s
user    0m 0.00s
sys     0m 0.63s

# time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
32768+0 records in
32768+0 records out
real    1m 54.45s
user    0m 0.00s
sys     0m 0.71s

# time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
32768+0 records in
32768+0 records out
real    1m 55.61s
user    0m 0.02s
sys     0m 0.64s

This is without using hardware descriptors. I'll test that next.

> From my point of view it is however easier to simply ignore SDHI for
> now and remove those patches from this patch series. Once all the
> dependencies are sorted out for the new DMAC driver and all code is
> upstream then perhaps the SDHI driver is in a better shape and allows
> for more easy DMA enablement.

-- 
Regards,

Laurent Pinchart

RE: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Phil Edworthy]

SGkgTWFnbnVzLA0KDQpPbiAyOSBPY3RvYmVyIDIwMTQgMDc6MjQsIE1hZ251cyB3cm90ZToNCj4g
T24gTW9uLCBPY3QgMjcsIDIwMTQgYXQgMjo0MCBBTSwgTGF1cmVudCBQaW5jaGFydA0KPiA8bGF1
cmVudC5waW5jaGFydCtyZW5lc2FzQGlkZWFzb25ib2FyZC5jb20+IHdyb3RlOg0KPiA+IEhlbGxv
LA0KPiA+DQo+ID4gVGhpcyBwYXRjaCBzZXRzIGFkZHMgYSBuZXcgZHJpdmVyIGZvciB0aGUgRE1B
IGNvbnRyb2xsZXIgZm91bmQgaW4gdGhlIFItQ2FyDQo+ID4gR2VuMiBTb0NzIHVuZGVyIHRoZSBu
YW1lICJEaXJlY3QgTWVtb3J5IEFjY2VzcyBDb250cm9sbGVyIGZvciBTeXN0ZW0NCj4gPiAoU1lT
LURNQUMpIi4gU3VwcG9ydCBmb3IgdGhlICJSZWFsdGltZSBEaXJlY3QgTWVtb3J5IEFjY2VzcyBD
b250cm9sbGVyDQo+ID4gKFJULURNQUMpIiBhbmQgIkRpcmVjdCBNZW1vcnkgQWNjZXNzIENvbnRy
b2xsZXIgZm9yIEF1ZGlvIChBdWRpby1ETUFDKSINCj4gd2lsbA0KPiA+IGJlIGFkZGVkIGxhdGVy
Lg0KPiA+DQo+ID4gRm9yIHRoZSByYXRpb25hbGUgb2Ygd2h5IGEgbmV3IGRyaXZlciBpcyBuZWVk
ZWQsIGFuZCBwZXJmb3JtYW5jZSBmaWd1cmVzLA0KPiA+IHBsZWFzZSBzZWUgdGhlIGNvdmVyIGxl
dHRlciBvZiB2MSAoIltQQVRDSCAwLzddIFItQ2FyIEdlbjIgRE1BIENvbnRyb2xsZXINCj4gPiBk
cml2ZXIiKSBbMV0uDQo+ID4NCj4gPiBTdXBwb3J0IGZvciBoYXJkd2FyZSBkZXNjcmlwdG9ycyBs
aXN0cyBpcyBub3QgaW5jbHVkZWQgaW4gdGhpcyBzZXJpZXMgdG8ga2VlcA0KPiA+IGl0IHNpbXBs
ZSBhbmQgaG9wZWZ1bGx5IGdldCBpdCBtZXJnZWQgaW4gdjMuMTkuIEknbGwgcG9zdCBpdCBhcyBh
IHNlcGFyYXRlDQo+ID4gc2VyaWVzLiBObyBjaGFuZ2UgdG8gdGhlIERUIGJpbmRpbmdzIHdpbGwg
YmUgbmVlZGVkLg0KPiA+DQo+ID4gVGhlIGZpcnN0IHRocmVlIHBhdGNoZXMgc2hvdWxkIGdvIHRo
cm91Z2ggdGhlIERNQSBlbmdpbmUgdHJlZSwgd2hpbGUgdGhlIGxhc3QNCj4gPiBzaXggcGF0Y2hl
cyBzaG91bGQgZ28gdGhyb3VnaCB0aGUgUmVuZXNhcyB0cmVlLiBTaW1vbiwgYXMgdGhlIERUIGJp
bmRpbmdzIGhhdmUNCj4gPiBiZWVuIG1lcmdlZCBhbHJlYWR5LCBJIGJlbGlldmUgeW91IGNhbiBx
dWV1ZSB1cCB0aGUgYXJjaCBwYXRjaGVzIHdpdGhvdXQNCj4gPiB3YWl0aW5nIGZvciB0aGUgZHJp
dmVyIHBhdGNoZXMgdG8gYmUgbWVyZ2VkLg0KPiA+DQo+ID4gS25vd24gaXNzdWVzIGFyZQ0KPiA+
DQo+ID4gLSBVbnRlc3RlZCBjeWNsaWMgRE1BIHRyYW5zZmVycy4gSSd2ZSBkb25lIG15IGJlc3Qg
dG8gZml4IHRoZSByZWxhdGVkIGlzc3Vlcw0KPiA+ICAgZnJvbSB2MiwgYnV0IEkgaGF2ZW4ndCBi
ZWVuIGFibGUgdG8gdGVzdCBhdWRpbyB3aXRoIHRoZSBSLUNhciBwbGF0Zm9ybXMgKHNlZQ0KPiA+
ICAgWzJdKS4gTW9yaW1vdG8tc2FuLCBpZiB5b3UgY291bGQgaGVscCBtZSB3aXRoIGF1ZGlvIHRl
c3RpbmcgSSdkIGJlIGdyYXRlZnVsLg0KPiA+DQo+ID4gLSBTdHViIHN5c3RlbSBQTSBpbXBsZW1l
bnRhdGlvbi4gSSdtIHdvcmtpbmcgb24gdGhpcy4NCj4gPg0KPiA+IC0gUmlzayBvZiBjb25mbGlj
dCB3aXRoIE1heGltZSdzIERNQSBlbmdpbmUgcmV3b3JrIHNlcmllcy4NCj4gPg0KPiA+IEkgYmVs
aWV2ZSB0aGUgZmlyc3QgdHdvIGlzc3VlcyBhcmUgbm90IHNob3cgc3RvcHBlcnMuIEkgY2FuIHJl
YmFzZSB0aGUgcGF0Y2hlcw0KPiA+IGlmIE1heGltZSdzIHBhdGNoZXMgZ2V0IG1lcmdlZCBmaXJz
dC4NCj4gPg0KPiA+IENoYW5nZXMgc2luY2UgdjI6DQo+ID4NCj4gPiAtIFJlcGxhY2Ugc2V2ZXJh
bCBvY2N1cnJlbmNlcyBvZiBzaXplX3Qgd2l0aCB1bnNpZ25lZCBpbnQNCj4gPiAtIFJlbW92ZSB1
bm5lZWRlZCBsb2NhbCB2YXJpYWJsZSBpbml0aWFsaXphdGlvbg0KPiA+IC0gQ29tcHV0ZSBtYXhp
bXVtIHRyYW5zZmVyIHNpemUgYXQgcnVudGltZQ0KPiA+IC0gVHlwbyBmaXhlcw0KPiA+IC0gUmVw
bGFjZSBXQVJOX09OIHdpdGggV0FSTl9PTl9PTkNFIGluIGludGVycnVwdCBoYW5kbGVyDQo+ID4g
LSBWYWxpZGF0ZSB0aGUgbnVtYmVyIG9mIGNoYW5uZWxzDQo+ID4gLSBSZXNldCB0aGUgZGV2aWNl
IGJlZm9yZSBlbmFibGluZyBpbnRlcnJ1cHRzDQo+ID4gLSBVc2UgRE1BX1NMQVZFX0JVU1dJRFRI
XyogY29uc3RhbnRzIGluc3RlYWQgb2YgbnVtZXJpY2FsIHZhbHVlcw0KPiA+IC0gVXNlIGRldm1f
a2FzcHJpbnRmDQo+ID4gLSBVcGRhdGUgdG8gdGhlIG5ldyBwcmVwX2RtYV9jeWNsaWMgQVBJDQo+
ID4gLSBGaWx0ZXIgb3V0IGNoYW5uZWxzIGZyb20gdW5yZWxhdGVkIGRldmljZXMNCj4gPiAtIEZp
eCB0eXBvIGluIHJlZ2lzdGVyIGRlZmluaXRpb24NCj4gPiAtIFJlbmFtZSByY2FyX2RtYWNfaHdf
ZGVzYyB0byByY2FyX2RtYWNfeGZlcl9jaHVuaw0KPiA+IC0gSWdub3JlIHRoZSBkZXByZWNhdGVk
IGRtYV9zbGF2ZV9jb25maWcgZGlyZWN0aW9uIGZpZWxkDQo+ID4gLSBBbGxvY2F0ZSBtZW1vcnkg
d2l0aCBHRlBfTk9XQUlUIGluIHByZXAgaGFuZGxlcnMNCj4gPiAtIFNwbGl0IHJ1bnRpbWUgYW5k
IHN5c3RlbSBQTQ0KPiA+IC0gTW92ZSBydW50aW1lIFBNIHRvIGNoYW5uZWwgYWxsb2MvZnJlDQo+
ID4NCj4gPiBDaGFuZ2VzIHNpbmNlIHYxOg0KPiA+DQo+ID4gLSBBbGxvY2F0ZSBJUlEgbmFtZSBz
dHJpbmdzIGR5bmFtaWNhbGx5DQo+ID4gLSBPbmx5IGNhbGwgdGhlIGNhbGxiYWNrIGZ1bmN0aW9u
IGlmIG9uZSBpcyBzdXBwbGllZA0KPiA+IC0gRG9uJ3Qgb3ZlcmFsbG9jYXRlIHNnIGxpc3QgZW50
cmllcw0KPiA+IC0gQWxsb2NhdGUgc2cgbGlzdCBlbnRyaWVzIHdpdGggR0ZQX0tFUk5FTA0KPiA+
IC0gRG9uJ3QgbWFuYWdlIGZ1bmN0aW9uIGNsb2NrIG1hbnVhbGx5DQo+ID4gLSBNYWtlIGNoYW5u
ZWwgZmlsdGVyIGlnbm9yZSB1bnJlbGF0ZWQgZGV2aWNlcw0KPiA+IC0gRG9jdW1lbnQgd2h5IHRo
ZSBjeWNsaWMgc2cgbGlzdCBpcyBrY2FsbG9jJ2VkDQo+ID4gLSBSZW1vdmUgY2gxNSBmcm9tIGlu
dGVycnVwdCBuYW1lcyBpbiBEVA0KPiA+IC0gUmVwbGFjZSBDT05GSUdfT0Ygd2l0aCBPRiBpbiBL
Y29uZmlnDQo+ID4NCj4gPiBbMV0gaHR0cDovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9saW51eC1z
aC9tc2czMzc2OC5odG1sDQo+ID4gWzJdIGh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvbGlu
dXgtc2gvbXNnMzY0NzQuaHRtbA0KPiA+DQo+ID4gTGF1cmVudCBQaW5jaGFydCAoOSk6DQo+ID4g
ICBkbWFlbmdpbmU6IEFkZCAxNiBieXRlcywgMzIgYnl0ZXMgYW5kIDY0IGJ5dGVzIGJ1cyB3aWR0
aHMNCj4gPiAgIGRtYWVuZ2luZTogcmNhci1kbWFjOiBSZW1vdmUgZHVwbGljYXRlIHNlbnRlbmNl
IGZyb20gRFQgYmluZGluZ3MNCj4gPiAgIGRtYWVuZ2luZTogcmNhci1kbWFjOiBBZGQgUmVuZXNh
cyBSLUNhciBHZW4yIERNQSBDb250cm9sbGVyIChETUFDKQ0KPiA+ICAgICBkcml2ZXINCj4gPiAg
IEFSTTogc2htb2JpbGU6IHI4YTc3OTA6IFJlbmFtZSBtbWNpZiBub2RlIHRvIG1tYw0KPiA+ICAg
QVJNOiBzaG1vYmlsZTogcjhhNzc5MTogQWRkIE1NQ0lGMCBEVCBub2RlDQo+ID4gICBBUk06IHNo
bW9iaWxlOiByOGE3NzkwOiBSZWZlcmVuY2UgRE1BIGNoYW5uZWxzIGluIE1NQ0lGIERUIG5vZGVz
DQo+ID4gICBBUk06IHNobW9iaWxlOiByOGE3NzkxOiBSZWZlcmVuY2UgRE1BIGNoYW5uZWxzIGlu
IE1NQ0lGIERUIG5vZGUNCj4gPiAgIEFSTTogc2htb2JpbGU6IHI4YTc3OTA6IFJlZmVyZW5jZSBE
TUEgY2hhbm5lbHMgaW4gU0RISSBEVCBub2Rlcw0KPiA+ICAgQVJNOiBzaG1vYmlsZTogcjhhNzc5
MTogUmVmZXJlbmNlIERNQSBjaGFubmVscyBpbiBTREhJIERUIG5vZGVzDQo+IA0KPiBIaSBMYXVy
ZW50LA0KPiANCj4gSSd2ZSBub3cgdGVzdGVkIHRoaXMgc2VyaWVzIGJyaWVmbHkgdG9nZXRoZXIg
d2l0aCBRU1BJIG9uIEtvZWxzY2gsIGFuZA0KPiBvbiB0b3Agb2YgdGhhdCBJJ3ZlIGFsc28gZG9u
ZSBhIHByb3RvdHlwZSBiYWNrIHBvcnQgdG8gTFRTSS0zLjE0LiBBbGwNCj4gc2VlbXMgd2VsbCBl
eGNlcHQgdGhpcyBtaW5vciBLY29uZmlnIGFkanVzdG1lbnQgdGhhdCBJIG5lZWRlZCB0byBkbyB0
bw0KPiBoYW5kbGUgdGhlIGNhc2Ugd2hlbiB3ZSBvbmx5IGVuYWJsZSB0aGlzIGRyaXZlcjoNCkNv
dWxkIHlvdSBwb2ludCBtZSB0byB0aGUgTFRTSS0zLjE0IGJhY2twb3J0LCBvciBzZW5kIHBhdGNo
ZXM/DQoNCg0KPiAtLS0gMDAwMS9kcml2ZXJzL2RtYS9NYWtlZmlsZQ0KPiArKysgd29yay9kcml2
ZXJzL2RtYS9NYWtlZmlsZSAyMDE0LTEwLTI5IDEzOjE0OjI0LjAwMDAwMDAwMCArMDkwMA0KPiBA
QCAtMjAsNiArMjAsNyBAQCBvYmotJChDT05GSUdfQVRfSERNQUMpICs9IGF0X2hkbWFjLm8NCj4g
IG9iai0kKENPTkZJR19NWDNfSVBVKSArPSBpcHUvDQo+ICBvYmotJChDT05GSUdfVFhYOV9ETUFD
KSArPSB0eHg5ZG1hYy5vDQo+ICBvYmotJChDT05GSUdfU0hfRE1BRV9CQVNFKSArPSBzaC8NCj4g
K29iai0kKENPTkZJR19SQ0FSX0RNQUMpICs9IHNoLw0KPiAgb2JqLSQoQ09ORklHX0NPSDkwMTMx
OCkgKz0gY29oOTAxMzE4Lm8gY29oOTAxMzE4X2xsaS5vDQo+ICBvYmotJChDT05GSUdfQU1DQ19Q
UEM0NDBTUEVfQURNQSkgKz0gcHBjNHh4Lw0KPiAgb2JqLSQoQ09ORklHX0lNWF9TRE1BKSArPSBp
bXgtc2RtYS5vDQo+IA0KPiBOb3QgdGhlIHByZXR0aWVzdCBzb2x1dGlvbiwgYnV0IGF0IGxlYXN0
IGl0IG1ha2VzIHRoZSBjb2RlIGNvbXBpbGUNCj4gcmVnYXJkbGVzcyBvZiBTSF9ETUFFX0JBU0Uu
DQo+IENhbiB5b3UgcGxlYXNlIGNvbnNpZGVyIGZvbGRpbmcgdGhpcyBodW5rIGludG8gbmV4dCB2
ZXJzaW9uIG9mIHlvdXIgc2VyaWVzPw0KPiANCj4gVGhhbmtzLA0KPiANCj4gLyBtYWdudXMNCg0K
VGhhbmtzDQpQaGlsDQo

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Oct 29, 2014 at 10:49 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> I've performed quick SDHI performance tests yesterday. Read performance were
> around 7.5% lower with DMA support. Write performances varied but seemed
> similar on average.
>
> - PIO
>
> # time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
> 262144+0 records in
> 262144+0 records out

262144 records? Did it get split in 512 byte records?

> # time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
> 32+0 records in
> 32+0 records out

Only 32 records?

> - DMA
>
> # time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
> 32+0 records in
> 32+0 records out

Only 32 records?

> # time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
> 32768+0 records in
> 32768+0 records out

OK

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 v3 0/9] R-Car Gen2 DMA Controller driver

[Laurent Pinchart]

Hi Geert,

On Wednesday 29 October 2014 10:59:48 Geert Uytterhoeven wrote:
> On Wed, Oct 29, 2014 at 10:49 AM, Laurent Pinchart wrote:
> > I've performed quick SDHI performance tests yesterday. Read performance
> > were around 7.5% lower with DMA support. Write performances varied but
> > seemed similar on average.
> > 
> > - PIO
> > 
> > # time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
> > 262144+0 records in
> > 262144+0 records out
> 
> 262144 records? Did it get split in 512 byte records?

I knew I should have replaced the whole results instead of copying only the 
lines I thought had changed between tests :-) The times correspond to 32768 
blocks of 4kB despite what the number of records say.

> > # time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
> > 32+0 records in
> > 32+0 records out
> 
> Only 32 records?
> 
> > - DMA
> > 
> > # time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
> > 32+0 records in
> > 32+0 records out
> 
> Only 32 records?
> 
> > # time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
> > 32768+0 records in
> > 32768+0 records out
> 
> OK

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Laurent Pinchart]

Hi Magnus,

On Wednesday 29 October 2014 16:24:11 Magnus Damm wrote:
> On Mon, Oct 27, 2014 at 2:40 AM, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch sets adds a new driver for the DMA controller found in the
> > R-Car Gen2 SoCs under the name "Direct Memory Access Controller for System
> > (SYS-DMAC)". Support for the "Realtime Direct Memory Access Controller
> > (RT-DMAC)" and "Direct Memory Access Controller for Audio (Audio-DMAC)"
> > will be added later.
> > 
> > For the rationale of why a new driver is needed, and performance figures,
> > please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2 DMA Controller
> > driver") [1].
> > 
> > Support for hardware descriptors lists is not included in this series to
> > keep it simple and hopefully get it merged in v3.19. I'll post it as a
> > separate series. No change to the DT bindings will be needed.
> > 
> > The first three patches should go through the DMA engine tree, while the
> > last six patches should go through the Renesas tree. Simon, as the DT
> > bindings have been merged already, I believe you can queue up the arch
> > patches without waiting for the driver patches to be merged.
> > 
> > Known issues are
> > 
> > - Untested cyclic DMA transfers. I've done my best to fix the related
> >   issues from v2, but I haven't been able to test audio with the R-Car
> >   platforms (see [2]). Morimoto-san, if you could help me with audio
> >   testing I'd be grateful.
> >
> > - Stub system PM implementation. I'm working on this.
> > 
> > - Risk of conflict with Maxime's DMA engine rework series.
> > 
> > I believe the first two issues are not show stoppers. I can rebase the
> > patches if Maxime's patches get merged first.
> > 
> > Changes since v2:
> > 
> > - Replace several occurrences of size_t with unsigned int
> > - Remove unneeded local variable initialization
> > - Compute maximum transfer size at runtime
> > - Typo fixes
> > - Replace WARN_ON with WARN_ON_ONCE in interrupt handler
> > - Validate the number of channels
> > - Reset the device before enabling interrupts
> > - Use DMA_SLAVE_BUSWIDTH_* constants instead of numerical values
> > - Use devm_kasprintf
> > - Update to the new prep_dma_cyclic API
> > - Filter out channels from unrelated devices
> > - Fix typo in register definition
> > - Rename rcar_dmac_hw_desc to rcar_dmac_xfer_chunk
> > - Ignore the deprecated dma_slave_config direction field
> > - Allocate memory with GFP_NOWAIT in prep handlers
> > - Split runtime and system PM
> > - Move runtime PM to channel alloc/fre
> > 
> > Changes since v1:
> > 
> > - Allocate IRQ name strings dynamically
> > - Only call the callback function if one is supplied
> > - Don't overallocate sg list entries
> > - Allocate sg list entries with GFP_KERNEL
> > - Don't manage function clock manually
> > - Make channel filter ignore unrelated devices
> > - Document why the cyclic sg list is kcalloc'ed
> > - Remove ch15 from interrupt names in DT
> > - Replace CONFIG_OF with OF in Kconfig
> > 
> > [1] http://www.spinics.net/lists/linux-sh/msg33768.html
> > [2] http://www.spinics.net/lists/linux-sh/msg36474.html
> > 
> > Laurent Pinchart (9):
> >   dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
> >   dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
> >   dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
> >   
> >     driver
> >   
> >   ARM: shmobile: r8a7790: Rename mmcif node to mmc
> >   ARM: shmobile: r8a7791: Add MMCIF0 DT node
> >   ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
> >   ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
> >   ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
> >   ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes
> 
> Hi Laurent,
> 
> I've now tested this series briefly together with QSPI on Koelsch, and
> on top of that I've also done a prototype back port to LTSI-3.14. All
> seems well except this minor Kconfig adjustment that I needed to do to
> handle the case when we only enable this driver:
> 
> --- 0001/drivers/dma/Makefile
> +++ work/drivers/dma/Makefile 2014-10-29 13:14:24.000000000 +0900
> @@ -20,6 +20,7 @@ obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
>  obj-$(CONFIG_MX3_IPU) += ipu/
>  obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
>  obj-$(CONFIG_SH_DMAE_BASE) += sh/
> +obj-$(CONFIG_RCAR_DMAC) += sh/
>  obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
>  obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
>  obj-$(CONFIG_IMX_SDMA) += imx-sdma.o
> 
> Not the prettiest solution, but at least it makes the code compile
> regardless of SH_DMAE_BASE.
> Can you please consider folding this hunk into next version of your series?

How about this one instead ?

diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index cb626c179911..ebbcfdb8493a 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_MX3_IPU) += ipu/
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
-obj-$(CONFIG_SH_DMAE_BASE) += sh/
+obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_IMX_SDMA) += imx-sdma.o
diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
index 6b4d95377bc8..8190ad225a1b 100644
--- a/drivers/dma/sh/Kconfig
+++ b/drivers/dma/sh/Kconfig
@@ -2,6 +2,10 @@
 # DMA engine configuration for sh
 #
 
+config RENESAS_DMA
+	bool
+	select DMA_ENGINE
+
 #
 # DMA Engine Helpers
 #
@@ -12,7 +16,7 @@ config SH_DMAE_BASE
 	depends on !SUPERH || SH_DMA
 	depends on !SH_DMA_API
 	default y
-	select DMA_ENGINE
+	select RENESAS_DMA
 	help
 	  Enable support for the Renesas SuperH DMA controllers.
 
@@ -56,7 +60,7 @@ config RCAR_AUDMAC_PP
 config RCAR_DMAC
 	tristate "Renesas R-Car Gen2 DMA Controller"
 	depends on ARCH_SHMOBILE || COMPILE_TEST
-	select DMA_ENGINE
+	select RENESAS_DMA
 	help
 	  This driver supports the general purpose DMA controller found in the
 	  Renesas R-Car second generation SoCs.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Laurent Pinchart]

Hi Morimoto-san,

On Tuesday 28 October 2014 17:04:01 Kuninori Morimoto wrote:
> Hi Laurent, Simon
> 
> > > On Lager board + SDHI
> > > 
> > > Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > 
> > Thank you.
> > 
> > > Current SDHI driver + DMAC is working, but super slow,
> > > especially, write case....
> > 
> > *sigh* I'll test that.
> 
> Maybe this is SDHI side issue (?)
> Buswidth/clock/setting etc etc etc...
> No one used SDHI + DMA in DT and in R-Car Gen2 today.

I've performed my tests using a 2 bytes bus width. Using a 4 bytes bus width I 
get similar performances for PIO and DMA. 16 bytes and 32 bytes bus widths 
don't work out of the box, they would need more work.

> So, I guess it is very safety if we can ignore SDHI + DMA in upstream
> -> Simon ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Simon Horman]

On Wed, Oct 29, 2014 at 12:05:15PM +0200, Laurent Pinchart wrote:
> Hi Geert,
> 
> On Wednesday 29 October 2014 10:59:48 Geert Uytterhoeven wrote:
> > On Wed, Oct 29, 2014 at 10:49 AM, Laurent Pinchart wrote:
> > > I've performed quick SDHI performance tests yesterday. Read performance
> > > were around 7.5% lower with DMA support. Write performances varied but
> > > seemed similar on average.
> > > 
> > > - PIO
> > > 
> > > # time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
> > > 262144+0 records in
> > > 262144+0 records out
> > 
> > 262144 records? Did it get split in 512 byte records?
> 
> I knew I should have replaced the whole results instead of copying only the 
> lines I thought had changed between tests :-) The times correspond to 32768 
> blocks of 4kB despite what the number of records say.

As discussed elsewhere, I've dropped the following two patches for now,
pending further investigation of the problem.

ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes
ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes

> > > # time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
> > > 32+0 records in
> > > 32+0 records out
> > 
> > Only 32 records?
> > 
> > > - DMA
> > > 
> > > # time dd if=/dev/mmcblk1 of=/mnt/ram/mmc.bin count2768 bs@96
> > > 32+0 records in
> > > 32+0 records out
> > 
> > Only 32 records?
> > 
> > > # time dd of=/dev/mmcblk1 if=/mnt/ram/mmc.bin count2768 bs@96
> > > 32768+0 records in
> > > 32768+0 records out
> > 
> > OK
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]


> > --- 0001/drivers/dma/Makefile
> > +++ work/drivers/dma/Makefile 2014-10-29 13:14:24.000000000 +0900
> > @@ -20,6 +20,7 @@ obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
> >  obj-$(CONFIG_MX3_IPU) += ipu/
> >  obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
> >  obj-$(CONFIG_SH_DMAE_BASE) += sh/
> > +obj-$(CONFIG_RCAR_DMAC) += sh/
> >  obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
> >  obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
> >  obj-$(CONFIG_IMX_SDMA) += imx-sdma.o

I had a similar patch when doing I2C DMA development. However, I simply
used:
	obj-y += sh/

Since we are not compling anything by default.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 0/9] R-Car Gen2 DMA Controller driver

[Magnus Damm]

Hi Laurent,

On Wed, Oct 29, 2014 at 8:15 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Magnus,
>
> On Wednesday 29 October 2014 16:24:11 Magnus Damm wrote:
>> On Mon, Oct 27, 2014 at 2:40 AM, Laurent Pinchart wrote:
>> > Hello,
>> >
>> > This patch sets adds a new driver for the DMA controller found in the
>> > R-Car Gen2 SoCs under the name "Direct Memory Access Controller for System
>> > (SYS-DMAC)". Support for the "Realtime Direct Memory Access Controller
>> > (RT-DMAC)" and "Direct Memory Access Controller for Audio (Audio-DMAC)"
>> > will be added later.
>> >
>> > For the rationale of why a new driver is needed, and performance figures,
>> > please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2 DMA Controller
>> > driver") [1].
>> >
>> > Support for hardware descriptors lists is not included in this series to
>> > keep it simple and hopefully get it merged in v3.19. I'll post it as a
>> > separate series. No change to the DT bindings will be needed.
>> >
>> > The first three patches should go through the DMA engine tree, while the
>> > last six patches should go through the Renesas tree. Simon, as the DT
>> > bindings have been merged already, I believe you can queue up the arch
>> > patches without waiting for the driver patches to be merged.
>> >
>> > Known issues are
>> >
>> > - Untested cyclic DMA transfers. I've done my best to fix the related
>> >   issues from v2, but I haven't been able to test audio with the R-Car
>> >   platforms (see [2]). Morimoto-san, if you could help me with audio
>> >   testing I'd be grateful.
>> >
>> > - Stub system PM implementation. I'm working on this.
>> >
>> > - Risk of conflict with Maxime's DMA engine rework series.
>> >
>> > I believe the first two issues are not show stoppers. I can rebase the
>> > patches if Maxime's patches get merged first.
>> >
>> > Changes since v2:
>> >
>> > - Replace several occurrences of size_t with unsigned int
>> > - Remove unneeded local variable initialization
>> > - Compute maximum transfer size at runtime
>> > - Typo fixes
>> > - Replace WARN_ON with WARN_ON_ONCE in interrupt handler
>> > - Validate the number of channels
>> > - Reset the device before enabling interrupts
>> > - Use DMA_SLAVE_BUSWIDTH_* constants instead of numerical values
>> > - Use devm_kasprintf
>> > - Update to the new prep_dma_cyclic API
>> > - Filter out channels from unrelated devices
>> > - Fix typo in register definition
>> > - Rename rcar_dmac_hw_desc to rcar_dmac_xfer_chunk
>> > - Ignore the deprecated dma_slave_config direction field
>> > - Allocate memory with GFP_NOWAIT in prep handlers
>> > - Split runtime and system PM
>> > - Move runtime PM to channel alloc/fre
>> >
>> > Changes since v1:
>> >
>> > - Allocate IRQ name strings dynamically
>> > - Only call the callback function if one is supplied
>> > - Don't overallocate sg list entries
>> > - Allocate sg list entries with GFP_KERNEL
>> > - Don't manage function clock manually
>> > - Make channel filter ignore unrelated devices
>> > - Document why the cyclic sg list is kcalloc'ed
>> > - Remove ch15 from interrupt names in DT
>> > - Replace CONFIG_OF with OF in Kconfig
>> >
>> > [1] http://www.spinics.net/lists/linux-sh/msg33768.html
>> > [2] http://www.spinics.net/lists/linux-sh/msg36474.html
>> >
>> > Laurent Pinchart (9):
>> >   dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths
>> >   dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings
>> >   dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
>> >
>> >     driver
>> >
>> >   ARM: shmobile: r8a7790: Rename mmcif node to mmc
>> >   ARM: shmobile: r8a7791: Add MMCIF0 DT node
>> >   ARM: shmobile: r8a7790: Reference DMA channels in MMCIF DT nodes
>> >   ARM: shmobile: r8a7791: Reference DMA channels in MMCIF DT node
>> >   ARM: shmobile: r8a7790: Reference DMA channels in SDHI DT nodes
>> >   ARM: shmobile: r8a7791: Reference DMA channels in SDHI DT nodes
>>
>> Hi Laurent,
>>
>> I've now tested this series briefly together with QSPI on Koelsch, and
>> on top of that I've also done a prototype back port to LTSI-3.14. All
>> seems well except this minor Kconfig adjustment that I needed to do to
>> handle the case when we only enable this driver:
>>
>> --- 0001/drivers/dma/Makefile
>> +++ work/drivers/dma/Makefile 2014-10-29 13:14:24.000000000 +0900
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
>>  obj-$(CONFIG_MX3_IPU) += ipu/
>>  obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
>>  obj-$(CONFIG_SH_DMAE_BASE) += sh/
>> +obj-$(CONFIG_RCAR_DMAC) += sh/
>>  obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
>>  obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
>>  obj-$(CONFIG_IMX_SDMA) += imx-sdma.o
>>
>> Not the prettiest solution, but at least it makes the code compile
>> regardless of SH_DMAE_BASE.
>> Can you please consider folding this hunk into next version of your series?
>
> How about this one instead ?
>
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index cb626c179911..ebbcfdb8493a 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -18,7 +18,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/
>  obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
>  obj-$(CONFIG_MX3_IPU) += ipu/
>  obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
> -obj-$(CONFIG_SH_DMAE_BASE) += sh/
> +obj-$(CONFIG_RENESAS_DMA) += sh/
>  obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
>  obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
>  obj-$(CONFIG_IMX_SDMA) += imx-sdma.o
> diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
> index 6b4d95377bc8..8190ad225a1b 100644
> --- a/drivers/dma/sh/Kconfig
> +++ b/drivers/dma/sh/Kconfig
> @@ -2,6 +2,10 @@
>  # DMA engine configuration for sh
>  #
>
> +config RENESAS_DMA
> +       bool
> +       select DMA_ENGINE
> +
>  #
>  # DMA Engine Helpers
>  #
> @@ -12,7 +16,7 @@ config SH_DMAE_BASE
>         depends on !SUPERH || SH_DMA
>         depends on !SH_DMA_API
>         default y
> -       select DMA_ENGINE
> +       select RENESAS_DMA
>         help
>           Enable support for the Renesas SuperH DMA controllers.
>
> @@ -56,7 +60,7 @@ config RCAR_AUDMAC_PP
>  config RCAR_DMAC
>         tristate "Renesas R-Car Gen2 DMA Controller"
>         depends on ARCH_SHMOBILE || COMPILE_TEST
> -       select DMA_ENGINE
> +       select RENESAS_DMA
>         help
>           This driver supports the general purpose DMA controller found in the
>           Renesas R-Car second generation SoCs.
>

Thanks for this, it of course looks good to me. Acutally I'm fine with
more or less anything as long as we can successfully build each driver
independently. I saw that Wolfram also had a simpler approach which I
don't mind. Please pick by yourself!

Thanks,

/ magnus