Re: [RFC v2]: Issues implementing clock handling mechanism within UART driver

Govindraj
2011-08-01T12:47:20Z

On Mon, Aug 1, 2011 at 3:32 PM, Felipe Balbi <balbi@ti.com> 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-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html