H. Nikolaus Schaller
hns at goldelico.com
Sun Feb 28 18:27:36 CET 2021
> Am 22.02.2021 um 00:48 schrieb Paul Boddie <paul at boddie.org.uk>:
> On Sunday, 21 February 2021 17:42:38 CET H. Nikolaus Schaller wrote:
>> So maybe time gives us another idea.
>> Or we have to go back to a non-IRQ driver model to become able to fix the
>> remaining issues and upstream everything soon. Then we get a chance for
>> inclusion into v5.13.
>> So let's shift priorities and come back to this IRQ based driver later.
> Yes, I think that it would almost be better to just have the driver
> periodically check the bus state. Is it possible to schedule some kind of
> kernel task to wake up every so many microseconds during a transaction?
> Given that I2C uses a fairly flexible protocol with it potentially being
> possible to slow communications to a fairly low speed (maybe even suspending
> them if I remember correctly), that might be a satisfactory approach.
> Something else to look at, I guess.
I have started again to do some tests...
You may have noted from source code that I have changed the driver
to use readb_poll_timeout_atomic() for polling the status registers
What I just found out is that this iopoll lib uses internally ktime_get()
and here we are back to the clocksource issue. We know that the
clocksource=jiffies works but only has a very coarse resolution while
the ingenic-timer fails.
So I am not sure if I can really fix the i2c before we have found
the clocksource problem. This had been the idea to make i2c work and
then POST and ask others for help for the ingenic-timer.
But this dependency means we have to repair the timer first...
Still I have no idea how to debug this. I think the register values
are correct (we have checked multiple times), having 16 bits or 32
bit OST1 makes no difference.
So it can either be a timer readout problem (async read may return
wrong bits while the timer change ripples through the counter) or
similar. We had tried before but maybe not hard enough...
More information about the Letux-kernel