Me again... On Wed, 18 May 2016 14:05:08 +0200, Jean Delvare wrote: > * The I2C Block Read transaction must set this bit to 0 (write) even if > it is a read transaction. This is explicitly mentioned in the > datasheet (page 215, "For I2C Read command, the value written into > bit 0 of the Transmit Slave Address Register (SMB I/O register, > offset 04h) needs to be 0.") > (...) > Mika/Jarkko, is there any chance to get your hardware people involved? > I wonder if there is any workaround to this issue? Any chance to get > this fixed in future chipsets? Not sure about Send Byte but the write > protection should definitely not block I2C Block Read transactions. > > For now we need to come up with a software workaround. I can think of 3 > approaches: > (...) > If anyone can think of any better solution, please let me know. 4* It could be that the sentence in the datasheet that claims the slave address register bit 0 must be set to 0 (write) for I2C Block Reads is a left-over from previous incarnations of the chipset, and this no longer holds true today. Out of curiosity I tried setting bit 0 to 1 (as it should normally be for a read) and it seems to work just fine. And then it is no longer affected by the SPD write protection mechanism. However I don't know if there is any problem or negative side effect I may have missed. Mika/Jarkko, can you check with your hardware guys if that statement on page 215 still holds for 8-Series/C220 and later? Thanks, -- Jean Delvare SUSE L3 Support -- 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
