[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1360271904.2650.40.camel@pasglop>
Date: Fri, 08 Feb 2013 08:18:24 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Alexey Brodkin <Alexey.Brodkin@...opsys.com>
Cc: Grant Likely <grant.likely@...retlab.ca>,
Michal Simek <monstr@...str.eu>, Arnd Bergmann <arnd@...db.de>,
Vineet Gupta <Vineet.Gupta1@...opsys.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
dahinds@...rs.sourceforge.net
Subject: Re: [PATCH] drivers/block/xsysace - replace
in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)
On Thu, 2013-02-07 at 20:56 +0400, Alexey Brodkin wrote:
> > So, if I'm correct that means that for the data port (specifically
> > copying between RAM and the data port) using ioread16/iowrite16 on the
> > data port results in the correct behaviour. It also means that LE
> > support in the current driver is broken.
>
> That matches my earlier note when I wrote that for correct work on LE
> (note I'm on ARC, not PPC/MB) I needed to use "io{read|write}16" in
> "ace_data{in|out}_le16".
>
> With original "io{read|write}16be" instead data was corrupted.
For the "backward wiring case" your data port will always be the opposite
endian as your host. For the "correct wiring" case, the data port will always
be the same endian as your host.
So the correct wiring case (the one using ioread16/iowrite16 for registers),
the data port should just use ioread16_rep.
For the other case, you need some ifdef'ery or raw variants with home made
barriers, or a bounce buffer.
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists