svn commit: r188018 - in head: sys/dev/pci usr.sbin/pciconf

[Robert Noland]

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?

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 at FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20090202/6b3cca2e/attachment.pgp