Search Linux Wireless

Re: is L1 really disabled in iwlwifi

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

 



On Wed, May 1, 2013 at 2:31 AM, Emmanuel Grumbach <egrumbach@xxxxxxxxx> wrote:
> [from Bjorn's mail]
>> In Emmanuel's case, we don't get _OSC control, so
>> pci_disable_link_state() does nothing.
>
> Right, but this is true with the specific log I sent to you. Is it
> possible that another platform  / BIOS, we *will* get _OSC control and
> that pci_disable_link_state() will actually do something?  In that case
> I would prefer not to remove the call to pcie_disable_link_state().

Yes, absolutely, on many platforms we will get _OSC control, and
pci_disable_link_state() will work as expected.  The problem is that
the driver doesn't have a good way to know whether pci_disable_link()
did anything or not.

Today I think we have:

1) If the BIOS grants the OS permission to control PCIe services via
_OSC, pci_disable_link_state() works and L1 will be disabled.

2) If the BIOS does not grant permission, pci_disable_link_state()
does nothing and L1 may be enabled or not depending on what
configuration the BIOS did.

If the device really doesn't work reliably when L1 is enabled, we're
currently at the mercy of the BIOS -- if the BIOS enables L1 but
doesn't grant us permission via _OSC, L1 will remain enabled (as it is
on your system).

> Also - in the log I sent you, we don't get _OSC control, but I can see
> 'disabling PCIe ASPM" ... and it *is* enabled (since L1 works). So I
> am kinda scratching my head here...

The code is a bit convoluted, but I *think* the "disabling PCIe ASPM"
message basically means "Linux is not going to touch ASPM
configuration," so we just use whatever the BIOS set up.

>> The general issue here is that Windows will (as far as we've been able
>> to determine) never touch ASPM registers unless given PCIe control via
>> _OSC. Drivers are presumably able to override this by hitting
>> configuration registers themselves. The pci_disable_link_state()
>> functions are currently broadly equivalent to the helper functions
>> provided in the Windows .inf files, and if drivers really want to
>> disable the control themselves then they can do so.

The Windows mechanism (described in "PCI Express in Depth for Windows
Vista and Beyond" [1]) is to put a "Needs=PciASPMOptOut" statement in
the .inf file.

My impression is that if the BIOS enables ASPM but doesn't grant
control to the OS, Vista will generally leave the ASPM config alone.
I guess the question is what happens when a driver .inf specifies
PciASPMOptOut in this case.

I don't think it makes sense to provide this mechanism to driver
writers, but make it only work if the BIOS grants control.  The doc
doesn't mention anything about drivers needing to do anything extra to
cover the case when the BIOS didn't grant control.  So my guess is
that when PciASPMOptOut is specified, Vista will turn off ASPM for
that device in either case.  But maybe you've tested this and
determined otherwise?

>> The only time this should be relevant is if (a) the BIOS has enabled L1
>> on iwlwifi, (b) the BIOS has disabled ASPM control, and (c) the hardware
>> doesn't work with L1 enabled. Are there really cases where that's true?
>
> After having read (a bit) about _OSC I can say the following:
> L1 is a must for the Windows driver - so that it doesn't sounds
> reasonable that the .inf of the Windows driver for Intel Wireless NICs
> disables ASPM through _OSC or through any other mechanism.
> (a) - this is really platform / BIOS dependent, and I can't test all
> the platform out there
> (b) - ditto
> (c) - the HW *should* work with L1 enabled but we may very well have a
> bug in the driver. I have tried to check the way we initialize the HW
> and it seems fine, but one never knows.

Do you know if the Windows driver for these iwlwifi devices specifies
PciASPMOptOut?  If it doesn't, that's a pretty good clue that the
Linux driver shouldn't need to use pci_disable_link_state().

Bjorn

[1] http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/cpa070_wh06.ppt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux