All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hein Tibosch <hein_tibosch@yahoo.es>
To: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: viresh kumar <viresh.kumar@linaro.org>,
	spear-devel <spear-devel@list.st.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"ludovic.desroches" <ludovic.desroches@atmel.com>,
	Havard Skinnemoen <havard@skinnemoen.net>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd.bergmann@linaro.org>
Subject: Re: [PATCH 1/2] dw_dmac: make driver endianness configurable
Date: Mon, 27 Aug 2012 22:58:46 +0800	[thread overview]
Message-ID: <503B8B26.3050205@yahoo.es> (raw)
In-Reply-To: <20120827111431.GA27868@samfundet.no>

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

  reply	other threads:[~2012-08-27 15:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-26 20:53 [PATCH 1/2] dw_dmac: make driver endianness configurable Hein Tibosch
2012-08-27  7:03 ` Hans-Christian Egtvedt
2012-08-27  8:47   ` Hein Tibosch
2012-08-27 11:14     ` Hans-Christian Egtvedt
2012-08-27 14:58       ` Hein Tibosch [this message]
2012-08-28  3:23         ` Viresh Kumar
2012-08-28  6:55           ` Hein Tibosch
2012-08-28  7:05             ` Viresh Kumar
2012-08-28  7:39             ` Felipe Balbi
2012-09-03  7:50               ` Andy Shevchenko
2012-09-03 14:16                 ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=503B8B26.3050205@yahoo.es \
    --to=hein_tibosch@yahoo.es \
    --cc=akpm@linux-foundation.org \
    --cc=arnd.bergmann@linaro.org \
    --cc=egtvedt@samfundet.no \
    --cc=havard@skinnemoen.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludovic.desroches@atmel.com \
    --cc=nicolas.ferre@atmel.com \
    --cc=spear-devel@list.st.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.