Hello!
I'm now very busy with work on my diploma thesis, so sorry for replying
with such a delay and to the whole thread at once.
> His response is that an unsigned char and the "fake" bus hierarchy can
> represent all cases we need to handle, and I honestly cannot disagree
> with him, he is right. So I would not suggest to pursue this idea
> much further.
As long as we fit in the 8-bit bus number, we should probably stay
with the current solution. On the other hand, the whole PCI subsystem
itself is already capable of supporting real separate PCI busses --
everything is referred to by struct pci_bus and struct pci_dev, so if
you use pci_bus->sysdata to identify the correct hose, everything
should work properly, only the backward-compatibility pcibios_* calls
won't.
> I've just finished implementing alpha-like syscalls on my 2.2 PPC tree,
> it's mostly a "proof of concept" for now, but your idea is probably better.
No such syscalls are needed -- /proc/bus/pci/* is THE correct way
to access PCI config registers on all platforms. On the other hand,
you should NOT use it to modify base addresses of regions since only
the kernel really knows what do they mean. As far as I understand,
except for working around bugs like S3 cards reporting bogus region
sizes (which the kernel already handles anyway), there is no need
to move around resource regions in the X server.
> On the other hand, dealing with the issues surrounding mmap'ing PCI
> devices on these different busses is an issue that should be handled
> because the 32-bit PCI base address register (plus some offset
> perhaps) is not enough to uniquely map in the registers of a PCI
> device in such configurations. This is a huge problem with PCI
> graphics cards on sparc64 for example, because this issue does not
> jive well with how all the xfree86 pci logic operates.
> What I was thinking about, in order to address this whole issue, is to
> provide a /dev/pcimmap like device, you open it, run an ioctl on it to
> select a "bus, device, function, base address register" quadruple,
> then at that point you can "mmap" that specific device area with some
> offset from the base register indicated using the mmap offset
> parameter.
> There's one thing Egbert pointed me to: Some arch may require also to be
> passed a "shift" information indicating a necessary shift on the CPU
> addresses when mapping the PCI addresses. If I understand Egbert
> correctly, than mean than an inb-like function would do something like
> *((u8*)(addr << shift)), addr beeing the register address in the card's
> space. This needs to be returned by this driver (via another ioctl).
> Also, this driver could probably also handle read/writes so that simple
> things that don't need specific performances can simply use those
> functions and avoid having to handle the shift at all.
We probably don't need any new devices for configuring special features of PCI
devices, querying type of byte scattering or mmaping MMIO -- all such things
can be handled via ioctl() on /proc/bus/pci files.
> We also need to somewhat handle the legacy ISA space. I beleive we can
> decide once for all that we handle only one legacy ISA space and decide
> at boot time on which bus/bridge/offset it is located.
With ISA dying out, it's probably a good strategy.
| I feel very strongly that Linus would agree with me on this point,
| and that if he knew what XFree was doing wrt. PCI device resource
| allocation, he would most likely scream :-)
Agreed. I've screamed as well when I've seen it :)
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> <mj@suse.cz> http://atrey.karlin.mff.cuni.cz/~mj/ "IBM = Industry's Biggest Mistake"- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:23 EST