On Tuesday, September 09, 2014 at 05:05:24 PM, Janusz Użycki wrote: [...] > >> If it is too fast a slave has possibility to inform by setting SCL low. > > > > Do you mean clock stretching ? > > Yes, I didn't notice it is the same. OK > >> However I haven't seen any driver which supports the method. > >> > >>>> |Checking CTRL1_NO_SLAVE_ACK_IRQ |bit for SELECT command will increase > >>>> > >>>> code size only > >>>> without special profit. Current PIO implementation also gathers all > >>>> errors together and reads them on the end by > >>>> mxs_i2c_pio_check_error_state(). Probably > >>>> mxs_i2c_pio_check_error_state() call or > >>>> enabling interrupt masks for PIO could be better than > >>>> direct |CTRL1_NO_SLAVE_ACK_IRQ |bit checking for clear code. > >>>> It also could support multimaster for PIO (MASTER_LOSS). > >>> > >>> Actually, the PIO is explicitly IRQ-less and is used only for > >>> transferring very short amounts of data. > >> > >> Yes but error service could be more common probably. > > > > Feel free to prepare a patch please! > > On the moment the fix is enough for me. I did need i2cdetect to work. You should be really careful here. Please note that the I2C is not a PnP bus and probing the I2C might have adverse effect on various devices attached to the bus. > I looked on 2.6.35 FSL BSP. There both DMA and PIO mode use status > interrupt and cmd_complete. It was changed to speed up? Yes, esp. in short transfers. Best regards, Marek Vasut -- 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