Message-ID: <CAK9wHMRiTapv7LGtLES4_gR4-DWxWm7CU+L2Yw0e+tRUCN0wyA@mail.gmail.com>
Date:	Tue, 26 Jun 2012 09:34:06 +0800
From:	chao xie <xiechao.linux@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	rjw@...k.pl, pavel@....cz, linux-arm-kernel@...ts.infradead.org
Subject: Re: pm runtime and system suspend resume

2012/6/25 Alan Stern <stern@...land.harvard.edu>:
> On Mon, 25 Jun 2012, chao xie wrote:
>
>> There is no more question about runtime_idle and runtime_suspend
>> as i understand that runtime_idle indicates that the device is idle,
>> clock may be off, no function there,
>
> runtime_idle indicates the the device is idle and the usage counter is
> 0, right.  Your runtime_idle routine is allowed to call
> pm_runtime_suspend, pm_runtime_autosuspend, or a similar function.
>
>>  runtime_suspend means that the
>> device my be power off, and making it rework may need some
>> initialization work.
>> So in the scenario, for USB, there are some clocks relates to it and
>> there is a phy attached to it.
>> When phy is powered off, it need to be initialized again, and it will
>> take some time.
>> So in the driver, when there is no action, we will call
>> pm_runtime_put, and it will shut off the clocks, for
>> pm_runtime_put_sync_suspend, it will shut off the phy to save more
>> power.
>
> I'm not sure what you mean.
>
> There are only two differences between pm_runtime_put and
> pm_runtime_put_sync_suspend:
>
>        pm_runtime_put calls pm_request_idle, which means your
>        driver's runtime_idle routine gets called asynchronously;
>
>        pm_runtime_put_sync_suspend pm_runtime_suspend, which means
>        your driver's runtime_suspend routine gets called
>        synchronously.
>
> Your runtime_idle routine shouldn't turn off anything.  All it should
> do is call pm_runtime_suspend (or something similar).  Thus, in either
> case your driver's runtime_suspend routine will be called.  It can turn
> off both the clocks and the phy.
>
If we want to separate clocks off and phy off, what should we do?
in fact, in the driver, at some time, it can shutdown clock, and at
some time, it can shut down phy too. So what i want to do it make
runtime_idle to shut down the clocks while in runtime_suspend to
shutdown the clocks and phy.
So when the driver is in idle, and i can call pm_runtime_put which
will call runtime_idle to shutdown the clocks, while when the driver
want to turn off phy, it means it will enter deeper idle, so i need
call pm_runtime_put_sync_suspend.
The question is if when driver calls pm_runtime_put_sync_suspend, the
driver has already called pm_runtime_put, the usaga_count is 0 now, so
driver has to call pm_runtime_get and then call
pm_runtime_put_sync_suspend.
PM runtime provide runtime_idle and runtime_suspend, but the device
status has only two kinds of status, active or no-active. It confuses
me. It means that the pm runtime can not support multiple level of
power mode for device. actually, i think it has provided two kinds of
callback runtime_idle and runtime_suspend, and it should maintain at
least 3 state, idle, suspend, active for the device.

>> Then how do we call pm_runtime_put_sync_suspend if it already calls
>> pm_runtime_put? Do we need do call pm_runtime_get before call
>> pm_runtime_put_sync_suspend because the usage_count is not 0?
>


> You should always call pm_runtime_get (or one of its variants) before
> calling pm_runtime_put (or any of its variants).  Increments and
> decrements of the usage counter must balance.
>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists