[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: xsrc/external/mit/libpciaccess/dist/src
Michael Lorenz wrote:
> Module Name: xsrc
> Committed By: macallan
> Date: Thu Jul 9 19:27:08 UTC 2009
> Modified Files:
> xsrc/external/mit/libpciaccess/dist/src: netbsd_pci.c
> Log Message:
> teack libpciaccess how to discover and map PCI devices on machines with
> more than one host bridge. While there get rid of some local (re)defines
> if PCI-related constants.
> With this Xorg should be able to use any PCI graphics device, no matter
> if it's console or not.
> - cleanup
> - deal with IO spaces
> - fix Xorg -configure
> To generate a diff of this commit:
> cvs rdiff -u -r1.3 -r1.4 xsrc/external/mit/libpciaccess/dist/src/netbsd_pci.c
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> + * NetBSD's userland has a /dev/pci* entry for each bus but userland has no
> + * to tell if a bus is a subordinate of another one or if it's on a different
> + * host bridge.
I have a patch which introduces support for PCI domains. It allows the
userland to distinguish between them by checking if the pci bus belongs
to the same PCI domain.
Patch is at http://www.netbsd.org/~cegger/pci_domain.diff
It has (intentionally) some debug code in it. Please have a look at it
and tell me what you think about it.
> On some architectures ( macppc for example ) all root buses have
> + * bus number 0 but on sparc64 for example the two roots in an Ultra60 have
> + * different bus numbers - one is 0 and the other 128.
At work, I have several amd64 machines with two host bridges. On one
machine the host bridges have the bus numbers 0 and 128 and on an other
they have the bus numbers 0 and 16.
For such machines, there are not enough /dev/pciN files. In order
to use pcictl I need at least three more /dev/pciN with 7 < N <= 10.
> + * With each /dev/pci* we can map everything on the same root and we can also
> + * see all devices on the same root, trying to do that causes problems
> + * - since we can't tell which /dev/pci* is a subordinate we would find some
> + * devices more than once
> + * - we would have to guess subordinate bus numbers which is a waste of time
> + * since we can ask each /dev/pci* for its bus number so we can scan only
> + * buses we know exist, not all 256 which may exist in each domain.
> + * - some bus_space_mmap() methods may limit mappings to address ranges which
> + * belong to known devices on that bus only.
> + * Each host bridge may or may not have its own IO range, to avoid guesswork
> + * here each /dev/pci* will let userland map its appropriate IO range at
> + * PCI_MAGIC_IO_RANGE if defined in <machine/param.h>
> + * With all this we should be able to use any PCI graphics device on any PCI
> + * bus on any architecture as long as Xorg has a driver, without allowing
> + * arbitrary mappings via /dev/mem and without userland having to know or
> + * about translating bus addresses to physical addresses or the other way
> + * around.
> + */
Main Index |
Thread Index |