Date: Mon, 02 Feb 2009 16:09:35 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r188018 - in head: sys/dev/pci usr.sbin/pciconf Message-ID: <1233608975.1492.45.camel@ferret.2hip.net> In-Reply-To: <200902021554.55644.jhb@freebsd.org> References: <200902021954.n12JsGT2005768@svn.freebsd.org> <200902021554.55644.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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: > > igb0@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 <rnoland@FreeBSD.org> FreeBSD [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmHYQ8ACgkQM4TrQ4qfROMQbQCfe10dRnIuqFXgaPzlO7CyG+5P UXEAnj+0ZE8841fCl7+A5HirZTfyWByV =bk7a -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1233608975.1492.45.camel>