Re: how to trigger function in usb_device_pm_ops

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

 



hi alan:

2013/10/1 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Tue, 1 Oct 2013, yoma sophian wrote:
>
>> hi all:
>> >>
>> >>> >> When we use "echo mem > /sys/power/state" , we didn't see any function
>> >>> >
>> >>> > "mem" is a kind of sleep, not a kind of hibernation.
>> >>> But I don't see any usb sleep funciton called from log
>> >>
>> >> What messages do you expect to see?
>> > When I try the command yesterday, I didn't plug in usb dick. :)
>> > I attach the log after I plug in usb stick.
>> from the log, I conclude calling path as below:
>> 1. calling dev_pm_ops
>> 2. calling interface driver's suspend
>> 3. calling usb device's suspend.
>
> That's right.
>
>> My questions are:
>> 1. in dev_pm_ops, we use same function, usb_suspend, but different
>> pm_message to tell different kind of power management.
>
> Yes.
>
>> 2. but in usb device's suspend, generic_suspend, different pm_message
>> seems has the same effect.
>
> Not true.  generic_suspend() does this:
>
>         /* Non-root devices don't need to do anything for FREEZE or PRETHAW */
>         else if (msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_PRETHAW)
>                 rc = 0;
>         else
>                 rc = usb_port_suspend(udev, msg);
>
> The FREEZE and PRETHAW events are treated differently from the others.
>
>> 3. is there any platform apis in generic_suspend for us to register
>> when we try to handle hw's specific behavior during hibernate/restore?
>
> No.  What specific behavior do you want to handle?

1. in susped, we will gate our ehci clk
in resumt, we need to release clk gating to let ehci control work.
and above are platform specific behavior need to do
there seems no such place to do above 2 things.


2. in ehci_bus_resume, which handle ehci go back from both suspend/hibernate.
    This function handle ehci basic register default setting, such as
re-init operational registers and restore CMD_RUN, framelist size, and
irq threshold

                /* at least some APM implementations will try to deliver
 402         * IRQs right away, so delay them until we're ready.
 403         */
 404        ehci_writel(ehci, 0, &ehci->regs->intr_enable);
 405
 406        /* re-init operational registers */
 407        ehci_writel(ehci, 0, &ehci->regs->segment);
 408        ehci_writel(ehci, ehci->periodic_dma, &ehci->regs->frame_list);
 409        ehci_writel(ehci, (u32) ehci->async->qh_dma,
&ehci->regs->async_next);
 410
 411        /* restore CMD_RUN, framelist size, and irq threshold */
 412        ehci->command |= CMD_RUN;
 413        ehci_writel(ehci, ehci->command, &ehci->regs->command);
 414        ehci->rh_state = EHCI_RH_RUNNING;
 415
 416        /*

3. In xhci_bus_resume, I cannot see any behaviour for re-init
operational registers and restore CMD_RUN, framelist size, and irq
threshold. for xhci.
when hibernate happen, the data allocated for device context still
exist in ddr, but xhci should reinitialise the base address to its
register.
If my consumption is correct, why I cannot find this part in xhci_bus_resume.
so far xhci_bus_resume only take port status.

Grateful to your kind help,
--
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