Re: Intel ICHx bus driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jean,

On Thu, Jan 28, 2010 at 11:53 AM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> Hi Felix,
>
> On Thu, 28 Jan 2010 11:32:28 +0200, Felix Rubinstein wrote:
>> Please explain to me how do you interpret "I2C Block Write"?
>> To my understanding it's I2C, not SMBus, transaction on the bus,
>> meaning (from Documentation/i2c/i2c-protocol)
>> S Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P
>
> No, the above isn't what people commonly call "I2C block write". What
> people commonly call "I2C block write", and which would probably be
> more appropriately called "1-byte addressing I2C block write" is (as
> documented in Documentation/i2c/i2c-protocol):
>
> S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P
>
> That being said, please note that the difference is only theoretical:
> nothing differentiates command bytes from data bytes on the wire.
>
>> on the other hand SMBus transaction looks like this:
>> S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P
>>
>> The diff is obvious, no Count (not to say Comm) bytes in I2C
>> transaction (well, it's clear, ICH9 is SMBus, not I2C bus). But what
>> does "I2C Block Write" then means?
>
> See "I2C block write" as functionally equivalent to "SMBus block write"
> but for non-SMBus devices such as I2C EEPROMs. The goal is the same
> (write a series of bytes to the device at a given sub-address) but the
> on-the-wire format is different (size goes on the wire for SMBus, not
> for I2C.)
>
> While "I2C block write" isn't part of the SMBus specification, we have
> implemented it in a similar way, simply because many SMBus controllers
> implement that transaction type.
>
>> > I have no idea what you mean with "I2C's multi-block". Please be
>> > specific.
>>
>> S Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P
>
> OK, that's a straight I2C write of arbitrary length.
>
>> Does  i2c-i801.c  support the following kind of transactions?
>> S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P
>> (note, no count byte on the bus, taken from Documentation/i2c/smbus-protocol)
>
> Yes, it does. Use i2c_smbus_write_i2c_block_data(). And if you don't
> need the command byte, you can abuse it by passing the first data byte
> as the command.
>
>> looking at i801_block_transaction_by_block:
>>
>>         if (read_write == I2C_SMBUS_WRITE) {
>>                 len = data->block[0];
>>                 outb_p(len, SMBHSTDAT0);
>>                 for (i = 0; i < len; i++)
>>                         outb_p(data->block[i+1], SMBBLKDAT);
>>         }
>>
>> Meaning len is put on the bus.
>
> No, the above piece of code doesn't imply this. The length is written
> to one register of the SMBus controller. It doesn't imply in any way
> that the controller will push that value on the wire. In the case of
> I2C block transactions, it does not.
How exactly the len is not pushed on the wire?
In i801_transaction, the outb_p(xact | I801_START, SMBHSTCNT);
where xact has I801_BLOCK_DATA (101b) turned on.

here is an excerpt from ICH9 datasheet:
101 = Block: This command uses the transmit slave address, command, DATA0
registers, and the Block Data Byte register. For block write, the
count is stored
in the DATA0 register and indicates how many bytes of data will be transferred.

But DATA0 was assigned a value of len before that by means of the
above code snipet.
Please shed the light why SMBus controller will not push the len byte
on the wire if DATA0 equals to len and Block SMB_CMD (as defined in
the datasheet on page 761) equals to 101b (I801_BLOCK_DATA).


Thanks,
Felix R.


>
> BTW, the ICH9 datasheet is public, so you can easily check what exactly
> the controller does for each transaction type.
>
> --
> Jean Delvare
> http://khali.linux-fr.org/wishlist.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux