I don't see any way of getting around virtualizing the IO port space.
(by that I mean encoding more info in the upper IO port address bits)
...
> Right. That's my opinion too. But it's difficult to make everybody agree
> on it ;) Even the simple mechanism Paul Mackerras did so that IOs to
> non-existent devices don't kill the kernel (very small overhead) caused
> some barking ;)
Well, make it a CONFIG_XXX option for your arch and the people who
insist on doing complicated things will have to live with complicated
solutions. I don't have a better idea.
> It's my understanding that you use high
> bits of the IO address to store the HBA number and then use that to call
> the proper access functions.
Correct. For some reason, I thought alpha (or sparc? hose number?) did this
as well.
> That would solve the PCI IO problem (PCI cards
> requiring IOs to BAR-mapped regions), but I don't see how it can fix the
> problem of a card accessing legacy VGA addresses, except if you hand-fixed
> the video drivers to fill those high bits before doing IOs.
That's right. That happens after the bus walk but before drivers see
the device in pci_fixup_bus().
> If I understand things correctly, that mean that each card, instead of
> accessing the legacy VGA port 0xpp, would instead access 0x00bb00pp
> (or whatever mangling you use to stuff the HBA number).
right.
> The question is then to decide is all ISA busses are on a matching PCI bus,
> in which case a simple unsigned pci_get_bus_io_base(int bus_no) -like functio
> n
> would be enough, or if we want a scheme that supports other ISA-like busses ?
I don't know enough about your arch to answer that.
> We could eventually decide to support only PCI, and additionally declare a
> fake PCI bus for an ISA bus not matched to a PCI bus, whose config ops would
> return no device in any slot.
> Do we agree on this ?
In theory yes. But davem already wrote:
| There is no 'fake' ISA bus number you need. There is a 'real' one,
| the one on which the PCI-->ISA bridge lives, why not use that one
| :-)
> Well, from the driver point of view, I think it _do_ exist. Basically, the
> driver will do inb/outb & friends. Whatever those function do in reality is
> arch-dependant.
Right. I meant the underlying implementation of inb/outb.
> But we agree on the fact that in order for those functions to know on which
> bus to tap, an additional information must be "cooked" inside the IO address
> passed to them.
yes.
> Additionally, the same problem is true for ISA memory, when it exist
> obviously.
Really? I expected ISA memory to look like reguler uncacheable memory
and the drivers would simply dereference the address. But I'm not an
expert on how ISA busses work...
> With those two simple functions, we could at least
[ deleted list ]
I have to defer to someone like Alan Cox or Davem or someone who has
a clue about VGA. I don't. Like sparc, parisc doesn't support VGA.
Alan is the only person I know of who's even considered plugging a VGA
card into a parisc box.
> The only thing that's annoying me in the fact that we keep tied to PCI
> is that in various embedded system, there is one (or more) ISA-like
> bus hanging around with legacy devices and no PCI, and abstracting a
In short, where the HW doesn't route transactions down the right bus
adapter, the SW has too.
> bit the notion of IO bus would have helped. But it seem that now, more
> embedded systems are also going toward in-CPU IOs anyway, along with
> eventually a PCI bus for the most expensive ones, so it may finally
> not be an issue in the long term.
It sounds like the HW will do (some of?) the routing.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
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/