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(-)
--
On 30 August 2012 22:44, Hein Tibosch <[email protected]> wrote:
> 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
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
On 31 August 2012 10:45, Hein Tibosch <[email protected]> wrote:
> On 8/31/2012 12:26 PM, Viresh Kumar wrote:
>> 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.
Perfect !!
On 8/31/2012 12:26 PM, Viresh Kumar wrote:
> 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