Re: enable/disable devices behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?


Cheers,

                    Tiago
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux