Geert Uytterhoeven <[email protected]> wrote:
> On Fri, 30 May 2008, Haavard Skinnemoen wrote:
> > Maybe we need another interface that does not do byteswapping but
> > provides stronger ordering guarantees?
>
> The byte swapping depends on the device/bus.
Of course. But isn't it reasonable to assume that a device integrated
on the same silicon as the CPU is connected to a somewhat sane bus
which doesn't require any byte swapping?
> So what happened to the old idea of putting the accessor function pointers
> in the device/bus structure?
Don't know. I think it sounds like overkill to replace a simple load or
store with an indirect function call.
Haavard
On Mon, Jun 02, 2008 at 10:11:02AM +0200, Haavard Skinnemoen wrote:
> Geert Uytterhoeven <[email protected]> wrote:
> > On Fri, 30 May 2008, Haavard Skinnemoen wrote:
> > > Maybe we need another interface that does not do byteswapping but
> > > provides stronger ordering guarantees?
> >
> > The byte swapping depends on the device/bus.
>
> Of course. But isn't it reasonable to assume that a device integrated
> on the same silicon as the CPU is connected to a somewhat sane bus
> which doesn't require any byte swapping?
No, unfortunately. :-(
See the end of drivers/dma/fsldma.h. Likewise with Freescale's PCI host
bridges; for some reason the bus itself being little endian led to the host
bridge control registers also being little endian.
-Scott
Scott Wood <[email protected]> wrote:
> On Mon, Jun 02, 2008 at 10:11:02AM +0200, Haavard Skinnemoen wrote:
> > Geert Uytterhoeven <[email protected]> wrote:
> > > On Fri, 30 May 2008, Haavard Skinnemoen wrote:
> > > > Maybe we need another interface that does not do byteswapping but
> > > > provides stronger ordering guarantees?
> > >
> > > The byte swapping depends on the device/bus.
> >
> > Of course. But isn't it reasonable to assume that a device integrated
> > on the same silicon as the CPU is connected to a somewhat sane bus
> > which doesn't require any byte swapping?
>
> No, unfortunately. :-(
Ok, I guess I was being naive.
> See the end of drivers/dma/fsldma.h. Likewise with Freescale's PCI host
> bridges; for some reason the bus itself being little endian led to the host
> bridge control registers also being little endian.
Right. But still, isn't it better to handle it on a case-by-case basis
in the drivers? In some cases, it's best to explicitly use a certain
byte order, in others it's best to use whatever is native to the CPU.
Haavard
On Mon, 2 Jun 2008, Haavard Skinnemoen wrote:
>
> > So what happened to the old idea of putting the accessor function pointers
> > in the device/bus structure?
>
> Don't know. I think it sounds like overkill to replace a simple load or
> store with an indirect function call.
Indeed. *Especially* as the driver in practice tends to always know which
one it is statically.
Yes, sometimes the same RTL may end up being used behind two differnt
buses, and with some broken byte-conversion hardware in the middle, but
that's pretty damn rare in the end. It happens, but it happens mostly with
the odd broken kind of embedded setups where somebody took a standard part
and then did something _strange_ to it - and in the process they may well
have introduced other issues as well.
I suspect you find this kind of thing mostly with things like stupid
integrated IDE controllers, and things like byte order tends to be the
_least_ of the issues (specialized register accesses with odd offsets etc
will happen).
So most of the time the byte order is simply decided by the hardware
itself (and LE is the common one, due to ISA/PCI). Sometimes you can set
it dynamically (at which point it's irrelevant - just pick the one you
want).
So I definitely argue against complex IO accessor functions with things
like dynamic support for byte order depending on bus. 99.9% of all
hardware simply do not need them, and the small percentage that might need
it will need special drivers anyway, so they might as well do the
complexity on their own rather than make everybody else care.
See for example the input driver for the i8042 chip: not only do those
things sometimes need native order (probably exactly because it's
integrated on a chip over some special "native bus", or just wired up to
be big-endian on a BE platform by some moron), but you'll also find that
they just need odd accesses anyway exactly because it's oddly wired up
(eg it's some special serial protocol that emulates ISA accesses).
So having some "byte-order correcting function" still wouldn't make any
sense, because it's not just about byte order.
Will that mean that you might occasionally have a "normal" driver and an
"odd" driver that actually drives what is basically the same HW block,
just wired up differently? Sure. But that's still a smaller price to pay
than it would be to try to make everything be "generic" when there is no
point to it.
Linus