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@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@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@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!
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
