[i2c] cleanup of i2c-nforce2
khali at linux-fr.org
Mon Oct 16 10:41:02 CEST 2006
On Sun, 15 Oct 2006 22:58:51 +0200, Hans-Frieder Vogt wrote:
> Am Mittwoch, 11. Oktober 2006 16:57 schrieb Jean Delvare:
> > > 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.
Nice. I have a chip at 0x69 on my laptop's SMBus, and a regular (byte)
dump returns all 0x0a. I had concluded it was a one-register chip...
But I just tested with an SMBus block read as you suggested above and
bingo, it works and I can read 10 distinct register values. Thanks for
the hint! Now the bad news is that I have no idea what chip it is, and
I'm simply not going to break into my laptop to find out.
Still I want to be pragmatic. If the chips exist but we don't have any
driver for them, I guess it means that we don't actually need to play
around with them, and as a consequence it's no big deal if we lack the
transaction type to access them on one specific SMBus implementation. I
can only take in-kernel drivers into consideration for that kind of
More information about the i2c