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 n
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 ca
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, thank
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
On 2/15/23 13:31, Peter Naulls wrote:
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
x00
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
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
In my vendor kernel:
[2.243263] i2c-mt7621 1e000900.i2c: clock 100KHz, re-start not support
Which is this driver:
* drivers/i2c/busses/i2c-mt7621.c
*
* Copyright (C) 2013 Steven Liu
* Copyright (C) 2016 Micha
