Re: [2/5] i2c: davinci: query STP always when NACK is received

From: Uwe Kleine-König
Date: Thu Nov 20 2014 - 17:20:07 EST


On Thu, Nov 20, 2014 at 12:03:05PM +0200, Grygorii Strashko wrote:
> According to I2C specification the NACK should be handled as folowing:

> "When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
> Acknowledge signal. The master can then gene rate either a STOP condition to
s/gene rate/generate/

> abort the transfer, or a repeated START condition to start a new transfer."
> []
The link is nice, but pointing out that this is the i2c spec would be

> The same is recomened by TI I2C wiki:

If the specification tells what to do, there is no need to further
support your claim.

> Currently, the Davinci I2C driver interrupts I2C trunsfer in case of NACK, but

> It queries Stop condition DAVINCI_I2C_MDR_REG.STP=1 only if NACK has been received

> during the last message transmitting/recieving.
s/transmitting/transmitted/; s/recieving/received/

I think I don't understand this sentence even with the typos corrected.
Do you want to say:

Currently the Davinci i2c driver interrupts the transfer on receipt of a
NACK but fails to send a STOP in some situations and so makes the bus

> This may lead to Bus stuck in "Bus Busy" until I2C IP reset (idle/enable) if
> during SMBus reading transaction the first I2C message is NACKed.
Did you hit this problem, or is this a theoretical issue?

Assuming this is a candidate for stable, adding a Fixes:-footer would be

> Hence, fix it by querying Stop condition (STP) always when NACK is received.
> This patch fixes Davinci I2C in the same way it was done for OMAP I2C
> commit cda2109a26eb ("i2c: omap: query STP always when NACK is received").
> More info can be found at:
I'd drop this "more info" paragraph.

> CC: Sekhar Nori <nsekhar@xxxxxx>
> CC: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>
> CC: Santosh Shilimkar <ssantosh@xxxxxxxxxx>
> CC: Murali Karicheri <m-karicheri2@xxxxxx>
> Reported-by: Hein Tibosch <hein_tibosch@xxxxxxxx>
Is this Reported-by tag reused from the omap issue?

> Signed-off-by: Grygorii Strashko <grygorii.strashko@xxxxxx>
> ---
> drivers/i2c/busses/i2c-davinci.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
> index 9bbfb8f..2cef115 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -411,11 +411,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
> if (dev->cmd_err & DAVINCI_I2C_STR_NACK) {
> if (msg->flags & I2C_M_IGNORE_NAK)
> return msg->len;
> - if (stop) {
> - w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
> - davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
> - }
> + w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
> + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
I think this is a good change, but I wonder if the handling of
I2C_M_IGNORE_NAK is correct here. If the controller reports a NACK say
for the 2nd byte of a 5-byte-message, the transfer supposed to
continue, right? (Hmm, maybe the framework handle this and restarts the
transfer with I2C_M_NOSTART but the davinci driver doesn't seem to
handle this flag?)

Best regards

> return -EREMOTEIO;
> }
> return -EIO;

Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | |
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at