Re: any global parameter to know system power state

Re: any global parameter to know system power state

[loody]

hi all:
Is there any global parameter which can let us know the pm state?
Such that we can apply different software workaround in our embedded
system by different power state.

Thanks for your help in advance,

Re: any global parameter to know system power state

[Daniel Lezcano]

On 10/10/2013 01:31 PM, loody wrote:
> hi all:
> Is there any global parameter which can let us know the pm state?
> Such that we can apply different software workaround in our embedded
> system by different power state.

Can you elaborate and give an example ?


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: any global parameter to know system power state

[loody]

hi Daniel:


2013/10/10 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 10/10/2013 01:31 PM, loody wrote:
>>
>> hi all:
>> Is there any global parameter which can let us know the pm state?
>> Such that we can apply different software workaround in our embedded
>> system by different power state.
>
>
> Can you elaborate and give an example ?
Sure.
I forget to do that to make this question more clear :)


in xhci_resume, we will do xhci_halt usually.
But our embedded system has something wrong and xhci_halt will make it
core dump during resume.

I try to know whether there is any global parameter to let us do the
sw workaround.
(just like below + line)


int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
{
    u32            command, temp = 0;
    struct usb_hcd        *hcd = xhci_to_hcd(xhci);
    struct usb_hcd        *secondary_hcd;
    int            retval = 0;
    ....
    ......
    xhci_dbg(xhci, "Stop HCD\n");
+    if (global_pm_state !=resume){
        xhci_halt(xhci);
+    }
    xhci_reset(xhci);
    spin_unlock_irq(&xhci->lock);
    ......



Appreciate your help,

Re: any global parameter to know system power state

[Alan Stern]

On matters concerning xHCI, you really should CC: the xHCI maintainer.

On Thu, 10 Oct 2013, loody wrote:

> in xhci_resume, we will do xhci_halt usually.
> But our embedded system has something wrong and xhci_halt will make it
> core dump during resume.
> 
> I try to know whether there is any global parameter to let us do the
> sw workaround.
> (just like below + line)
> 
> 
> int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
> {
>     u32            command, temp = 0;
>     struct usb_hcd        *hcd = xhci_to_hcd(xhci);
>     struct usb_hcd        *secondary_hcd;
>     int            retval = 0;
>     ....
>     ......
>     xhci_dbg(xhci, "Stop HCD\n");
> +    if (global_pm_state !=resume){
>         xhci_halt(xhci);
> +    }
>     xhci_reset(xhci);
>     spin_unlock_irq(&xhci->lock);
>     ......

Wouldn't it be better to test the platform?  Then the xhci_halt() could 
be skipped on your embedded systems but nowhere else.

Alan Stern

Re: any global parameter to know system power state

[loody]

hi Alan:
Wow!! Suprise!!
you are here  :-)
Does linux hacker need to monitor every topic?

> On matters concerning xHCI, you really should CC: the xHCI maintainer.
Yes, but I thought this our soc issue, and it is under debugging.
So i try not to bother Sarah. :)

>
> On Thu, 10 Oct 2013, loody wrote:
>
>> in xhci_resume, we will do xhci_halt usually.
>> But our embedded system has something wrong and xhci_halt will make it
>> core dump during resume.
>>
>> I try to know whether there is any global parameter to let us do the
>> sw workaround.
>> (just like below + line)
>>
>>
>> int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
>> {
>>     u32            command, temp = 0;
>>     struct usb_hcd        *hcd = xhci_to_hcd(xhci);
>>     struct usb_hcd        *secondary_hcd;
>>     int            retval = 0;
>>     ....
>>     ......
>>     xhci_dbg(xhci, "Stop HCD\n");
>> +    if (global_pm_state !=resume){
>>         xhci_halt(xhci);
>> +    }
>>     xhci_reset(xhci);
>>     spin_unlock_irq(&xhci->lock);
>>     ......
>
> Wouldn't it be better to test the platform?  Then the xhci_halt() could
> be skipped on your embedded systems but nowhere else.

Yes, actually our designer is trying to figure out why "xhci_halt"
make our system core dump.
off cause I can keep my own parameter to record pm_state, but it would
be better if there is already a global one to the same thing.

Nice to see U, and hope one day I have the pleasure to drink beer with you.