From: Hein Tibosch <hein_tibosch@yahoo.es>
To: viresh kumar <viresh.kumar@linaro.org>
Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
Havard Skinnemoen <havard@skinnemoen.net>,
"ludovic.desroches" <ludovic.desroches@atmel.com>,
linux-kernel@vger.kernel.org,
spear-devel <spear-devel@list.st.com>
Subject: Re: [PATCH] Fixes for dw_dmac and atmel-mci for AP700x
Date: Tue, 21 Aug 2012 14:12:30 +0800 [thread overview]
Message-ID: <503326CE.40301@yahoo.es> (raw)
In-Reply-To: <CAOh2x=kOxninn=o1i2-HE1is-G8vfi1ER_JjUQY=N0wTYwAotw@mail.gmail.com>
Hi Viresh,
On 8/21/2012 12:42 PM, viresh kumar wrote:
> I have added linux-kernel list in cc as there might be other users of
> this patch.
> Also, please try to keep spear-devel list in cc for dw_dmac as we are using this
> driver for SPEAr.
Yes sure, I didn't want to bother the lists with the first preparations of this patch.
> On Sun, Aug 19, 2012 at 9:36 PM, Hein Tibosch <hein_tibosch@yahoo.es> wrote:
>> dw_dmac:
>> - After 2.6.39, the registers were accessed using readl/writel
>> in stead of the __raw_readl and __raw_writel causing a 16-bit
>> swap of all values (little endian access)
> Ahhhh!! Firstly we can't use __raw* for architectures >= ARMv6. It is not
> only for endianess but for memory barriers. Why are they getting swapped
> for your case? Does your processor and dw_dmac have different endianess?
If I'm not wrong: the __raw_* functions will access the i/o memory in native endianess.
As far as I know, all AVR32 drivers are currently using the __raw* functions. I never
encountered a problem with that.
> And if i am not wrong, we should always try not to use __raw* variants just
> due to endianess things... instead use either readl/writel OR
> readl_/writel_ relaxed.
> I am not sure if relaxed versions are available for architectures
> other than ARM.
Would you agree to have this depend on CONFIG_AVR ?
>> - Access to memory was sometimes done in chunks of 64-bits,
>> which gives an undefined value of 0x03 for SRC/DST_TR_WIDTH
>> field in the CTLxL register
> Looks fine. But there should be a separate patch for this.
>
>> - The SMS field in the CTLxL register received the wrong value:
>> 0 in stead of 1
> I believe it is not for dw_dmac?
That's correct, I'll put it in a separate Atmel patch (at32ap700x.c)
So for the AP700x fixes for the MCI/DMA driver I'm thinking of this
series of patches:
To you, cc spear-devel & linux-kernel
- include/linux/dw_dmac.h:
adding field max_mem_width to limit SRC/DST_TR_WIDTH
- dw_dmac.c:
check max_mem_width before setting SRC/DST_TR_WIDTH
- dw_dmac_regs.h:
use __raw* functions for AVR32, readl/writel for all others
To Ludovic Desroches, linux-mmc:
- atmel-mci.c:
avoid using peripheral DMA controller (PDC) in case of AVR32
- atmel-mci.c:
only use the ATMCI_DMA register if supported by arch
To Hans-Christian, linux-kernel cc Andrew:
- at32ap700x.c:
set src_master=1 to get SMS (Source Master Select) correct
set max_mem_width=2 to get SRC/DST_TR_WIDTH correct
Ok?
Thanks, Hein
next prev parent reply other threads:[~2012-08-21 6:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <502BC31E.4070200@yahoo.es>
[not found] ` <502BDD0E.4030106@yahoo.es>
[not found] ` <502CA8FC.7090705@atmel.com>
[not found] ` <502CB89B.4070302@yahoo.es>
[not found] ` <502CC326.8020605@atmel.com>
[not found] ` <502CC6A0.3050603@atmel.com>
[not found] ` <502F52E7.9050804@yahoo.es>
[not found] ` <CACiLriS-GZg24TJqJGQ=P04n-Zk3FdHtGgh5VeqGcCMHG6TnMw@mail.gmail.com>
[not found] ` <50310F10.2080701@yahoo.es>
2012-08-21 4:42 ` [PATCH] Fixes for dw_dmac and atmel-mci for AP700x viresh kumar
2012-08-21 6:12 ` Hein Tibosch [this message]
[not found] ` <CAKohponN16krs-WWw6Abh1fLPO3+iYndTaxsPDfeXCoS9OHufQ@mail.gmail.com>
2012-08-21 7:32 ` Hein Tibosch
[not found] ` <CAKohpomMPeewDBVxVR=g-op7E53rqt-AZgOdyoib6W+5QsLOOA@mail.gmail.com>
2012-08-21 8:34 ` Arnd Bergmann
[not found] ` <CAKohpokhM5WkUK6ww8Neu+fx554+-4uBCsNzBxB9q5rcqSf6cw@mail.gmail.com>
2012-08-21 8:47 ` Arnd Bergmann
[not found] ` <CAKohpokoeSLBtLdh8hr4GKv8VOxzK8Vq5SoqLE3yC-TDyjYA9w@mail.gmail.com>
2012-08-21 9:05 ` Arnd Bergmann
2012-08-21 14:24 ` Hein Tibosch
2012-08-21 7:44 ` Arnd Bergmann
[not found] ` <CAKohpo=DyQajiE-DmpMiv=gVOVOep1OEECVuw83D2u4VJisEsw@mail.gmail.com>
2012-08-21 8:31 ` Arnd Bergmann
2012-08-21 14:15 ` Havard Skinnemoen
2012-08-23 3:47 ` Hein Tibosch
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=503326CE.40301@yahoo.es \
--to=hein_tibosch@yahoo.es \
--cc=hans-christian.egtvedt@atmel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox