[PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[Laxman Dewangan]

Use clk_disable_unprepare() inplace of clk_disable().
This was missed as part of moving clock enable/disable to
prepare/unprepare for using the common clock framework.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 drivers/i2c/busses/i2c-tegra.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 00cdc10..d071cf0 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -696,7 +696,7 @@ static int __devinit tegra_i2c_probe(struct platform_device *pdev)
 	ret = i2c_add_numbered_adapter(&i2c_dev->adapter);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to add I2C adapter\n");
-		clk_disable(i2c_dev->i2c_clk);
+		clk_disable_unprepare(i2c_dev->i2c_clk);
 		return ret;
 	}
 
-- 
1.7.1.1

Re: [PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[Stephen Warren]

On 06/20/2012 06:56 AM, Laxman Dewangan wrote:
> Use clk_disable_unprepare() inplace of clk_disable().
> This was missed as part of moving clock enable/disable to
> prepare/unprepare for using the common clock framework.

Wolfram,

Since I've taken the other I2C patch on this topic through the Tegra
tree (in order to satisfy any common clock dependencies there), I
believe I should take this one patch through the Tegra tree too.

I see no reason not to take the second patch in the series through the
I2C tree though.

Do you agree?

Re: [PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[Stephen Warren]

On 06/20/2012 10:26 AM, Stephen Warren wrote:
> On 06/20/2012 06:56 AM, Laxman Dewangan wrote:
>> Use clk_disable_unprepare() inplace of clk_disable().
>> This was missed as part of moving clock enable/disable to
>> prepare/unprepare for using the common clock framework.
...
> I see no reason not to take the second patch in the series through the
> I2C tree though.

Uggh. Ignore that paragraph - the other patch was sent separately not as
a series.

Re: [PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[Laxman Dewangan]

Stephen,

On Wednesday 20 June 2012 09:57 PM, Stephen Warren wrote:
> On 06/20/2012 10:26 AM, Stephen Warren wrote:
>> On 06/20/2012 06:56 AM, Laxman Dewangan wrote:
>>> Use clk_disable_unprepare() inplace of clk_disable().
>>> This was missed as part of moving clock enable/disable to
>>> prepare/unprepare for using the common clock framework.
> ...
>> I see no reason not to take the second patch in the series through the
>> I2C tree though.
> Uggh. Ignore that paragraph - the other patch was sent separately not as
> a series.

so are you taking care of this patch or do I need to send the patch 
based on your tree in place of linux-next?

Re: [PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[Stephen Warren]

On 06/25/2012 03:46 AM, Laxman Dewangan wrote:
> Stephen,
> 
> On Wednesday 20 June 2012 09:57 PM, Stephen Warren wrote:
>> On 06/20/2012 10:26 AM, Stephen Warren wrote:
>>> On 06/20/2012 06:56 AM, Laxman Dewangan wrote:
>>>> Use clk_disable_unprepare() inplace of clk_disable().
>>>> This was missed as part of moving clock enable/disable to
>>>> prepare/unprepare for using the common clock framework.
>> ...
>>> I see no reason not to take the second patch in the series through the
>>> I2C tree though.
>> Uggh. Ignore that paragraph - the other patch was sent separately not as
>> a series.
> 
> so are you taking care of this patch or do I need to send the patch
> based on your tree in place of linux-next?

Yes, this patch should be applied through the Tegra tree, since it will
be a dependency of the common clock framework switchover there, which I
hope to take place this kernel cycle.

I did just attempt to apply this patch to the for-3.6/common-clk branch,
but it doesn't apply:-( Could you please rebase and resend. Thanks.

Re: [PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[Laxman Dewangan]

On Monday 25 June 2012 09:25 PM, Stephen Warren wrote:
> On 06/25/2012 03:46 AM, Laxman Dewangan wrote:
>> Stephen,
>>
>> On Wednesday 20 June 2012 09:57 PM, Stephen Warren wrote:
>>> On 06/20/2012 10:26 AM, Stephen Warren wrote:
>>>> On 06/20/2012 06:56 AM, Laxman Dewangan wrote:
>>>>> Use clk_disable_unprepare() inplace of clk_disable().
>>>>> This was missed as part of moving clock enable/disable to
>>>>> prepare/unprepare for using the common clock framework.
>>> ...
>>>> I see no reason not to take the second patch in the series through the
>>>> I2C tree though.
>>> Uggh. Ignore that paragraph - the other patch was sent separately not as
>>> a series.
>> so are you taking care of this patch or do I need to send the patch
>> based on your tree in place of linux-next?
> Yes, this patch should be applied through the Tegra tree, since it will
> be a dependency of the common clock framework switchover there, which I
> hope to take place this kernel cycle.
>
> I did just attempt to apply this patch to the for-3.6/common-clk branch,
> but it doesn't apply:-( Could you please rebase and resend. Thanks.

Looked at your common_clk branch and the related code is not there.
The clk_disable() in the particular case is introduced by change
i2c: tegra: make all resource allocation through devm_*
which is not in your branch.

Then later Prashant post the change as
i2c: tegra: Add clk_prepare/clk_unprepare
and it does not accounted for the above patch.

So none of your local tree will have this issue.

You need to pull some of the change from Wofram's tree to you commn-clk 
to fix the issue.
Suggest to pull the change
i2c: tegra: make all resource allocation through devm_*
i2c: tegra: support for I2C_M_NOSTART functionality
i2c: tegra: add PROTOCOL_MANGLING as supported functionality.
i2c: tegra: make sure register writes completes

Re: [PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[Stephen Warren]

On 06/26/2012 12:27 AM, Laxman Dewangan wrote:
> On Monday 25 June 2012 09:25 PM, Stephen Warren wrote:
>> On 06/25/2012 03:46 AM, Laxman Dewangan wrote:
>>> Stephen,
>>>
>>> On Wednesday 20 June 2012 09:57 PM, Stephen Warren wrote:
>>>> On 06/20/2012 10:26 AM, Stephen Warren wrote:
>>>>> On 06/20/2012 06:56 AM, Laxman Dewangan wrote:
>>>>>> Use clk_disable_unprepare() inplace of clk_disable().
>>>>>> This was missed as part of moving clock enable/disable to
>>>>>> prepare/unprepare for using the common clock framework.
>>>> ...
>>>>> I see no reason not to take the second patch in the series through the
>>>>> I2C tree though.
>>>> Uggh. Ignore that paragraph - the other patch was sent separately
>>>> not as
>>>> a series.
>>> so are you taking care of this patch or do I need to send the patch
>>> based on your tree in place of linux-next?
>> Yes, this patch should be applied through the Tegra tree, since it will
>> be a dependency of the common clock framework switchover there, which I
>> hope to take place this kernel cycle.
>>
>> I did just attempt to apply this patch to the for-3.6/common-clk branch,
>> but it doesn't apply:-( Could you please rebase and resend. Thanks.
> 
> Looked at your common_clk branch and the related code is not there.
> The clk_disable() in the particular case is introduced by change
> i2c: tegra: make all resource allocation through devm_*
> which is not in your branch.
> 
> Then later Prashant post the change as
> i2c: tegra: Add clk_prepare/clk_unprepare
> and it does not accounted for the above patch.
> 
> So none of your local tree will have this issue.

OK. In that case, it's best if this patch goes through the I2C tree
since that's where the code is that it's modifying. This might not be
optimal for runtime git bisection depending on the order Linus ends up
merging things, but it's probably as good as we can do without
inter-twining the I2C and Tegra trees a lot.

Re: [PATCH] i2c: tegra: use clk_disable_unprepare in place of clk_disable

[Laxman Dewangan]

On Tuesday 26 June 2012 09:58 PM, Stephen Warren wrote:
> On 06/26/2012 12:27 AM, Laxman Dewangan wrote:
>> On Monday 25 June 2012 09:25 PM, Stephen Warren wrote:
>>> On 06/25/2012 03:46 AM, Laxman Dewangan wrote:
>>>> Stephen,
>>>>
>>>> On Wednesday 20 June 2012 09:57 PM, Stephen Warren wrote:
>>>>> On 06/20/2012 10:26 AM, Stephen Warren wrote:
>>>>>> On 06/20/2012 06:56 AM, Laxman Dewangan wrote:
>>>>>>> Use clk_disable_unprepare() inplace of clk_disable().
>>>>>>> This was missed as part of moving clock enable/disable to
>>>>>>> prepare/unprepare for using the common clock framework.
>>>>> ...
>>>>>> I see no reason not to take the second patch in the series through the
>>>>>> I2C tree though.
>>>>> Uggh. Ignore that paragraph - the other patch was sent separately
>>>>> not as
>>>>> a series.
>>>> so are you taking care of this patch or do I need to send the patch
>>>> based on your tree in place of linux-next?
>>> Yes, this patch should be applied through the Tegra tree, since it will
>>> be a dependency of the common clock framework switchover there, which I
>>> hope to take place this kernel cycle.
>>>
>>> I did just attempt to apply this patch to the for-3.6/common-clk branch,
>>> but it doesn't apply:-( Could you please rebase and resend. Thanks.
>> Looked at your common_clk branch and the related code is not there.
>> The clk_disable() in the particular case is introduced by change
>> i2c: tegra: make all resource allocation through devm_*
>> which is not in your branch.
>>
>> Then later Prashant post the change as
>> i2c: tegra: Add clk_prepare/clk_unprepare
>> and it does not accounted for the above patch.
>>
>> So none of your local tree will have this issue.
> OK. In that case, it's best if this patch goes through the I2C tree
> since that's where the code is that it's modifying. This might not be
> optimal for runtime git bisection depending on the order Linus ends up
> merging things, but it's probably as good as we can do without
> inter-twining the I2C and Tegra trees a lot.


Then it can go Wolfram's tree along with other patch
  i2c: tegra: remove unused member variable.

as some of previous i2c patches are in his tree.