It's a lost cause, I think. The controller is going to use the first byte for the length the slave intends to send. The LAST_BYTE bit means the SW telling the master it wants to stop. If the first byte is > 32 or doesn't match the actual message length I think the results are likely to be bad. Jean Delvare wrote: > Hi Mark, > > >>Interesting. It looks like that datasheet only shows this: >> >> S Addr Wr [A] Comm [A] D0 [A] D1 [A] S (read bytes...) >> >>I agree that's not like any transaction we support. > > > True. Not only that but it seems that this function is broken at least in > the ICH3-M (which I have). The specification update from Intel [1] says > so. > > >>OTOH, the ICH5 [1] datasheet shows this: >> >> S Addr Wr [A] D1 [A] S (read bytes...) >> >>That's exactly the transfer protocol that eeproms need, right? (That's why >>I mentioned to Khali by IRC last weekend that I thought it should be >>possible.) > > > True again. > > >>It would be really bizarre if these two chipsets behaved differently in >>this respect - I wonder if the datasheets are correct? > > > I think they are. Intel are very serious with datasheets. I believe they > implemented a useless function, realized that and simply changed it in > the newer revisions of the ICH. BTW it would certainly be worth looking > at the revision numbers of our chips. The revision is shown by lspci > (aming others). Mine is 01. I would expect a different value for the > chips with the new I2C block read function. If I'm right, that would be > a convenient detection method. > > I will not try the weird I2C block read on my system since it really > starts like a write command and I wouldn't want to trash my eeproms > accidentally. > > >>[1] Well I just scanned all the other datasheets... only ICH5, ICH6, and >>6300ESB appear to support the standard I2C block read. Sorry Khali. :) > > > Yes, it looks so. I guess I'll have to change my laptop for an > ICH6-based one then ;) > > However, what I had in mind was NOT to use that weird function but to > hi-jack the SMBus block read command. Unless I am mistaken, the only > difference between SMBus and I2C block reads is that the former has an > additional leading (read) byte for the length while the latter doesn't. > My plan was to implement I2C block reads using the SMBus block read. All > I'd need to do is copy the supposed length byte as the first data byte > and shift all other data bytes by one position. Sounds simple... except > that it doesn't seem to work. Or, more precisely, sometimes it works > and sometimes is doesn't. Seems to depend on the first byte read. I > suppose that the ICH3-M trusts this byte more than the LAST_BYTE bit > (the specification update confirms that this is the case for the weird > I2C block read function, making it useless as I said earlier). I tried > to overwrite the byte length with 32 after the first transfer of the > block but it didn't seem to help. Also, I see no relation between the > value of the first byte and the point at which the block read dies on a > timeout, although this is perfectly reproducible. > > I'll investigate again this evening but with little hope. And anyway > this sounds like a trick we might not want to implement in the released > driver even if it somewhat works, especially since I2C block reads are > really only a bonus for EEPROMs, not a vital feature for hardware > monitoring. > > [1] http://www.intel.com/design/chipsets/specupdt/290718.htm > > Thanks, > -- > Jean Delvare > >
