USB D3 vs system S3

[Len Brown]

FYI,
I think we may have an issue here where the entire Linux suspend order
is being proposed to change, when in fact the underlying issue
may really be that USB is in D3 on S3 for this box when it is
not supposed to be deeper below D1.

http://bugzilla.kernel.org/show_bug.cgi?id=9528

-Len

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Rafael J. Wysocki]

Post by Len Brown
FYI,
I think we may have an issue here where the entire Linux suspend order
is being proposed to change, when in fact the underlying issue
may really be that USB is in D3 on S3 for this box when it is
not supposed to be deeper below D1.
http://bugzilla.kernel.org/show_bug.cgi?id=9528

Bug #9528 is not the only test case, though.

Please have a look at this thread:
http://marc.info/?t=119945995300002&r=1&w=2

Thanks,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[David Brownell]

Post by Len Brown
FYI,
I think we may have an issue here where the entire Linux suspend order
is being proposed to change, when in fact the underlying issue
may really be that USB is in D3 on S3 for this box when it is
not supposed to be deeper below D1.
http://bugzilla.kernel.org/show_bug.cgi?id=9528

I still run my system with those patches to hook up PCI and USB
wakeup mechanisms to the ACPI tables. ISTR that they got pulled
at some point because they caused some system to wake up immediately
instead of suspending ... sound familiar?

If that immediate-wake problem is now otherwise resolved, maybe it's
time to revisit the merge of those patches. (From *LAST* January
I think, in at least one otherwise-mergeable incarnation ...)

In the absense of those patches, nothing is hooking up USB to
the relevant ACPI tables.

Want I should repost my latest version of those patches? They
apply cleanly against RC7.

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

[Carlos Corbacho]

Post by Len Brown
FYI,
I think we may have an issue here where the entire Linux suspend order
is being proposed to change, when in fact the underlying issue
may really be that USB is in D3 on S3 for this box when it is
not supposed to be deeper below D1.
http://bugzilla.kernel.org/show_bug.cgi?id=9528

I respectfully disagree. The USB device that exhibits this behaviour (USB2,
the device that gets bound to ehci-hcd) is not the offender - the system will
suspend and resume just fine even after Linux has put it into D3.

USB0 (the device that gets bound to ohci-hcd), does not have this requirement
that it can be only put into D1 when going to S3 - the DSDT here says it's
just fine to put this device into D3 when we advertise XP compatibility.

As I pointed out in the bug:

1) The ACPI suspend ordering is still wrong for suspend on ACPI 1.0 systems

2) Based on poking around in Vista, it may also be required to disable
autosuspend for OHCI on CK804 (nForce 4), since Vista here apparently does
not enable USB autosuspend on the USB hubs on this board (yet enabling
autosuspend is supposedly the default Vista behaviour, and I've certainly
never touched the USB settings in Vista).

Given we have two different BIOS's from different manufacturers for the same
chipset, that both have a similar SMI trap, and are both breaking here, I
wonder if this is a known problem with the reference nVidia BIOS; so Windows
will not put USB devices into D3 early on this chipset, to ensure that USB0
is not in a low power state before _PTS() is called (unfortunately, on point
2, I don't have enough to back it up either way, besides my own observations
here).

-Carlos
--
E-Mail: ***@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Carlos Corbacho]

Post by Carlos Corbacho
2) Based on poking around in Vista, it may also be required to disable
autosuspend for OHCI on CK804 (nForce 4), since Vista here apparently does
not enable USB autosuspend on the USB hubs on this board (yet enabling
autosuspend is supposedly the default Vista behaviour, and I've certainly
never touched the USB settings in Vista).
Given we have two different BIOS's from different manufacturers for the
same chipset, that both have a similar SMI trap, and are both breaking
here, I wonder if this is a known problem with the reference nVidia BIOS;
so Windows will not put USB devices into D3 early on this chipset, to
ensure that USB0 is not in a low power state before _PTS() is called
(unfortunately, on point 2, I don't have enough to back it up either way,
besides my own observations here).

I've had confirmation from another nForce 4 box that Vista also disables
autosuspend/ selective suspend on the root hubs there, so I'm pretty
confident in saying now that this will also be needed in Linux (definitely
for OHCI. I don't think we need to stop autosuspend on EHCI, even though
Windows does appear to disable it for that as well), to avoid inadvertently
triggering the suspend-to-RAM hang on these broken BIOSs.

(Testing also shows that putting the OHCI controller into D2 is no good
either - having it in any state other than D1 before we call the ACPI _PTS()
method will reliably hang the box on suspend).

What's the best way to go about doing this? I've been glancing over the OHCI
code and I can't see how to easily do this (unless 'broken_suspend' is the
correct option here?)

-Carlos

[Alan Stern]

Post by Carlos Corbacho
I've had confirmation from another nForce 4 box that Vista also disables
autosuspend/ selective suspend on the root hubs there, so I'm pretty
confident in saying now that this will also be needed in Linux (definitely
for OHCI. I don't think we need to stop autosuspend on EHCI, even though
Windows does appear to disable it for that as well), to avoid inadvertently
triggering the suspend-to-RAM hang on these broken BIOSs.
(Testing also shows that putting the OHCI controller into D2 is no good
either - having it in any state other than D1 before we call the ACPI _PTS()
method will reliably hang the box on suspend).
What's the best way to go about doing this? I've been glancing over the OHCI
code and I can't see how to easily do this (unless 'broken_suspend' is the
correct option here?)

Currently there's no need to change anything.

The USB autosuspend code affects only the controller's USB interface --
it doesn't touch the PCI side. An autosuspended controller will remain
in D0. Until somebody tries writing autosuspend code for PCI
devices...

Alan Stern

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

[Carlos Corbacho]

Post by Alan Stern
Currently there's no need to change anything.

Ok.

Post by Alan Stern
The USB autosuspend code affects only the controller's USB interface --
it doesn't touch the PCI side. An autosuspended controller will remain
in D0. Until somebody tries writing autosuspend code for PCI
devices...

Is this likely to happen?

-Carlos

[Alan Stern]

Post by Carlos Corbacho

Post by Alan Stern
Currently there's no need to change anything.

Ok.

Post by Alan Stern
The USB autosuspend code affects only the controller's USB interface --
it doesn't touch the PCI side. An autosuspended controller will remain
in D0. Until somebody tries writing autosuspend code for PCI
devices...

Is this likely to happen?

I don't know of anybody working on it. A minimal prerequisite is that
PCI runtime wakeup processing needs to work right -- which it doesn't.
See

http://bugzilla.kernel.org/show_bug.cgi?id=6892

Alan Stern

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

[David Brownell]

=20

Post by Carlos Corbacho

The USB autosuspend code affects only the controller's USB interf=

ace --

Post by Carlos Corbacho

it doesn't touch the PCI side. =A0An autosuspended controller wil=

l remain

Post by Carlos Corbacho

in D0. =A0Until somebody tries writing autosuspend code for PCI
devices...

=20
Is this likely to happen?

=20
I don't know of anybody working on it. =A0A minimal prerequisite is t=

hat=20

PCI runtime wakeup processing needs to work right -- which it doesn't=

=2E =A0

See=20
=20
=A0=A0=A0=A0=A0=A0=A0=A0http://bugzilla.kernel.org/show_bug.cgi?id=3D=

6892

And while most of the non-PCI USB host platforms to which I have access
don't have that type of issue, their hardware isn't actually set up to
offer an analogue of runtime PCI_D3 (for example) power states.

In more detail: they generally have some clocks that could be disabled=
,
but for various reasons they need to be left running. Disabling those
clocks prevents wakeup from working ... yes, a multi-MHz clock just to
detect the D+ (or D-) pullup as it kicks in. Systems using an external
PHY will sometimes offer an alternative, when the PHY can issue those
wakeup IRQs by itself, but that seems oddly uncommon.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html