Re: [PATCH v2] i2c: tegra: Add delay before reset the controller

[Shubhrajyoti Datta]

Hi Alok,
Few / doubts /questions.


On Mon, Apr 2, 2012 at 11:29 AM, Alok Chauhan <alokc@xxxxxxxxxx> wrote:
> Stephen,
>
> I've updated the commit message and comment in the code as per your suggestion. Tegra I2C controller doesn't have idle bit so delay is required before reset the controller in case of NACK error.  This delay is calculated purely based on clock period of that particular i2c bus and not passed as hardcoded value. I2C SCL clock-stretching won't affect this calculated delay.

Why is it clock cycle dependent?

Is it possible to poll if the stop is sent by controller ?

>
> Thanks
> Alok
>
>
> -----Original Message-----
> From: Alok Chauhan [mailto:alokc@xxxxxxxxxx]
> Sent: Monday, April 02, 2012 11:23 AM
> To: swarren@xxxxxxxxxxxxx; khali@xxxxxxxxxxxx; ben-linux@xxxxxxxxx; w.sang@xxxxxxxxxxxxxx; Stephen Warren; olof@xxxxxxxxx; bones@xxxxxxxxxxxx; omaplinuxkernel@xxxxxxxxx; ccross@xxxxxxxxxxx; Laxman Dewangan; linux-tegra@xxxxxxxxxxxxxxx; linux-i2c@xxxxxxxxxxxxxxx; dgreid@xxxxxxxxxxxx
> Cc: Alok Chauhan; linux-kernel@xxxxxxxxxxxxxxx
> Subject: [PATCH v2] i2c: tegra: Add delay before reset the controller
>
> NACK interrupt generated before I2C controller generates the STOP condition on bus. In Software, because of this reset of controller is happening before I2C controller could complete STOP condition. So wait for some time before resetting the controller so that STOP condition has delivered properly on bus.
>
> Added delay of 2 clock period
How did you calculate the 2 clock cycles?


before reset the controller in case of NACK error.
>
> Signed-off-by: Alok Chauhan <alokc@xxxxxxxxxx>
> ---
> Added the more descriptive commit message about issue in case of NACK error condition. Changed the comment in code also
>
>  drivers/i2c/busses/i2c-tegra.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/