Re: USB Resume behaviour in case of suspend to resume

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

 



On Wed, Dec 7, 2011 at 4:51 PM, Peter Chen <hzpeterchen@xxxxxxxxx> wrote:
> On Wed, Dec 7, 2011 at 1:30 PM, Pratyush Anand <pratyush.anand@xxxxxxxxx> wrote:
>> Hi,
>>
>> I am working with linux-2.6.38 and testing suspend to ram behaviour in
>> case usb2.0.
>>
>> 1.  I have connected a HS device, so it is enumerated on EHCI.
>> 2.  Now I do suspend to ram (echo mem > /sys/power/state).
>> 3.  When I do resume, I see that the same HS device is now enumerated by OHCI.
>> 4.  It happens because of following reasons:
>>       a . Power of controller is lost during suspend. By reading
>> following link it seems that power should not be lost.
>> http://comments.gmane.org/gmane.linux.usb.general/29432 ;. But, we can
>> not prevent it , as USB controller and many other peripherals are in
>> same power island and , this island needs to be switched off in echo
>> mem operation.
> Lost vbus of USB bus will cause disconnect event for device,
> suspend/resume needs
> vbus is present, the remote wakeup will not be supported if vbus is not present.

We do not use wakeup from usb device. We use gpio as syatem wake up source.
I think reset_resume implementation of  usb_port_resume function,
considers that it is the same device which was in configured state
before suspend. So, does not do logical disconnection.

>
>>      b.  Power on reset value of Configured flag (Bit 1 of EHCI offset
>> 0x50) is 0. So, default owner is companion controller. Therefore, OHCI
>> takes over and now device is enumerated by it.  A new sdb node is
>> created with new bus and device number. However, successive suspend
>> and resume creates same node, as now device is always with OHCI.
>>
>> 5.  Now question is, what should be workaround? I am doing following
>> workaround. Is this correct? or am  I missing something and not able
>> to use already available feature of kernel?
>>
>>     a. In my controller specific suspend, I keep track of
>> configured_flag. If it is set in controller, I set my software flag
>> too.
>>     b. If configured_flag is set, then I also save ehci port status
>> of all the ports.
>>     c. In resume, I check if configured flag was set.
>>     d. If it was set, then I check if port was powered.
>>     e. If it was powered, I set power bit (bit 12) and I check if a
>> device was present.
>>     f.  If a device was present, then I wait (with a timeout) till
>> device present bit (bit 0) becomes 1.
>>
>>     g. With these modifications, I see that usb_port_resume function
>> is correctly able to see reset resume and device is enumerated with
>> same address and bus at EHCI.
>>
>> Please advice, if it is the right way.
>>
>> Regards
>> Pratyush
>> --
>> 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
>
>
>
> --
> BR,
> Peter Chen
--
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