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

[John Baldwin]

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

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.

-- 
John Baldwin