enable/disable devices behavior

[Jesse Barnes]

On Wed, 06 May 2009 02:37:44 -0300
Tiago Vignatti <vignatti at freedesktop.org> wrote:

> Dave Airlie escreveu:
> > On Wed, 2009-05-06 at 15:14 +1000, Dave Airlie wrote:
> >> On Wed, 2009-05-06 at 15:09 +1000, Dave Airlie wrote:
> >>> On Wed, 2009-05-06 at 01:56 -0300, Tiago Vignatti wrote:
> >>>> Dave Airlie escreveu:
> >>>>> On Wed, 2009-05-06 at 01:37 -0300, Tiago Vignatti wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> AFAIK, the existing interface in libpciaccess to enable a
> >>>>>> device (pci_device_enable) deals always with I/O _and_ memory
> >>>>>> resources. But I'm confused with the behavior of such
> >>>>>> interface because it's not working as I expected. For me it
> >>>>>> has to be equivalent to do the following, in the regs
> >>>>>> configuration space:
> >>>>>>
> >>>>>>      ctrl = (PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
> >>>>>>      pci_device_cfg_write_u32(dev, ctrl, PCI_COMMAND);
> >>>>>>
> >>>>>>
> >>>>>> Isn't it? But it's not happening that. When I call
> >>>>>> pci_device_enable (or just `echo 1 > enable` in device) the
> >>>>>> kernel sometimes sets only the PCI_COMMAND_MEMORY bit or
> >>>>>> simply does nothing. What am I missing here?
> >>>>>>
> >>>>>> Attached, I'm sending a code that I'm using to play with this.
> >>>>> Its not for that.
> >>>>>
> >>>>> Twiddling enable bits from userspace isn't something we want to
> >>>>> be able to do.
> >>>> So what's the intention of the enable field in sysfs?
> >>>>
> >>>> What I want in the end is to build an interface inside pci
> >>>> library to enable/disable a given resource of a device. This is
> >>>> what we were doing in Xorg (sigh) and what we progressively can
> >>>> move out to libpciaccess to build (I expected in a near future)
> >>>> the "system-wide PCI access control".
> >>> The enable field is to let you *enable* cards that haven't been
> >>> yet.
> >>>
> >>> This is just so secondary cards MMIO ranges are enabled. However
> >>> it won't disable anything for you ever.
> >>>
> >>> Machines boot with the secondary disabled, this just lets you
> >>> enable it, and generally once enabled you can read out the ROM at
> >>> least.
> >>>
> >>> You are not allowed enable/disable PCI device resources from
> >>> X.org. This isn't the X servers job at all ever again.
> >>>
> >>> Start to think of X as a non-priv process and design things
> >>> accordingly.
> >>>
> >>> Dave.
> >> Perhaps I haven't explained it,
> >>
> >> but why do we need to ever play with a *PCI* resource?
> >>
> >> Linux does all the PCI setup for us, we never get overlapping PCI
> >> resources.
> >>
> >> VGA should be the only thing we are missing.
> > 
> > Okay daniel pointed out we don't enable i/o resources,
> 
> huumm now it make sense why there's no effect the pci_device_enable
> call inside int10 :)
> 
> It should be to much aggressive to simply set the I/O resources by 
> writing it in the regs configuration space inside pci_device_enable 
> (libpciaccess) for now?

Can you just make the corresponding kernel driver enable the resources
you need instead of trying to do it in userspace?

But again it may depend on VGA arbitration, since enabling I/O decode
on a device will also cause it to respond to legacy I/O cycles, not
just those described in its I/O BARs.

-- 
Jesse Barnes, Intel Open Source Technology Center