Trent Piepho wrote:
> On Sun, 20 May 2007, Manu Abraham wrote:
>> Don't you think that the STV0297 (the obvious case that i looked at was
>> b2c2 flexcop) B2C2 cablestar.
>> In this case looking at flexcop-i2c.c flexcop_i2c_read4(foobar)
>>
>> if ((ret = flexcop_i2c_operation(fc, &r100)) != 0) {
>> /* The cablestar needs a different kind of i2c_transfer (does not
>> * support "Repeat Start");
>> * wait for the ACK failure,
>> * and do a subsequent read with the Bit 30 enabled
>> */
>>
>> ..
>>
>> Now, to me it looks a rather bit strange: the reason being the transfer
>> here just needs a stop bit in between which exactly is a very normal
>> transaction with START/STOP bits, just that the whole transaction is
>> looped for 4 bytes.
>>
>> This mode is exactly a BYTE mode which is a loop for 4 bytes and not a
>> PAGE mode transfer, what we normally have under Linux.
>>
>> So what i think would be better, probably would be like this:
>>
>> * pass a flag to master_xfer to define the mode of operation say a flag
>> "PAGE_MODE" or "BYTE_MODE" [1] Page 9
>> now master_xfer looks for the FOO_MODE flag and decides what transfer to
>> be done.
>> [1] http://www.tranzistoare.ro/datasheets/150/501070_DS.pdf
>
> The page mode vs byte mode from that eeprom datasheet is just something
> internal to the way the eeprom's write latches work.
That is the address sequencer, one might call it that. Okay let's look at
it another way.
> It has nothing to do with the I2C protocol.
If so, why does a Master need to set those bits specific for PAGE/Byte
mode ? Okay looking at it from another angle. I am a user .. i need to
explicitly define whether i need to use PAGE mode or not. How will i be
able to do it ? That would be the better way of putting the same question.
> The I2C transaction for a multi-byte write and page
> mode write is exactly the same.
Ah, sorry for that error (though not relevant for the stv0297), the
read/write sequences are the same, but there is a small twist to it.
The difference being some devices do not have an internal address
sequencer and some do have.
For the ones that do have it page_mode can be used. For the ones without
the address sequencer, the page_mode of access cannot be used.
> In mutli-byte mode, the write is limited
> to 4 bytes and can start at any address. In page mode the write can be up
> to 8 bytes, but must start at an 8-byte aligned address.
* from one of the Conexant datasheets ..
3.3.4 Page-Mode limitations
Even though multiple EEPROMs can be supported, there is a restriction
that a pagemode
access can not occur across separate devices. Also, some EEPROMs larger than
256 bytes may not support page-mode accesses across 256 byte internal
boundaries.
For example: The 24C04 contains two pages and does not support the page-mode
writes across the page boundary. Using a 24C04 will work if writing to
it, is limited to
word resolution around the page boundary. Byte resolution may not be
used for
reading or writing when crossing the IC chip-size boundaries. These
limitations are
introduced by using the page-mode word-write and dword sequential read
operations
available to speed up access.
* from another place ..
I2C Compatible Direct
A dword written to this address range will cause the hardware I2C
compatible interface to write the 4 bytes
beginning at the I2C compatible chip address from address bits [14:8]
and sub address from address
bits [7:0]. A dword read from this address range will cause the hardware
I2C compatible to read the 4
bytes beginning at the I2C compatible chip address from address bits
[14:8] and sub address from
address bits [7:0].
To make it simple:
What i understand from a couple of docs, PAGE MODE directly uses the
Hardware Address sequencer, whereas the other does not.
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
