m7621 i2c read failure

[Peter Naulls]

On 2/20/23 09:48, Peter Naulls wrote:
> On 2/16/23 17:17, Alexander Papazoglou wrote:
> 
>> My first guess would be that your microcontroller code doesn't handle repeated 
>> starts properly. All of the i2ctransfer commands you've shown involve at least 
>> one repeated start with the new driver but perhaps not with the old one. To 
>> verify, you can break them up in such a way that no repeated starts are issued.
>>
>> Since you control the microcontroller, you can add diagnostic code (printfs?) 
>> to see what I2C reads/writes are being issued by the MT7621.
>>
> 

I've now spent some time with this, and I think your theory is correct based 
upon what little debug I can get out of the MCU - inconsistent use of break
points, incomplete variable display etc. Sometimes I see it get into loops
from which it doesn't recover.

I did spend a while looking at the two versions of the driver, but I wasn't
sure entirely how to break it up to not do the repeated starts - I'm sure
it's obvious, but I guess you gotta know.

My colleague pointed out that we have an almost identical setup on a
prior board - same CPU, same kernel - the difference there is a
different MCU.  Sometimes that setup returns top-bit set and bogus values
from its (probably more sophisticated I2c setup, but it's sufficiently
infrequent that we can work around it). In any case, there probably
isn't any fundamental problem with the Linux setup - the old driver just
happened to be naive and lucky enough to mostly work most of the time.

The Sinomcu code is  copyright them, but freely available for download from 
their website, and I wasn't subject to any NDAs or anything regarding this:

https://www-sinomcu-com.translate.goog/product/detail?id=80&_x_tr_sl=zh-CN&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=sc

I could probably paste the relevant short function here 
(i2c_master_write_slave), but because this is an OSS project, I'd
rather err on the side of caution and not do that - I'll email
it to anyone who asks.