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>,
Arnd Bergmann <arnd.bergmann@linaro.org>
Subject: Re: [PATCH] Fixes for dw_dmac and atmel-mci for AP700x
Date: Tue, 21 Aug 2012 15:32:18 +0800 [thread overview]
Message-ID: <50333982.3020201@yahoo.es> (raw)
In-Reply-To: <CAKohponN16krs-WWw6Abh1fLPO3+iYndTaxsPDfeXCoS9OHufQ@mail.gmail.com>
On 8/21/2012 2:35 PM, Viresh Kumar wrote:
> On 21 August 2012 11:42, Hein Tibosch <hein_tibosch@yahoo.es <mailto:hein_tibosch@yahoo.es>> wrote:
>
> On 8/21/2012 12:42 PM, viresh kumar wrote:
> > 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.
>
>
> I don't have the best knowledge in this area :( and so cc-ing Arnd who can help us here.
> So my perception of these routines is:
>
> readl is defined generically as:
>
> #define readl(addr) __le32_to_cpu(__raw_readl(addr))
>
> Which converts to a simple __raw_readl() for little endian systems and
> swapped bytes for a big endian system.
>
> You wrote in the beginning
> >> - 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)
It got swapped as 0xAABB.CCDD => 0xCCDD.AABB
> What's this 16-bit swap here? It should be a 8 bit swap by __swab32() routine.
>
> Is AVR32 a big-endian system? Probably big-endian, that's why values are getting
> swapped. And dw_dmac is the standard one, can call it little endian for the time being.
>
AVR32 (AP700x) is a big-endian system.
It took me many hours to figure out why the DMA controller didn't do
anything at all.
Then I decided to access the i/o memory in different way:
#include "dmaca_206a.h" // from the AVR32-tools library
const struct __iomem avr32_dmaca_t *regs =
(const struct __iomem avr32_dmaca_t *)0xFF200000;
and printk all register values. Each and every u32 field was swapped as
0xAABBCCDD => 0xCCDDAABB
Håvard's comment was: "it's always wrong to use little endian accessors
(i.e. readl/writel) in drivers for chip-internal devices"
Memory barriers: within the AVR32 code, one often sees explicit ways to
introduce memory barriers, e.g.:
hsmc_readl(hsmc, MODE0); /* I/O barrier */
which means: reading back (just any) register (from the same peripheral)
to assure that the write was successful, especially from within
interrupt handlers.
But as I said, within avr32-linux I never encountered problems
with the __raw* approach, including dw_dmac.c
> @Arnd: What should we do here?
I'm curious too
Hein
next prev parent reply other threads:[~2012-08-21 7:33 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
[not found] ` <CAKohponN16krs-WWw6Abh1fLPO3+iYndTaxsPDfeXCoS9OHufQ@mail.gmail.com>
2012-08-21 7:32 ` Hein Tibosch [this message]
[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=50333982.3020201@yahoo.es \
--to=hein_tibosch@yahoo.es \
--cc=arnd.bergmann@linaro.org \
--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;
as well as URLs for NNTP newsgroup(s).