m7621 i2c read failure
Peter Naulls
peter at chocky.org
Thu Feb 16 12:37:44 PST 2023
On 2/16/23 13:59, Jan Breuer wrote:
> 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?
Hi Jan, thanks for responding. I probably cut too much of the original
message, but it's an mt7621 board, made by Atel. Presumably heavily based
upon the original reference board, but I couldn't say for sure. I don't
believe it's hugely different to any of the other mt7621 systems; certainly
the dts only varies in things like GPIO location and flash layout etc.
> 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.
I think the "reset" was a red herring due to a daemon I had running which
also queried the i2c bus (wrongly). The i2c code on the MCU does seem a
bit fragile, but in any case appears to be now working as expected with the
vendor/old kernel driver.
The vendor driver appears to be also be the driver from OpenWrt 18.02ish
which is from before your changes. I suspect it doesn't have any
changes from the vendor, but I would have to do some careful checking to
make entirely sure.
> Can you please describe the exact protocol you would like to implement
> in terms of I2C and what device is on the other side?
The other end is an MCU with a software setup i2c protocol - it's
pretty simple, but here's for example some queries to get the firmware version
etc that I had posted originally:
------------------------
Writes work correctly. This for example sets LEDs via i2c (handled by the MCU
and its GPIOs - I control this code too):
# i2ctransfer -y 0 w1 at 0x50 0x43 w3 3 2 1
Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979880] i2c i2c-0: ioctl,
cmd=0x705, arg=0x7fb736f0
Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979927] i2c i2c-0: ioctl,
cmd=0x703, arg=0x50
Wed Feb 15 18:23:01 2023 kern.debug kernel: [ 307.979954] i2c i2c-0: ioctl,
cmd=0x707, arg=0x7fb736f0
# i2ctransfer -y 0 w1 at 0x50 1 r1
Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921389] i2c i2c-0: ioctl,
cmd=0x705, arg=0x7febfd60
Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921437] i2c i2c-0: ioctl,
cmd=0x703, arg=0x50
Wed Feb 15 18:23:04 2023 kern.debug kernel: [ 310.921463] i2c i2c-0: ioctl,
cmd=0x707, arg=0x7febfd60
0x03
# i2ctransfer -y 0 w1 at 0x50 1 r1
Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714856] i2c i2c-0: ioctl,
cmd=0x705, arg=0x7feaf3e0
Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714903] i2c i2c-0: ioctl,
cmd=0x703, arg=0x50
Wed Feb 15 18:23:06 2023 kern.debug kernel: [ 312.714928] i2c i2c-0: ioctl,
cmd=0x707, arg=0x7feaf3e0
0x00
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).
The original post is here:
http://lists.openwrt.org/pipermail/openwrt-devel/2023-February/040509.html
Thanks!
More information about the openwrt-devel
mailing list