m7621 i2c read failure

[Jan Breuer]

On 16. 2. 2023 16:21, Peter Naulls wrote:
>
> On 2/15/23 13:31, Peter Naulls wrote:
> >
> > I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
> >
> x00

Can you please provide info about the exact SoC and hardware you are using?

> >
> > In particular, for the first read attempt, the value is always the first
> > value sent as part of the last write. i.e, 3 in this case. After, that,
> > it's always 0 (the correct answer ought to be 0xf).
> >

Without a logic analyzer/scope, it would be hard to tell what's
happening. The problem can be deeper and not in the code itself.

> So I pulled out the old vendor-supplied driver and dropped it in the current
> kernel, where it compiled with no changes.
>
> It works for reads, after a fashion.  It will read the correct value a few
> times, and then 0 after.  The state can be "reset" by doing a write, and then
> it works again.

I'm a little bit lost here. It seems to me, that also the vendor
driver does not work all the time for you and you must "reset"
something, but maybe I just misunderstood this.

Can you please describe the exact protocol you would like to implement
in terms of I2C and what device is on the other side?

> Pursing  getting the current driver working here seems most prudent - clearly
> the most recent changes were made for a reason, but I'm not sure what to do next.

The old driver does not support clock stretching and messages were
limited to 32 bytes. It did not support repeated start correctly. It
ignores ACK/NAK so i2cdetect did not work, etc.
So if the communication is broken "the right way" on the hardware
level, the old driver can behave differently.