Re: Runtime PM for PCI-based USB host controllers

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

 



On Wed, 2 Jun 2010, Rafael J. Wysocki wrote:

> > > Do PCI bus type callbacks need to be reworked to work correctly with unbound
> > > devices?
> > 
> > They do; I neglected to take care of them when first writing this 
> > patch.  After everything is working I'll submit it for real.  For now, 
> > the point was to find out whether this is going in the right direction.
> 
> I don't have a fundamental problem with it.  As long as all things can be made
> work along these lines, it's fine by me.

Arggh!  I just tried out a revised patch.  It seems to work
perfectly, except for one thing.  When I unbound ehci-hcd from one of
the USB controllers, which should have caused the controller to be 
runtime-suspended, this is what showed up in the log:

[  295.651545] pci 0000:00:1d.7: PME# enabled
[  295.664044] pci 0000:00:1d.7: Refused to change power state, currently in D0

Which seems to mean that the controller didn't want to go into D3hot!  
Presumably this is because it was unconfigured when the driver was 
unbound.  That's the only explanation I can think of; the controller 
had no objection about going into D3hot when it was bound to the 
driver.

Assuming other PCI devices will have similar behavior, I have to agree
that there's no point trying to put driverless devices into low-power
states.


One more thing: When looking at the r8169 and e1000e drivers, I noticed
that you used the same test (pci_dev_run_wake -- not the greatest name
in the world, BTW) in both the probe and remove routines.  That's not
the right thing to do if the runtime-wakeup setting could get changed
inbetween.  (I realize that currently there is no way to change the
setting, but in the future there might be.)

Do you want to make an explicit assumption that the runtime wakeup
settings are fixed, not subject to change?  If so, then why not compute
the setting just once, when the device is registered, and store it in
the pci_device structure?  Or even in the struct device?

Alan Stern

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux