Re: USB resume issue

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

 



On Tue, Dec 1, 2015 at 4:48 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 1 Dec 2015, Alan Cooper wrote:
>
>> On Tue, Dec 1, 2015 at 2:35 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>> >> I'm now sure the host in "non-compliant".
>> >
>> > It is non-compliant if it turns off Vbus power during suspend.  But
>> > that may be caused by the platform more than by the controller itself.
>> >
>>
>> I wasn't able to find any document that states that VBUS must be on in
>> S3 mode.
>
> Hmmm, that's a little tricky.  Were you able to find a document that
> says Vbus must be on in S0?  People tend to make assumptions about
> these things without stating them clearly.
>
> The USB-2.0 spec says (section 7.2.1, the paragraph about root port
> hubs): "Systems that obtain operating power externally, either AC or
> DC, must supply at least five unit loads to each port."  (A unit load
> is 100 mA.)
>
> There's no mention of suspend, S3, or anything else.  However, I think
> we can assume this refers to the case where the root hub is not
> suspended.
>
> Section 7.2.3 discusses power control during suspend/resume.  Among
> other things, it says:
>
>         When a hub is in the Suspend state, it must still be able to
>         provide the maximum current per port (one unit load of current
>         per port for bus-powered hubs and five unit loads per port for
>         self-powered hubs). This is necessary to support remote
>         wakeup-capable devices that will power-up while the remainder
>         of the system is still suspended.
>
> Although it doesn't say so explicitly, this includes root hubs as well
> as external hubs.  The normal current draw during suspend will of
> course be a lot smaller than this; the maximum is needed only during
> the time that a downstream device is powering up because of a wakeup
> event.
>
>>  In our SoC, the USB controller is not in the AON block so it
>> looses power in S3 and that disables the USB VBUS supply. If I can
>> prove our SoC is out of spec, I can probably get it fixed in future
>> chips.
>
> Maybe this reference will help.

I agree that for USB suspend modes, VBUS must be on, and our hardware
behaves that way for runtime suspend. The question is for system wide
suspend (S3/STR) can the system shut down the USB hardware entirely.
The ACPI spec and Linux Documents/power/states.txt seem to allow either
design. From states.txt under S3 mode: "In many cases, all peripheral buses
lose power when entering STR, so devices must be able to handle the
transition back to the On state".

Thanks for you input
Al Cooper
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux