thanks for offer. i2c block read support for ich5 and later is now in CVS.
Best way to test bus drivers is with 'i2cdump'.
In particular to test i2c block reads, best way is with the "i" mode of i2cdump.
If it works, regular byte ("b") mode and "i" mode should have identical results
when reading from an eeprom.
For the ICH7, first we've heard of it, but not surprised it would be the chip
after ICH6 :)
I see there's nothing on developer.intel.com about it. Will there be any
changes in the SMBus controller? What is the device ID? Datasheet availability?
Whether you submit 2.4 or 2.6 patches doesn't really matter.
But with the device ID, and assurances that the SMBus part of the chip didn't change,
it's real easy.
mds
Gaston, Jason D wrote:
> Mark,
>
> I would be willing to do some testing of the i2c-i801 driver on ICH5,
> ICH6, ESB6300 and ICH7. I have access to boards/systems, but I am not
> proficient in i2c testing, other then running "sensors" and seeing the
> data. If you know of some instructions for the testing you are looking
> for, I am willing to give it a go.
>
> In addition, I will soon want to get support for ICH7 added to the
> i2c-i801 driver. Last time, when I wanted to get support for ICH6
> added, I posted a patch, adding the DID's, to the LKML and Greg KH.
> This made it into the 2.6 kernel. Perhaps I should get support added
> here first and then the base kernel?
>
> Let me know how I can help,
>
> Jason Gaston
> Jason.d.gaston at intel.com
>
>
>
>
> -----Original Message-----
> From: Mark Studebaker [mailto:mds4 at verizon.net]
> Sent: Tuesday, December 07, 2004 7:02 PM
> To: Sensors
> Subject: Re: RFC: complete rewrite of i2c-i801 for 2.6.x
>
>
>
> Mark M. Hoffman wrote:
>
>>Hi Mark:
>>
>>(CCs trimmed)
>>
>>* Mark D. Studebaker <mds4 at verizon.net> [2004-12-07 11:20:54 -0500]:
>>
>>
>>>My reading of the DB datasheet (in 2002 and now) is that it doesn't
>
> support a
>
>>>standard i2c block read. The driver functionality bitmask reflects
>
> that.
>
>>>I fixed the error message (which would only print out if a driver
>
> ignored
>
>>>the functionality mask).
>>
>>
>>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.
>
>
> correct. don't know what they were thinking.
>
>
>>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.)
>
>
> I think it is what eeproms need (you omitted 'Addr' after the second
> 'S').
> It matches what I wrote in doc/smbus-protocol in i2c
> (that is, the i2c block functions are defined to take a 'command' byte,
> matching
> what eeproms need for 'random' reads and writes).
>
> Does anybody have a ICH5/6? If so I can add support to the driver for
> testing.
>
> mds
>
>
>
>>It would be really bizarre if these two chipsets behaved differently
>
> in this
>
>>respect - I wonder if the datasheets are correct?
>>
>>[1] Well I just scanned all the other datasheets... only ICH5, ICH6,
>
> and
>
>>6300ESB appear to support the standard I2C block read. Sorry Khali.
>
> :)
>
>>Regards,
>>
>
>
>
