On Monday, April 4, 2005 7:25 am, James Bottomley wrote:
> On Mon, 2005-04-04 at 15:16 +0100, Christoph Hellwig wrote:
> > The IOC4 device that provides IDE, serial ports and external interrupts
> > on Altix systems has a big endian register layour, and the PCI-X bridge
> > in those Altix systems c
On Tue, 5 Apr 2005, Russell King wrote:
> > > physical bus: 31...24 23...16 15...8 7...0
> > >
> > > BE version 1 (word invariant)
> > > byte access byte 0 byte 1 byte 2 byte 3
> > > word access 31-24 23-16 15-87-0
> > >
> > > BE version 2 (byte invariant)
> > > byt
On Tue, Apr 05, 2005 at 09:05:15AM -0500, James Bottomley wrote:
> On Tue, 2005-04-05 at 08:42 +0100, Russell King wrote:
> > Not so. There are two different styles of big endian. (Lets just face
> > it, BE is fucked in the head anyway...)
> >
> > physical bus: 31...24 23...16 15...8 7...
On Tue, 2005-04-05 at 08:42 +0100, Russell King wrote:
> Not so. There are two different styles of big endian. (Lets just face
> it, BE is fucked in the head anyway...)
>
> physical bus: 31...24 23...16 15...8 7...0
>
> BE version 1 (word invariant)
> byte access byte 0 byte 1 byte 2 byte
On Tue, 2005-04-05 at 08:21 +0100, Christoph Hellwig wrote:
> What I really don't like is that you still need ifdefs and wrappers to
> support BE and LE wired chips in the same driver. Shouldn't you set the
> BE or LE flag at iomap() time and always use the same accessors?
No, if you look how it
On Sat, Apr 02, 2005 at 09:40:39PM -0600, James Bottomley wrote:
> On Sun, 2005-04-03 at 04:10 +0100, Matthew Wilcox wrote:
> > > SPARC64 can do it in the PTEs, but we just use raw physical
> > > addresses in our I/O accessors, and in those load/store instructions
> > > we can specify the endiannes
On Mon, Apr 04, 2005 at 04:17:45PM -0500, James Bottomley wrote:
> OK, I sent the patch off to Andrew. To complete the original problem,
> the attached is the patch that uses it in the parisc lasi driver
> (although, actually, it sets up 53c700 to work everywhere including BE
> on a LE system).
>
On Mon, 2005-04-04 at 08:59 -0500, James Bottomley wrote:
> On Mon, 2005-04-04 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> > I disagree. The driver will never "know" ...
>
> ? the driver has to know. Look at the 53c700 to see exactly how awful
> it is. This beast has byte and word registers.
> > Well ... it's like this. Native means "pass through without swapping"
> > and has an easy implementation on both BE and LE platforms. Logically
> > io{read,write}{16,32}be would have to do byte swaps on LE platforms.
> > Being lazy, I'm opposed to doing the work if there's no actual use for
>
OK, I sent the patch off to Andrew. To complete the original problem,
the attached is the patch that uses it in the parisc lasi driver
(although, actually, it sets up 53c700 to work everywhere including BE
on a LE system).
I changed some of the flags around to reflect the fact that we now have
ge
On Mon, 2005-04-04 at 15:16 +0100, Christoph Hellwig wrote:
> The IOC4 device that provides IDE, serial ports and external interrupts
> on Altix systems has a big endian register layour, and the PCI-X bridge
> in those Altix systems can do the swapping if a special bit is set.
>
> In older kernels
James Bottomley wrote:
On Mon, 2005-04-04 at 17:50 +1000, Benjamin Herrenschmidt wrote:
I disagree. The driver will never "know" ...
? the driver has to know. Look at the 53c700 to see exactly how awful
it is. This beast has byte and word registers. When used BE, all the
byte registers alter th
On Mon, Apr 04, 2005 at 08:59:03AM -0500, James Bottomley wrote:
> Well ... it's like this. Native means "pass through without swapping"
> and has an easy implementation on both BE and LE platforms. Logically
> io{read,write}{16,32}be would have to do byte swaps on LE platforms.
> Being lazy, I'm
On Mon, 2005-04-04 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> I disagree. The driver will never "know" ...
? the driver has to know. Look at the 53c700 to see exactly how awful
it is. This beast has byte and word registers. When used BE, all the
byte registers alter their position (to both
On Sat, 2005-04-02 at 22:27 -0600, James Bottomley wrote:
> On Sat, 2005-04-02 at 20:08 -0800, David S. Miller wrote:
> > > Did anyone have a preference for the API? I was thinking
> > > ioread32_native, but ioread32be is fine too.
> >
> > I think doing foo{be,le}{8,16,32}() would be consistent w
On Sat, 2005-04-02 at 21:40 -0600, James Bottomley wrote:
> Actually, ioread8be is unnecessary, but I was planning to add
> ioread16/ioread32 and iowritexx be on be variants (equivalent to
> _raw_readw et al.)
>
> After all, the driver must know the card is BE, so the routines that
> make use of
On Sat, 2005-04-02 at 20:08 -0800, David S. Miller wrote:
> > Did anyone have a preference for the API? I was thinking
> > ioread32_native, but ioread32be is fine too.
>
> I think doing foo{be,le}{8,16,32}() would be consistent with
> our byteorder.h interface names.
Thinking about this some mor
On Sat, 02 Apr 2005 21:40:39 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
> After all, the driver must know the card is BE, so the routines that
> make use of the feature are easily coded into the card, so there's no
> real need to add it to the iomem cookie.
Yes, I don't believe it needs to
On Sun, 2005-04-03 at 04:10 +0100, Matthew Wilcox wrote:
> > SPARC64 can do it in the PTEs, but we just use raw physical
> > addresses in our I/O accessors, and in those load/store instructions
> > we can specify the endianness.
>
> Ah right. So you'd prefer an ioread8be() interface?
Actually, i
On Sat, Apr 02, 2005 at 06:38:05PM -0800, David S. Miller wrote:
> > My thought on this is that we should encode the endianness of the
> > registers in the ioremap cookie. Some architectures (sparc, I think?) can
> > do this in their PTEs. The rest of us can do it in our ioread/writeN
> > methods
On Sun, 3 Apr 2005 02:37:57 +0100
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> My thought on this is that we should encode the endianness of the
> registers in the ioremap cookie. Some architectures (sparc, I think?) can
> do this in their PTEs. The rest of us can do it in our ioread/writeN
> met
On Sat, Apr 02, 2005 at 02:52:14PM -0600, James Bottomley wrote:
> This driver has had it's own different infrastructure for doing this for
> ages, but it's time it used the common one.
Thanks. I'd been looking at this for a while but hadn't got round tuit yet.
> #ifdef CONFIG_53C700_LE_ON_BE
>
22 matches
Mail list logo
