The best news was Andrew's: World Domination is proceeding
according to plan!
On Saturday 24 July 2004 20:58, Greg KH wrote:
>
> David, can you think of anything that might have come up, besides the
> rewrite of the power management handling code that you said you were
> going to do? :)
Your evil streak is showing again, Greg ... I thought such rewrites
weren't going to happen until after devfs gets removed? :)
PM issues did come up a lot, true. The root cause being that
the PM framework still needs a lot of work. USB-related issues
in that area:
- The mismatch between ACPI and PCI causes complaints
about USB suspend not working. Basically, "system suspend"
passes an ACPI state (e.g. D2 == 2) code down to PCI devices
rather than its PCI analogue (D3hot == 3), and so of course
the suspend gets rejected when the HC doesn't support the
PCI state with that number (e.g. PCI D2 is optional, and at
least Intel hardware doesn't do it). Not a USB bug; the "new"
PM code in 2.6 is doing the wrong thing, it affects every PCI
driver that actually uses that parameter.
- There's also the issue of USB keeping x86 CPUs out of C3
(or higher) states when a mouse is connected. Basically
the x86 CPU cache snooping means that periodic DMAs
(like polling a USB mouse) prevent the CPU from using
its lowest power mode ... and on Centrino (for example)
that's the difference between 5 watts and 3 watts of CPU
power on an idle system. Stopping that power drain
means the HCDs need to get involved. The easiest way
is turning on USB_SUSPEND mode, but that might not be
user-transparent ... MS-Windows may have hacked HCDs
to not scan USB schedule seconds every millisecond
except when the USB devices are in active use.
- A few folk were very interested in CONFIG_USB_SUSPEND,
but they're the forward-looking ones. Apple for example
seems to like to suspend most USB devices most of the
time; we'll be able to start doing that after a while, and
save power that way. Likewise with remote wakeup.
That's all new-featureville for Linux.
- Some upcoming ACPI patches may finally allow remote
wakeup (as from USB keyboards/mice) to work on Linux,
in conjunction with CONFIG_USB_SUSPEND, but it'll need
manual sysfs tweaks until the PCI code gets taught to
make ACPI listen to the the PCI PME# logic it enables. Soon
to appear in the MM patches.
I think it was Benjamin who was talking about changing the
PM-to-PCI interfaces in ways that'd help address that first
problem, by (a) changing the generic driver framework
suspend method to take an ACPI state like PM_SUSPEND_DISK
(= 2) and (b) changing the PCI driver calls the same way,
so that the PCI drivers would map the ACPI state into some
value that PCI-PM-aware hardware (vs the legacy stuff...)
would pass to pci_set_power_state().
I could see how that might start to work ... except that those
PM_SUSPEND_* states still seem excessively glued to ACPI
S0/S1/S3/S4/... models, so I don't like the notion of making
that approach be "the" Linux-wide one; Linux needs to work
on systems that aren't x86 based laptops.
- As opposed to PCs (laptops etc), systems with really
aggressive power management aren't going to use
"system-wide" suspend policies anywhere near as much
So "S3" doesn't make much sense as a parameter to
pass down to any individual driver.
Instead, more selective device policies are needed ... power
down this group of devices as a group, or (especially!) keep all
devices in low-power states unless they're in active
use. The current model is: keep all in high-power
states except during system-wide suspend.
- The PM framework doesn't even understand the notion of clock
hierarchies needed to turn off sections of chips! This affects
USB on some of the Macintosh ASICs, as well as on many
embedded CPUs. The existing calls may suffice to kick in
low level clock gating (controller clock stops), but they aren't
enough to kick in deeper power saving modes (stop the
48MHz PLL when nobody's using it).
The drivers/base/power code does seem to need some
non-obvious changes, but for now I'd be content just
to have it stop deadlocking when suspend/resume code
has to destroy a device.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
