Please configure your email client to wrap lines after 72 columns or
so.
On Wed, 8 Sep 2010, Iverson Fang wrote:
> Dear Alan stern:
>
> I have a problem when I implement usb_autosuspend in our driver.
>
> I handle the pm_usage_cnt by function usb_autopm_get_interface and usb_autopm_put_interface.
>
> When pm_usage_cnt =0 , than driver will go into suspend mode, by function (suspend: xxx_suspend).
>
> Because our driver must auto resume by using function usb_autopm_get_interface to make pm_usage_cnt > 0.
>
> In order auto resume ,Our driver must live when suspend function is implemented .
>
> So now it have problem .
>
> How do I know that which called suspend (suspend: xxxx_suspend) : system ? our driver?
You can tell the difference between a system sleep and an autosuspend
by looking at the second argument of the suspend routine. For example,
suppose your suspend routine is defined like this:
xxxx_suspend(struct usb_device *udev, pm_message_t msg)
The call is an autosuspend if (msg.event & PM_EVENT_AUTO) is nonzero;
otherwise it is a system sleep.
> User will call system suspend at random.
>
> If our driver call usb_autopm_put_interface that pm_usage_cnt =0 , so system suspend .
>
> And call usb_autopm_get_interface that make pm_usage_cnt > 0 than system resume.
>
> This is ok.
>
> But there are many case like that
>
>
> 1. System call suspend before our driver call suspend ,and after that our driver call resume.
When you say "our driver call suspend", do you really mean that the
driver calls usb_autopm_put_interface()?
If yes, then why does your driver call usb_autopm_put_interface() when
the system is going to sleep?
> (Because suspend will only be executed once ,our driver call suspend will not work,
>
> At this case driver execute will making system error.)
Why does the driver try to execute while the device is suspended?
> 2. Our driver call suspend than system call suspend ,and our driver call resume
>
> (this also have problem)
Why does your driver call usb_autopm_get_interface() in that situation?
> Now my solution is using different pUsb's struct to determine that system is in suspend.
>
> The way like that
>
>
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33)
> if(pObj->pUsb_Dev->autosuspend_disabled ==0)
> #else
> if(pObj->pUsb_Dev->auto_pm ==1)
> #endif
> {
> res = rtmp_usb_autopm_get_interface(pObj->intf);
> if (res)
> {
> DBGPRINT(RT_DEBUG_ERROR, ("autopm_resume fail ------\n"));
> return;
> }
> }
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
> else
> {
> return;
> }
> #endif
>
> By if(pObj->pUsb_Dev->autosuspend_disabled ==0) or if(pObj->pUsb_Dev->auto_pm ==1) to determine system is in suspend.
>
> So that driver will or will not to call rtmp_usb_autopm_get_interface to avoid system error.
What is rtmp_usb_autopm_get_interface()?
Your driver should never need to call usb_autopm_get_interface() while
a system sleep is in progress.
> My question is that is this the right solution ?
No.
> Does it have any other solution ?
Yes. But without seeing the code for your driver, I can't tell you
what the solution is.
> In the fuyurer , the kernel version different that the kernel structure change ,
>
> This solution will not work, and is any way to make sure system in suspend or driver in suspend.?
If the driver is designed correctly, you don't need to do this.
Alan Stern
--
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
