On Mon, 2009-02-02 at 15:54 -0500, John Baldwin wrote: > On Monday 02 February 2009 2:54:16 pm John Baldwin wrote: > > Author: jhb > > Date: Mon Feb 2 19:54:16 2009 > > New Revision: 188018 > > URL: http://svn.freebsd.org/changeset/base/188018 > > > > Log: > > - Add a new ioctl to /dev/pci to fetch details on an individual BAR of a > > device. The details include the current value of the BAR (including all > > the flag bits and the current base address), its length, and whether or > > not > > it is enabled. Since this operation is not invasive, non-root users are > > allowed to use it (unlike manual config register access which requires > > root). The intention is that userland apps (such as Xorg) will use this > > interface rather than dangerously frobbing the BARs from userland to > > obtain this information. > > - Add a new sub-mode to the 'list' mode of pciconf. The -b flag when used > > with -l will now list all the active BARs for each device. > > > > MFC after: 1 month > > As with the capability messages, I attempted to make the bar messages match > the output of a verbose dmesg. An example: > > i...@pci0:8:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xda020000, size 131072, enabled > bar [14] = type Memory, range 32, base 0xda000000, size 131072, enabled > bar [18] = type I/O Port, range 32, base 0x3000, size 32, enabled > bar [1c] = type Memory, range 32, base 0xda080000, size 16384, enabled > cap 01[40] = powerspec 2 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled > cap 10[a0] = PCI-Express 2 endpoint
I haven't looked this over thoroughly yet, but will it support BIOS mappings as well? Or should I take a crack at adding that? robert. > There are a few caveats: > > 1) the ioctl will not report any status for a BAR that doesn't have allocated > resources. We could fix this is if we stored details about the BARs we > enumerate during pci_add_child() in the dinfo. > 2) The ioctl will report status for BARs we add via quirks, but the pciconf > doesn't know how to get to them. It may make sense for the IOCTL to work > differently than it does now. Perhaps as an iterator where you request > register 0 the first time, and then pass in the previous register on each > update. It would then walk all the resources and signal end by setting > the register to -1. The current mode does handle what Xorg expects I > think, whereas the iterator approach would require more hacking on X. -- Robert Noland <rnol...@freebsd.org> FreeBSD
signature.asc
Description: This is a digitally signed message part
