Hi, thanks for the patch.
> See updated patch on ml.
This raises two concerns for me:
[1]. Clients must split an I2C transaction of one read into two,
releasing the lock between them.
They might be interrupted (for example) by other read transaction
to another tuner, (or by other, un-related I2C to the demod),
and get wrong result.
ex.
1. write a read command to tuner@<I2C addr XX>
40 03 00 30 fe 00 01 00 >>> (XX << 1) | 1
2. write another read command to tuner@<I2C addr YY>
40 03 00 30 fe 00 01 00 >>> (YY << 1) | 1
3. read the result from tuner@XX
C0 02 00 30 00 01 01 00 <<< ??? # which one?
4. read the result from tuner@YY
C0 02 00 30 00 01 01 00 <<< ??? # right/valid answer?
[2]. There are (fairly common) use-cases of 2-Bytes, non-short writing,
which is not seemed to be supported by this patch.
ex. tuner read log from my previous post. (no tuner register)
40 03 00 30 fe 00 01 00 >>> c1 # addr:0x18, buf = {0xfe, 0xc1}
And friio itself also uses those 2-Bytes non-short msgs in its reset,
to control some peripherals other than demod/tuners.
ex. gl861.c::friio_reset()::line 422
40 03 00 12 03 00 01 00 >>> 80 # addr:0x09, buf = {0x03, 0x80}
But It may be possible to get around all these concerns.
For [1], demod usually does not share tuner I2C access like this.
For example, tc90522 supports multiple tuner input but has separate
demod blocks for each input with distinct I2C address.
For [2], 'short write' version might work still. (not sure/verified)
(40 02 c1 30 fe 00 00 00 >>>)
And friio can use gl861_ctrl_msg() directly instead.
So, anyway I will try to re-structure i2c in friio
and test/verify it.
Regards,
Akihiro
