Menu
▾
▴
gc-linux-cvs
|
From: <aot...@us...> - 2005-09-10 21:18:31
|
Update of /cvsroot/gc-linux/linux/include/asm-ppc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29152/include/asm-ppc Modified Files: io.h Log Message: include/asm-ppc/io.h expects all platforms that are !APUS to provide definitions for isa_{io,mem}_base, pci_dram_offset. 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. Index: io.h =================================================================== RCS file: /cvsroot/gc-linux/linux/include/asm-ppc/io.h,v retrieving revision 1.8 retrieving revision 1.9 diff -u -d -r1.8 -r1.9 --- io.h 23 Jun 2005 20:02:21 -0000 1.8 +++ io.h 10 Sep 2005 21:18:24 -0000 1.9 @@ -34,7 +34,7 @@ #include <asm/mpc83xx.h> #elif defined(CONFIG_85xx) #include <asm/mpc85xx.h> -#elif defined(CONFIG_APUS) || defined(CONFIG_GAMECUBE) +#elif defined(CONFIG_APUS) #define _IO_BASE 0 #define _ISA_MEM_BASE 0 #define PCI_DRAM_OFFSET 0 |
|
From: Albert H. <alb...@ya...> - 2005-09-11 00:38:53
|
--- aot...@us... 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
|
|
From: <a.o...@bl...> - 2005-09-11 01:09:06
|
On Sun, Sep 11, 2005 at 02:38:43AM +0200, Albert Herranz wrote:
> --- aot...@us... 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
|
|
From: Albert H. <alb...@ya...> - 2005-09-11 09:01:36
|
--- Arthur Othieno <a.o...@bl...> 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
|
|
From: <a.o...@bl...> - 2005-09-11 10:50:40
|
On Sun, Sep 11, 2005 at 11:01:27AM +0200, Albert Herranz wrote:
> --- Arthur Othieno <a.o...@bl...> 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
|
|
From: Albert H. <alb...@ya...> - 2005-09-11 10:59:24
|
> 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 |
|
From: <a.o...@bl...> - 2005-09-11 11:07:25
|
On Sun, Sep 11, 2005 at 12:59:16PM +0200, Albert Herranz wrote: > > 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. in/out_be(16|32)(). ioread/write(16|32)be() are simply wrappers around these. > > 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? Noise, yes. But a step towards eventually moving it out of CVS. Arthur |
|
From: Albert H. <alb...@ya...> - 2005-09-11 11:16:02
|
> 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X