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.
Best regards,
Torsten Fleischer
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
