All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shubhrajyoti <shubhrajyoti-l0cyMroinI0@public.gmane.org>
To: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
Cc: Shubhrajyoti Datta
	<omaplinuxkernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] I2C: OMAP: xfer: fix runtime PM get/put balance on error
Date: Fri, 29 Jun 2012 11:17:55 +0530	[thread overview]
Message-ID: <4FED418B.8030100@ti.com> (raw)
In-Reply-To: <87lij7nltv.fsf-l0cyMroinI0@public.gmane.org>

On Friday 29 June 2012 03:25 AM, Kevin Hilman wrote:
> Hi Shubhrajyoti,
>
> Shubhrajyoti Datta <omaplinuxkernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> Hi Kevin,
>> Thanks for the patch ,
>> a doubt below
> Thanks for the review.
>
>> On Wed, Jun 27, 2012 at 7:15 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>>> In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on
>>> failure.
>> So the failure means that the usecount is incremented. However the
>> device was not
>> enabled. 
> Correct.
>
>> In that case could we consider
>>
>>    void pm_runtime_put_noidle(struct device *dev);
>>     - decrement the device's usage counter
>>
>> Which will only decrement the counter and does not try to disable it.
> No, that is not needed.
>
>> However I am not sure what happens if you try to disable an already
>> disabled device.
> The runtime PM core already knows that the device is not enabled so will
> not need to call the disable hooks.  It already needs this functionality
> to support the _get_noresume() and _put_noidle() calls.
>
> I tested this on 3730/OveroSTORM where I was seeing this i2c xfer
> failure (and thus a failure in MMC suspend, which uses I2C to control
> the regulator.)
>
> Hope that helps clarify,
Thanks a lot for the clarification.
> If so, Wolfram, can you queue this up in your i2c-embedded/for-next
> branch since this problem was introduced there.
>
> Thanks,
>
> Kevin
>
>>> Without this, after a failed xfer, the runtime PM usecount will have
>>> been incremented, but not decremented
>> Agree.
>>
>>> causing the usecount to never
>>> reach zero after a failure.  This keeps the device always runtime PM
>>> enabled which keeps the enclosing power domain active, and prevents
>>> full-chip retention/off from happening during idle.
Reviewed-by: Shubhrajyoti D <shubhrajyoti-l0cyMroinI0@public.gmane.org>
>>> Cc: Shubhrajyoti D <shubhrajyoti-l0cyMroinI0@public.gmane.org>
>>> Signed-off-by: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
>>> ---
>>> This patch applies to current i2c-embedded/for-next branch
>>>
>>>  drivers/i2c/busses/i2c-omap.c |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>>> index 9895fa7..b105733 100644
>>> --- a/drivers/i2c/busses/i2c-omap.c
>>> +++ b/drivers/i2c/busses/i2c-omap.c
>>> @@ -582,7 +582,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
>>>
>>>        r = pm_runtime_get_sync(dev->dev);
>>>        if (IS_ERR_VALUE(r))
>>> -               return r;
>>> +               goto out;
>>>
>>>        r = omap_i2c_wait_for_bb(dev);
>>>        if (r < 0)
>>> --
>>> 1.7.9.2
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: shubhrajyoti@ti.com (Shubhrajyoti)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] I2C: OMAP: xfer: fix runtime PM get/put balance on error
Date: Fri, 29 Jun 2012 11:17:55 +0530	[thread overview]
Message-ID: <4FED418B.8030100@ti.com> (raw)
In-Reply-To: <87lij7nltv.fsf@ti.com>

On Friday 29 June 2012 03:25 AM, Kevin Hilman wrote:
> Hi Shubhrajyoti,
>
> Shubhrajyoti Datta <omaplinuxkernel@gmail.com> writes:
>
>> Hi Kevin,
>> Thanks for the patch ,
>> a doubt below
> Thanks for the review.
>
>> On Wed, Jun 27, 2012 at 7:15 AM, Kevin Hilman <khilman@ti.com> wrote:
>>> In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on
>>> failure.
>> So the failure means that the usecount is incremented. However the
>> device was not
>> enabled. 
> Correct.
>
>> In that case could we consider
>>
>>    void pm_runtime_put_noidle(struct device *dev);
>>     - decrement the device's usage counter
>>
>> Which will only decrement the counter and does not try to disable it.
> No, that is not needed.
>
>> However I am not sure what happens if you try to disable an already
>> disabled device.
> The runtime PM core already knows that the device is not enabled so will
> not need to call the disable hooks.  It already needs this functionality
> to support the _get_noresume() and _put_noidle() calls.
>
> I tested this on 3730/OveroSTORM where I was seeing this i2c xfer
> failure (and thus a failure in MMC suspend, which uses I2C to control
> the regulator.)
>
> Hope that helps clarify,
Thanks a lot for the clarification.
> If so, Wolfram, can you queue this up in your i2c-embedded/for-next
> branch since this problem was introduced there.
>
> Thanks,
>
> Kevin
>
>>> Without this, after a failed xfer, the runtime PM usecount will have
>>> been incremented, but not decremented
>> Agree.
>>
>>> causing the usecount to never
>>> reach zero after a failure.  This keeps the device always runtime PM
>>> enabled which keeps the enclosing power domain active, and prevents
>>> full-chip retention/off from happening during idle.
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>>> Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
>>> Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> ---
>>> This patch applies to current i2c-embedded/for-next branch
>>>
>>>  drivers/i2c/busses/i2c-omap.c |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>>> index 9895fa7..b105733 100644
>>> --- a/drivers/i2c/busses/i2c-omap.c
>>> +++ b/drivers/i2c/busses/i2c-omap.c
>>> @@ -582,7 +582,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
>>>
>>>        r = pm_runtime_get_sync(dev->dev);
>>>        if (IS_ERR_VALUE(r))
>>> -               return r;
>>> +               goto out;
>>>
>>>        r = omap_i2c_wait_for_bb(dev);
>>>        if (r < 0)
>>> --
>>> 1.7.9.2
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2012-06-29  5:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27  1:45 [PATCH] I2C: OMAP: xfer: fix runtime PM get/put balance on error Kevin Hilman
2012-06-27  1:45 ` Kevin Hilman
     [not found] ` <1340761532-27231-1-git-send-email-khilman-l0cyMroinI0@public.gmane.org>
2012-06-27  6:11   ` Shubhrajyoti Datta
2012-06-27  6:11     ` Shubhrajyoti Datta
     [not found]     ` <CAM=Q2cuLCT2VzcUgrpyRWiX61t1F+iWchO9iLC=Ka9MFVm4_bQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-06-28 21:55       ` Kevin Hilman
2012-06-28 21:55         ` Kevin Hilman
     [not found]         ` <87lij7nltv.fsf-l0cyMroinI0@public.gmane.org>
2012-06-29  5:47           ` Shubhrajyoti [this message]
2012-06-29  5:47             ` Shubhrajyoti
2012-08-07  0:28   ` Kevin Hilman
2012-08-07  0:28     ` Kevin Hilman
2012-08-18  8:13     ` Wolfram Sang
2012-08-18  8:13       ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FED418B.8030100@ti.com \
    --to=shubhrajyoti-l0cymroini0@public.gmane.org \
    --cc=khilman-l0cyMroinI0@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=omaplinuxkernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.