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
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 can do
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)
> > >
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
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
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
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 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...0
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)
byte access byte 3
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).
I
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 endianness.
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 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 3
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
> > 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
On Mon, 04 Apr 2005 13:57:59 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-04-04 at 16:41 +0100, David Vrabel wrote:
> > The Network Processing Engines in the Intel IXP425 are big-endian and
> > its XScale core may be run in little-endian mode. There's a bunch of
> > gotchas
On Mon, 2005-04-04 at 16:41 +0100, David Vrabel wrote:
> The Network Processing Engines in the Intel IXP425 are big-endian and
> its XScale core may be run in little-endian mode. There's a bunch of
> gotchas related to running in little-endian mode so you typically run
> the IXP425 in big-endian
Richard B. Johnson wrote:
>
> But the Linux interface (on the CPU side of the PCI bus interface)
> doesn't care about the implimentation details in the XScale
> Core. That's why it's a complete subsystem, isolated from the
> ix86 by the PCI/Bus interface.
Hmmm.
*takes a long hard look at the
On Mon, 4 Apr 2005, David Vrabel wrote:
James Bottomley wrote:
so can you provide an example of a BE bus (or device) used on a LE
platform that would actually benefit from this abstraction?
The Network Processing Engines in the Intel IXP425 are big-endian and
its XScale core may be run in
James Bottomley wrote:
> so can you provide an example of a BE bus (or device) used on a LE
> platform that would actually benefit from this abstraction?
The Network Processing Engines in the Intel IXP425 are big-endian and
its XScale core may be run in little-endian mode. There's a bunch of
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
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
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
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
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 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 the
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 with
our
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 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
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
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:
so can you provide an example of a BE bus (or device) used on a LE
platform that would actually benefit from this abstraction?
The Network Processing Engines in the Intel IXP425 are big-endian and
its XScale core may be run in little-endian mode. There's a bunch of
On Mon, 4 Apr 2005, David Vrabel wrote:
James Bottomley wrote:
so can you provide an example of a BE bus (or device) used on a LE
platform that would actually benefit from this abstraction?
The Network Processing Engines in the Intel IXP425 are big-endian and
its XScale core may be run in
Richard B. Johnson wrote:
But the Linux interface (on the CPU side of the PCI bus interface)
doesn't care about the implimentation details in the XScale
Core. That's why it's a complete subsystem, isolated from the
ix86 by the PCI/Bus interface.
Hmmm.
*takes a long hard look at the IXP425
On Mon, 2005-04-04 at 16:41 +0100, David Vrabel wrote:
The Network Processing Engines in the Intel IXP425 are big-endian and
its XScale core may be run in little-endian mode. There's a bunch of
gotchas related to running in little-endian mode so you typically run
the IXP425 in big-endian mode,
On Mon, 04 Apr 2005 13:57:59 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Mon, 2005-04-04 at 16:41 +0100, David Vrabel wrote:
The Network Processing Engines in the Intel IXP425 are big-endian and
its XScale core may be run in little-endian mode. There's a bunch of
gotchas related to
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
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
it, so
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. When
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
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,
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
> >
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
>
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
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
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
methods.
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. I've
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,
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 be
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 more, I
54 matches
Mail list logo
