[i2c] cleanup of i2c-nforce2
hfvogt at gmx.net
Sun Oct 15 22:58:51 CEST 2006
Am Mittwoch, 11. Oktober 2006 16:57 schrieb Jean Delvare:
> Hi Hans-Frieder,
> > OK, but now here are some of my findings: the block data transfer seems not to
> > work for 32 bytes. There is always the same effect: the SMBus blocks and I
> > found no way to reset it or wake it up again. I confirmed this finding on an
> > nForce2 and an nForce4 board.
> > However, the block data transfer works for up to 31 bytes (only read-tested
> > though, tested on some hardware-monitoring chips, on SPD-EEPROMs and on a
> > clock chip).
> Same observed here on nForce2 + SPD EEPROM.
> > I understand that the block data transfer (if supported) is expected to
> > support 32 byte transfers, and supporting 31 byte transfers opposes that
> > rule.
> That's the theory, yes. In practice, I guess it's OK if an adapter
> doesn't support certain cases, as long as the chip drivers are clearly
> notified and can act in consequence.
> > On the other side, there are devices like some (all?) clock chips that are
> > only accessible via block data mode, and for them the availability of block
> > data transfers is crucial.
> Which chips? Are they really using SMBus block transactions and not I2C
> block transactions? The only in-tree user of i2c_smbus_write_block_data()
> right now is a PowerPC sound driver (daca). i2c_smbus_read_block_data()
> had no user and was removed from the kernel tree. The only other driver
> I am aware of which makes use of the SMBus block transactions is the
> lm93 hardware monitoring driver but it's not merged yet - and it can use
> other transaction types if block transactions aren't available.
I am not talking about drivers included in the kernel (or part of lm_sensors). On my K8N4-E board (nForce 4X)
there is an i2c device with Address 0x6a, which I have not identified yet. Because the address is near to 0x69
I assumed it to be a clock chip, but I may be wrong. On that board there is a chip "ICS CA431523", the manufacturer of
which is known for its clock chips, but I have not found any description of that chip yet, so I am not sure.
This I2C device returns 0x07 for every command byte when using byte data transfer, but with block data transfer I
get the 7 value bytes. Therefore this is one example of a chip that needs block data transfer to get/set all the data.
> > In general I think it is better to support
> > something partially than not at all and therefore I have come up with another
> > patch, that should contain the changes below, but keeps the block data mode
> > for up to 31 bytes.
> > I will send that patch in a following mail to reduce the length of this mail.
> > If you disagree with the approach of a partial support of block data transfers
> > then of course I would also be happy to just sign off the patch below.
> See my comments there.
OK, I will answer to these comments in a reply to the other mail.
Hans-Frieder Vogt e-mail: hfvogt <at> arcor .dot. de
hfvogt <at> gmx .dot. net
More information about the i2c