Re: [PATCH] i2c: tegra: I2_M_NOSTART functionality not supported in Tegra20

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 08/16/2012 01:07 AM, Laxman Dewangan wrote:
> On Tuesday 14 August 2012 10:19 PM, Stephen Warren wrote:
>> On 08/14/2012 03:19 AM, Laxman Dewangan wrote:
>>> Tegra20 i2c controller does not support the continue transfer
>>> which implements the I2C_M_NOSTART functionality of i2c
>>> protocol mangling.
>>> Removing the I2C_M_NOSTART functionality for Tegra20.
>>>
>>> Signed-off-by: Laxman Dewangan<ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> Reported-by: Stephen Warren<swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> Tested-by: Stephen Warren<swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
>>
>> Note that if I take Laxman's I2C driver clock patches through the Tegra
>> tree, and Wolfram takes this patch through the I2C tree, there will be a
>> very slight conflict, since adjacent lines are touched. However, the
>> resolution is simple and obvious, so I think that's fine.
> 
> Stephen/Wolfram,
> I have 2 more change to implement runtime PM and dynamic clock control
> for fast clock which I have planned for 3.7.
> I think it will be better if this also goes on same tree where the clock
> related change are available to avoid the merge conflict.

OK, I guess I can take all the Tegra I2C driver changes through the
Tegra tree if needed. This patch is less trivial than the last, so I
would definitely need Wolfram's ack to do so. I suppose if this ends up
conflicting with e.g. any core work in the I2C tree, I can always give
Wolfram a Tegra branch to merge in first to avoid any issues; If needed,
I'd rather wait until after rc2 or perhaps rc3 before doing that though.