Re: Going beyond 256 PCI buses

[Benjamin Herrenschmidt]

> > I beleive there will always be need for some platform specific
> > hacking at probe-time to handle those, but we can at least make
> > the inx/outx functions/macros compatible with such a scheme,
> > possibly by requesting an ioremap equivalent to be done so that
> > we stop passing them real PIO addresses, but a cookie obtained
> > in various platform specific ways.
>
>The cookie can be encoded into the address itself.
>
>This is why readl() etc. take one arg, the address, not a billion
>other arguments like some systems do.

Right, I don't want an additional parameter. Just a clear definition
that, like read/writex(), the in/outx() functions "address" parameter
is not a magic IO address, but a cookie obtained from an ioremap-like
function.

Now, the parameter passed to that ioremap-like function are a different
story. I beleive it could be something like

isa_pioremap(domain, address, size)  for ISA-like PIO
isa_ioremap(domain, address, size)   for ISA-like mem

domain can be 0 for "default" case (or maybe -1 as 0 is a valid
domain number and we may want the default domain to be another one)

For PCI PIOs, we need a pioremap(pci_dev, address, size) counterpart
to ioremap, as mapping of IO space is usually different on each domain.

A nice side-effect of enforcing those rules is that we no-longer need
to have the entire IO space of all domain beeing mapped in kernel virtual
space all the time as it's the case now (at least on PPC), thus saving
kernel virtual address space.

Now, we can argue on the "pioremap" name itself ;)

A typical use is a fbdev driver for a VGA-compatible PCI card. Some of
these still require some "legacy" access before beeing fully useable with
PCI MMIO only. Such driver can use isa_pioremap & isa_ioremap with the
domain number extracted from the pci_dev of the card in order to generate
those necessary cycles.

Ben.