Dear Torsten Fleischer,
> Hi Marek,
>
> > +
> > + mxs_i2c_pio_trigger_write_cmd(i2c,
> > + start | MXS_I2C_CTRL0_MASTER_MODE |
> > + MXS_I2C_CTRL0_DIRECTION |
> > + MXS_I2C_CTRL0_XFER_COUNT(xlen), data);
> > +
> > + /* The START condition is sent only once. */
> > + start &= ~MXS_I2C_CTRL0_PRE_SEND_START;
> > +
> > + /* Wait for the end of the transfer. */
> > + ret = mxs_i2c_pio_wait_xfer_end(i2c);
> > + if (ret) {
> > + dev_err(i2c->dev,
> > + "PIO: Failed to finish WRITE cmd!\n");
> > + break;
> > + }
> > +
> > + /* Check NAK here ? */
>
> checking for the NAK at this point is really necessary.
>
> I've tested the patches by writing to the EEPROM using the at24 driver.
> If the data to write cross the EEPROM's page boundary then the at24 driver
> splits the I2C write commands.
>
> After the first I2C write command is done the at24 driver immediately tries
> to send the next I2C write command. Normally the EEPROM signals a NAK,
> because the previous write operation is internally still in progress. The
> NAK will be handled by the at24 driver. It later retries the I2C write
> command.
>
> But if the the EEPROM signals a NAK and the I2C write command has more than
> 3 and less than 7 bytes then the error "PIO: Failed to finish WRITE cmd!"
> appears, because the loop is not exited due to the NAK.
Ok, so we check
HW_I2C_STAT :: GOT_A_NAK bit at the end of the loop and if it's set, we "goto
cleanup" with ret = -ENXIO . How does it sound to you? Wolfram, is -ENXIO the
right one here?
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
