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. It has nothing to do
with the I2C protocol. The I2C transaction for a multi-byte write and page
mode write is exactly the same. 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.
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
