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 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.