--- aothieno@... escribió:
> Instead of working around this with even more #ifdef
> kludge,
> just provide these definitions in the
> platform-specific file.
>
> Besides, this will be moving to include/asm-powerpc/
> RSN, and, having
> to maintain ~550 lines for a 3 line delta doesn't
> seem very practical.
We still have to maintain io.h for the
read{b,w,l}/write{b,w,l} tweak anyway...
So currently, and until someone adds big endian
ioread*/iowrite* support, this change doesn't make too
much sense.
Cheers,
Albert
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es

On Sun, Sep 11, 2005 at 02:38:43AM +0200, Albert Herranz wrote:
> --- aothieno@... escribi?:
> > Instead of working around this with even more #ifdef
> > kludge,
> > just provide these definitions in the
> > platform-specific file.
> >
> > Besides, this will be moving to include/asm-powerpc/
> > RSN, and, having
> > to maintain ~550 lines for a 3 line delta doesn't
> > seem very practical.
>
> We still have to maintain io.h for the
> read{b,w,l}/write{b,w,l} tweak anyway...
No. We don't. These are accessors for PCI and other inherently
little-endian busses, only. In any case, the ones we're using
for gamecube don't provide proper memory barriers.
> So currently, and until someone adds big endian
> ioread*/iowrite* support, this change doesn't make too
> much sense.
These are still queued up in patchwork. They should make it upstream
RSN whenever paulus pushes to Linus, like he just did for ppc64.
Arthur

--- Arthur Othieno <a.othieno@...> escribió:
> > We still have to maintain io.h for the
> > read{b,w,l}/write{b,w,l} tweak anyway...
>
> No. We don't. These are accessors for PCI and other
> inherently
> little-endian busses, only. In any case, the ones
> we're using
> for gamecube don't provide proper memory barriers.
We use that accessors in the GameCube to access i/o
mapped devices, and that spaces are already guarded
and cache-inhibited so we _don't_ need memory barriers
to guarantee ordered access to "memory" (see ppc cache
model and memory coherence).
And we use that accessors because of the current lack
of the appropiate ones. So, we _do_ need them (or we
need to get the necessary patch). All drivers
performing i/o currently use them.
> > So currently, and until someone adds big endian
> > ioread*/iowrite* support, this change doesn't make
> too
> > much sense.
>
> These are still queued up in patchwork. They should
> make it upstream
> RSN whenever paulus pushes to Linus, like he just
> did for ppc64.
So, what's the _real_ effect of your patch?
Why not wait for the ioread/iowrite stuff and submit a
patch that _actually_ does something?
Cheers,
Albert
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es

On Sun, Sep 11, 2005 at 11:01:27AM +0200, Albert Herranz wrote:
> --- Arthur Othieno <a.othieno@...> escribi?:
> > > We still have to maintain io.h for the
> > > read{b,w,l}/write{b,w,l} tweak anyway...
> >
> > No. We don't. These are accessors for PCI and other
> > inherently
> > little-endian busses, only. In any case, the ones
> > we're using
> > for gamecube don't provide proper memory barriers.
>
> We use that accessors in the GameCube to access i/o
> mapped devices, and that spaces are already guarded
> and cache-inhibited so we _don't_ need memory barriers
> to guarantee ordered access to "memory" (see ppc cache
> model and memory coherence).
That change doesn't touch the accessors bit, so I don't see where the
problem is..
> And we use that accessors because of the current lack
> of the appropiate ones. So, we _do_ need them (or we
> need to get the necessary patch). All drivers
> performing i/o currently use them.
The appropriate accessors _do_ exist. None of the drivers doing
I/O actually use them, unfortunately.
> > > So currently, and until someone adds big endian
> > > ioread*/iowrite* support, this change doesn't make
> > too
> > > much sense.
> >
> > These are still queued up in patchwork. They should
> > make it upstream
> > RSN whenever paulus pushes to Linus, like he just
> > did for ppc64.
>
> So, what's the _real_ effect of your patch?
> Why not wait for the ioread/iowrite stuff and submit a
> patch that _actually_ does something?
I think I clarified it enough in the commit message. Nothing has been
broken, intentionally or unintentionally. Like I said, patch exists, and
until it makes it into mainline, include/asm-ppc/io.h remains in CVS.
Arthur

> That change doesn't touch the accessors bit, so I
> don't see where the
> problem is..
There's no problem. That's the problem. Your patch
does actually nothing.
> The appropriate accessors _do_ exist. None of the
> drivers doing
> I/O actually use them, unfortunately.
We can't use them yet, as you already mentioned it.
> I think I clarified it enough in the commit message.
> Nothing has been
> broken, intentionally or unintentionally. Like I
> said, patch exists, and
> until it makes it into mainline,
> include/asm-ppc/io.h remains in CVS.
Yes, nothing is broken. And nothing changed.
That's why I wondered, why the patch? Just cvs noise?
Or did I miss something subtle?
Cheers,
Albert
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es

> in/out_be(16|32)(). ioread/write(16|32)be() are
> simply wrappers around
> these.
Can we safely start using them now in drivers?
If so, I'll start porting drivers to the new
interfaces and testing them. After that we can get rid
of any io.h tweaks, and eventually removing io.h from
cvs.
Cheers,
Albert
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es