dw_dmac: repair driver for use with AVR32 (AP7000)

PATCH Superseded Hein Tibosch 2 participants 4 messages Aug 30, 2012 – Aug 31, 2012

lore

Share & tools

lore

Hein Tibosch

author

2012-08-30 18:34 UTC #0 lore raw

v2 cover dw_dmac: repair driver for use with AVR32 (AP7000)

After some recent changes to dw_dmac, the driver got broken for the AVR32 platform for two reasons:

The accessors to i/o memory had become little-endian. The maximum transfer width on the memory side was increased from 32 to 64 bits. This led to undefined behavior on the avr32 platform.

These patches repair the driver by:
1. making the endianness configurable through Kconfig, for AVR32 it will become big-endian
2. making the maximum memory transfer width configurable It can be set in the code within arch

For non-avr32 (ARM) platforms, nothing has to be changed.

Thanks to all for reviewing

Hein Tibosch (2):

 drivers/dma/Kconfig        |   11 +++++++++++
 drivers/dma/dw_dmac.c      |   10 +++++++---
 drivers/dma/dw_dmac_regs.h |   14 ++++++++++++++
 include/linux/dw_dmac.h    |    3 +++
 4 files changed, 35 insertions(+), 3 deletions(-)

Viresh Kumar

Acked-by on the v2 series

2012-08-31 04:26 UTC #1 lore raw

Quoted 8 lines · Hein Tibosch

After some recent changes to dw_dmac, the driver got broken for the AVR32 platform for two reasons:
The accessors to i/o memory had become little-endian. The maximum transfer width on the memory side was increased from 32 to 64 bits. This led to undefined behavior on the avr32 platform.

Quoted 5 lines

These patches repair the driver by:
1. making the endianness configurable through Kconfig, for AVR32 it will become big-endian
2. making the maximum memory transfer width configurable It can be set in the code within arch

Acked-by Viresh Kumar <[email protected]>

BTW, Ideally speaking the fix for AVR32 which will enable 32bit mem support and enable BIG endian support should have been part of this patchset. That code can go through DMA tree as these patches are very closely related. Otherwise now you have to wait till these patches are included in linux-next, then only you can send AVR32 patches for inclusion.

So, maybe you can just add Acked-by from me and Arnd and include AVR patches (Only changes related to these two patches) in the same series. That will make life easier for you.

viresh

Hein Tibosch

author

2012-08-31 06:24 UTC #2 lore raw

Quoted 10 lines · Viresh Kumar

BTW, Ideally speaking the fix for AVR32 which will enable 32bit mem support and enable BIG endian support should have been part of this patchset. That code can go through DMA tree as these patches are very closely related. Otherwise now you have to wait till these patches are included in linux-next, then only you can send AVR32 patches for inclusion.
So, maybe you can just add Acked-by from me and Arnd and include AVR patches (Only changes related to these two patches) in the same series. That will make life easier for you.

Good idea, I already wondered how these 5 patches can be kept together:

1 [PATCH v2 1/2] dw_dmac: make driver endianness configurable
2 [PATCH v2 2/2] dw_dmac: max_mem_width limits value for SRC/DST_TR_WID register 3 [PATCH v2] avr32: at32ap700x: set DMA slave properties for MCI dw_dmac 4 [PATCH v2 1/2] mmc: atmel-mci: DMA can be used with other controller 5 [PATCH v2 2/2] mmc: atmel-mci: AP700x PDC is not connected to MCI

Patch 3 will only compile after patch 2 has been applied.

Patch 4 and 5 will compile but they will only result in a working mci+dma after patches 1, 2 and 3 have been applied.

I'm a mere developer, not a MAINTAINER. But sure it would be good to keep these together as much as possible. It would also be easier for fellow avr32/mci users who want to upgrade to 3.5.2 without problems.

So I assume that you want patches 1 to 3, packed as [PATCH v3 3/3] ?

The atmel-mci patches will be handled by Ludovic Desroches.

Thanks, Hein

Viresh Kumar

2012-08-31 05:44 UTC #3 lore raw

Quoted 25 lines · Hein Tibosch

Quoted 10 lines · Viresh Kumar
BTW, Ideally speaking the fix for AVR32 which will enable 32bit mem support and enable BIG endian support should have been part of this patchset. That code can go through DMA tree as these patches are very closely related. Otherwise now you have to wait till these patches are included in linux-next, then only you can send AVR32 patches for inclusion.
So, maybe you can just add Acked-by from me and Arnd and include AVR patches (Only changes related to these two patches) in the same series. That will make life easier for you.
Good idea, I already wondered how these 5 patches can be kept together:
1 [PATCH v2 1/2] dw_dmac: make driver endianness configurable
2 [PATCH v2 2/2] dw_dmac: max_mem_width limits value for SRC/DST_TR_WID register 3 [PATCH v2] avr32: at32ap700x: set DMA slave properties for MCI dw_dmac 4 [PATCH v2 1/2] mmc: atmel-mci: DMA can be used with other controller 5 [PATCH v2 2/2] mmc: atmel-mci: AP700x PDC is not connected to MCI
Patch 3 will only compile after patch 2 has been applied.
Patch 4 and 5 will compile but they will only result in a working mci+dma after patches 1, 2 and 3 have been applied.

Quoted 7 lines

I'm a mere developer, not a MAINTAINER. But sure it would be good to keep these together as much as possible. It would also be easier for fellow avr32/mci users who want to upgrade to 3.5.2 without problems.
So I assume that you want patches 1 to 3, packed as [PATCH v3 3/3] ?
The atmel-mci patches will be handled by Ludovic Desroches.

Perfect !!