enable/disable devices behavior

Dave Airlie airlied at redhat.com
Tue May 5 22:14:49 PDT 2009


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.

Dave.

> 
> 
> _______________________________________________
> xorg-devel mailing list
> xorg-devel at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel



More information about the xorg-devel mailing list