enable/disable devices behavior

[Tiago Vignatti]

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