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
--=-g/9T2Lflg1SfluNqpfAK Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 > >=20 > > Log: > > - Add a new ioctl to /dev/pci to fetch details on an individual BAR o= f a > > device. The details include the current value of the BAR (includin= g all > > the flag bits and the current base address), its length, and whethe= r or not > > it is enabled. Since this operation is not invasive, non-root user= s are > > allowed to use it (unlike manual config register access which requi= res > > root). The intention is that userland apps (such as Xorg) will use= this > > interface rather than dangerously frobbing the BARs from userland t= o > > 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. > > =20 > > MFC after: 1 month >=20 > As with the capability messages, I attempted to make the bar messages mat= ch > the output of a verbose dmesg. An example: >=20 > igb0@pci0:8:0:0: class=3D0x020000 card=3D0x10a715d9 chip=3D0x10a78= 086 rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > class =3D network > subclass =3D ethernet > bar [10] =3D type Memory, range 32, base 0xda020000, size 131072, e= nabled > bar [14] =3D type Memory, range 32, base 0xda000000, size 131072, e= nabled > bar [18] =3D type I/O Port, range 32, base 0x3000, size 32, enabled > bar [1c] =3D type Memory, range 32, base 0xda080000, size 16384, en= abled > cap 01[40] =3D powerspec 2 supports D0 D3 current D0 > cap 05[50] =3D MSI supports 1 message, 64 bit > cap 11[60] =3D MSI-X supports 10 messages in map 0x1c enabled > cap 10[a0] =3D 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: >=20 > 1) the ioctl will not report any status for a BAR that doesn't have allo= cated > 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 pcic= onf > 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 reque= st > 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 setti= ng > the register to -1. The current mode does handle what Xorg expects I > think, whereas the iterator approach would require more hacking on X. --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-g/9T2Lflg1SfluNqpfAK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmHYQ8ACgkQM4TrQ4qfROMQbQCfe10dRnIuqFXgaPzlO7CyG+5P UXEAnj+0ZE8841fCl7+A5HirZTfyWByV =bk7a -----END PGP SIGNATURE----- --=-g/9T2Lflg1SfluNqpfAK--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1233608975.1492.45.camel>