lkml.org 
[lkml]   [2001]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Going beyond 256 PCI buses
Date
>It really isn't needed, and I understand why Linus didn't like the
>idea either. Because you can encode the bus etc. info into the
>resource addresses themselves.
>
>On sparc64 we just so happen to stick raw physical addresses into the
>resources, but that is just one way of implementing it.

That would be fine for PIO on PCI, but still is an issue for
VGA-like devices that need to issue some "legacy" cycles on
a given domain. Currently, on PPC, inx/outx will only go to
one bus (arbitrarily choosen during boot) because of that,
meaning that we can't have 2 VGA cards on 2 different domains

That's why I'd love to see a review of the "legacy" (ISA) stuff
in general. I understand that can require a bit of updating of
a lot of legacy drivers to do the proper ioremap's, but that would
help a lot, including some weird embedded archs which love using
those cheap 16 bits devices on all sorts of custom busses. In
those case, only the probe part will have to be hacked since the
drivers will all cleanly use a "base" obtained from that probe-time
ioremap before doing inx/outx.

I'd be happy to help bringing drivers up-to-date (however, I don't
have an x86 box to test with) once we agree on the way do go.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.122 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site