USB D3 vs system S3

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-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: USB D3 vs system S3

[Rafael J. Wysocki]

On Tuesday, 8 of January 2008, Len Brown wrote:
> 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

Re: USB D3 vs system S3

[David Brownell]

On Tuesday 08 January 2008, Len Brown wrote:
> 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

Re: USB D3 vs system S3

[Carlos Corbacho]

On Tuesday 08 January 2008 20:47:00 Len Brown wrote:
> 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: carlos@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-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: USB D3 vs system S3

[Carlos Corbacho]

On Wednesday 09 January 2008 00:09:21 Carlos Corbacho wrote:
> 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
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: USB D3 vs system S3

[Alan Stern]

On Wed, 9 Jan 2008, Carlos Corbacho wrote:

> 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

Re: USB D3 vs system S3

[Carlos Corbacho]

On Wednesday 09 January 2008 16:07:04 Alan Stern wrote:
> Currently there's no need to change anything.

Ok.

> 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
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: USB D3 vs system S3

[Alan Stern]

On Wed, 9 Jan 2008, Carlos Corbacho wrote:

> On Wednesday 09 January 2008 16:07:04 Alan Stern wrote:
> > Currently there's no need to change anything.
> 
> Ok.
> 
> > 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

Re: USB D3 vs system S3

[David Brownell]

On Wednesday 09 January 2008, Alan Stern wrote:
> 
> > > 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

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" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html