Hi Peter, On Tue, 16 Apr 2019 19:45:10 +0000, Peter Rosin wrote: > If there is some other device responding to 0x36/0x37, then it didn't > respond in the first (elided) dump with no ee1004 driver bound. So, that > seems unlikely. No? > > For reference the elided dump I referred to was: > > > [root:/sys/bus/i2c/devices] # i2cdetect 2 > > WARNING! This program can confuse your I2C bus, cause data loss and worse! > > I will probe file /dev/i2c-2. > > I will probe address range 0x03-0x77. > > Continue? [Y/n] y > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00: -- -- -- -- -- 08 -- -- -- -- -- -- -- > > 10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- -- -- -- > > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 30: 30 31 -- -- 34 35 -- -- -- -- -- -- -- -- -- -- > > 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- > > 50: 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- > > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 70: -- -- -- -- -- -- -- -- > > But why is there no response for those addresses when there is no > driver bound? Will they only ack writes or something? I don't know > anything about these DDR4 SPDs... For range 0x30-0x37, i2cdetect uses read commands for probing. 0x37 is a write-only address for the EE1004 standard, so it doesn't have to ack reads. 0x36 is special, as a read command it returns the currently selected page, but uses the ack to answer (page 0 or page 1) instead of acking and answering in an actual payload. If you ask me it is VERY BAD design, and it is very sad that whoever came up with that part of the EE1004 standard had too little experience to realize that saving a few bytes for this command was really not worth the clumsy design. The ack bit has a meaning and should never be abused like that. I observe the same on my working system: i2cdetect does not reveal 0x36 and 0x37. "i2cget" on these address fails too, unless you provide a register address, because then a combined write/read message is generated, and as it starts with a write, the EE1004-compliant SPD EEPROMs may ack it (but don't have to - they could in theory ack the first part and then nack the second part): # i2cget 4 0x36 Error: Read failed # i2cget 4 0x36 0x00 0xff The ee1004 driver on the other hand emits a simple write command to select the page, and that should always get acked. It is for me but not for Dreamcat4. As this is a write command AND SPD protection is active for him, I can only suspect that SPD protection is not implemented correctly and also blocks writes to the 0x30-0x37 address range despite what the datasheet says. But at this point we have no proof that this is the case and I don't want to blame Intel engineers without a proof. Note that the SPD protection feature of the Intel SMBus controller is essentially pointless with DDR4 anyway, as the EE1004 standard comes with its own SPD page protection logic. -- Jean Delvare SUSE L3 Support
