[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel

[Paul Boddie]

On Saturday, 26 December 2020 21:54:04 CET H. Nikolaus Schaller wrote:
> > Am 26.12.2020 um 17:38 schrieb Paul Boddie <paul at boddie.org.uk>:
> > 
> > I did wonder whether the transmission of the last byte might need to be
> > accompanied by the stop condition,
> 
> Yes, it should or well, the STOP must come after the last byte. There is
> code in my irq handler.

Right. The stop condition is immediate, then. I can't remember if the JZ4780 
couples the stop condition with the final byte or whether it also performs an 
immediate stop. I just thought that use of the former mechanism might explain 
any lingering bus activity.

> But it now works with interrupts always enabled. So it looks as if I have
> found the right triggers to end an interrupt request...

I suppose that there is some uncertainty about what will cause interrupt 
conditions. I would have to look at the manual again, but I don't think it is 
very thorough about that.

> So I think I will have some more minor changes and then merge it into
> letux-5.10.3 for more public testing. This will become available on the
> goldelico git soon.
> 
> What is still strange is the system time. First of all, "date" now runs much
> slower than real time. I think this has changed after I hot the LCD create
> some /dev/fb0 and X11 running. Needs more time to verify this assumed
> dependency.
> 
> And there are really strange values printed to dmesg. The sequence is
> correct, but the time jumps back and forth?
> 
> Well, it may be as simple as the time_val tv_usec having random and negative
> values...

I just thought that this is what happens in Linux logging now, with logging 
possibly being done in parallel (maybe systemd even gets involved).

[...]

> I am not at all sure but it may have started with the latest TCU/CGU update?

No, it was in your earlier logs, too. I had to sort one of them to make sense 
of it.

> PS: I just found that after removing all my printk() the i2c driver starts
> to fail. I need one printing the state and the status register :(
> So there is another timing issue to be fixed before publishing it...

I guess you added spinlock usage back to whichever function it was where you 
had been relying on interrupts being disabled. In any case, I hope you can 
figure it out.

Paul