On Tuesday 18 February 2014 11:00:05 Jason Gunthorpe wrote: > > > > You will have overlapping physical IO bus addresses - each domain will > > > have a 0 IO BAR - but those will have distinct CPU physical addresses > > > and can then be uniquely mapped into the IO mapping. So at the struct > > > resource level the two domains have disjoint IO addresses, but each > > > domain uses a different IO offset.. > > > > This would be the common case, but when we have a generic helper function, > > it's actually not that are to handle a couple of variations of that, > > which we may see in the field and can easily be described with the > > existing binding. > > I agree the DT binding ranges has enough flexibility to describe all > of these cases, but I kind of circle back to the domain discussion and > ask 'Why?'. > > As far as I can see there are two reasonable ways to handle IO space: > - The IO space is 1:1 mapped to the Physical CPU Address. In most > cases this would require 32 bit IO BARS in all devices. I wouldn't consider this one reasonable ;-) In particular, it would break /dev/port access horribly. > - The IO space in a domain is always 0 -> 64k and thus only ever > requires 16 bit BARs > > And this is possible too: > - The IO space is 1:1: mapped to Linux Virtual IO port numbers > (which are a fiction) and devices sometimes require 32 bit > IO BARs. This gives you lspci output that matches dmesg and > /proc/ioport. These two seem fine. > Things get more complex if you want to support legacy non-BAR IO (eg > VGA). Then you *really* want every domain to support 0->64k and you > need driver support to setup a window for the legacy IO port. (eg on a > multi-port root complex there is non-PCI spec hardware that routes the > VGA addresses to the root port bridge that connects to the VGA card) > Plus you probably need a memory hole around 1M.. For the I/O space part of this, that would be the same as your second example above. For memory space, you need both the 640k-1M window and the 15M-16M window. We have a couple of ARM platforms that actually have a PCI MMIO window starting at bus address 0 with a mem_offset matching the physical base address to facilitate VGA access, try 'git grep -w vga_base'. > But, I think this is overthinking things. IO space really is > deprecated, and 0->64k is a fine default for everything but very > specialized cases. We may not need the entire complexity to handle all cases, but I think it's a good idea to detect the ones we don't handle and then warn about them. For some things, just doing it right may be easier than detecting the case where we don't. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
