On Mon, Aug 1, 2011 at 3:32 PM, Felipe Balbi <balbi@xxxxxx> wrote:
> Hi,
>
> (fix your mailer dude)
Sorry some settings got screwed up with my mailer
>
> On Mon, Aug 01, 2011 at 03:26:52PM +0530, Raja, Govindraj wrote:
[..]
>> this hunk is unnecessary. Clocks are always on when they are called.
>>
>> The problem is:
>> [1]:
>> runtime_put -> *power.lock* - > rpm->suspend -> above pr_debug ->
>> console_write -> get_sync
>> -> *power.lock* -> rpm resume
>> power.lock contention.
>
> Are you sure ? If the device is still on, won't that get_sync() only
> increase the pm counter ? Instead of going through everything ?? Oh
> well, this is becoming quite racy :-(
Yes true, but before it increments the counter it will take
power.lock
if we look into internals.
pm_runtime_get_sync -> *__pm_runtime_resume* --> rpm_resume
int __pm_runtime_resume(struct device *dev, int rpmflags)
{
[..]
spin_lock_irqsave(&dev->power.lock, flags);
retval = rpm_resume(dev, rpmflags);
spin_unlock_irqrestore(&dev->power.lock, flags);
[..]
}
Same applicable for runtime_put
[..]
>> I'll leave this to Kevin to decide what to do, but clocks are off
>> here...
>>
>> Yes fine.�
>> Since most of these prints will be printed if DEBUG macro
>> is defined in respective files and *debug* is used in command line.
>> Can't leave uart clocks active always on debug cases.
>> [If *debug* �used as command line]
>> and gate uart clocks only for non debug cases.
>> With this approach�at least�we can have a clean solution
>> in uart driver also without adding clock gating from idle path.
>> Not sure if this�agreeable.
>> As of now gating from idle path seems to be only clean approach.
>
> I see.. that could be one way... let's see how Kevin feels about it
> though.
>
OK.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
