Messages in this thread | | | Date | Mon, 27 Aug 2012 22:58:46 +0800 | From | Hein Tibosch <> | Subject | Re: [PATCH 1/2] dw_dmac: make driver endianness configurable |
| |
On 8/27/2012 7:14 PM, Hans-Christian Egtvedt wrote: > Around Mon 27 Aug 2012 16:47:40 +0800 or thereabout, Hein Tibosch wrote: >> On 8/27/2012 3:03 PM, Hans-Christian Egtvedt wrote: >>> Brushing up the config items: >>> >>> +config DW_DMAC_BIG_ENDIAN_IO >>> + bool "Use big endian I/O register access" >>> + default y if AVR32 >>> + depends on DW_DMAC >>> + help >>> + Say yes here to use big endian I/O access when reading and writing >>> + to the DMA controller registers. This is needed on some platforms, >>> + like the Atmel AVR32 architecture. >>> + >>> + If unsure, use the default setting. > This sounds good in my ears, but I don't speak English natively. I think you Norwegians are doing very well in English And btw, I'm not from .es but from .nl, which is very close to England
>> And as I'd like to define the maximum memory transfer width in the same >> Kconfig: >> >> +config DW_DMAC_MEM_64_BIT >> + bool "Allow 64-bit memory transfers" >> + default y if !AVR32 >> + depends on DW_DMAC >> + help >> + Say yes if the DMA controller may do 64-bit memory transfers >> + For AVR32, say no because only up to 32-bit transfers are >> + defined > Is this sane to add? Could some non-AVR32 platforms use 64-bit and 32-bit > depending on runtime configuration? E.g. if you build a kernel with support > for multiple boards/processors, and there is a mix of 32-bit and 64-bit wide > DMA support. > > I think it is better to select 32/64-bit at runtime.
I did that in the first patch, adding a new property to the dw_dma_slave structure. It had the small disadvantage that some arch code had to be adapted (at32ap700x.c).
Viresh, what do you think? Add a property called "mem_64_bit_access" or so?
Or should it be passed as a member of 'dw_dma_platform_data', because it is a property of the (entire) DMA controller?
Hein
| |