svn commit: r188018 - in head: sys/dev/pci usr.sbin/pciconf
John Baldwin
jhb at freebsd.org
Mon Feb 2 15:09:54 PST 2009
On Monday 02 February 2009 4:09:35 pm Robert Noland wrote:
> 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 at 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?
It does not handle the BIOS BAR. If we need to we can either extend this or
add a new ioctl for that. However, if X is just reading the current setting
then what it is doing now may be fine. I will try to look at the current
code for that in a bit.
--
John Baldwin
More information about the svn-src-all
mailing list