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

[Paul Boddie]

On Friday, 27 November 2020 04:13:45 CET Lubomir Rintel wrote:
> On Thu, Nov 26, 2020 at 11:22:56PM +0100, Paul Boddie wrote:
> > 
> > One thing that may be different, at least when you can monitor the log, is
> > the following line:
> >
> >   [    0.000000] timer_probe: no matching timers found
> > 
> > Then again, searching for any reports about this leaves me unconvinced
> > that it might be a problem. In Lubomir's log output, the next line is
> > this...
> > 
> >   [    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns,
> >   wraps every 21474836475000000ns
> > 
> > Maybe this indicates that the lack of timer assignments won't be a problem
> > because scheduling is done using other timers.
> 
> Thank you. With a little more patching I got a more respectable panic
> now. I'll follow up with the patches.
> 
> The configuration [1] and dmesg [2] are here:
> 
> [1] https://people.freedesktop.org/~lkundrak/jz4730/config-20201127.txt
> [2] https://people.freedesktop.org/~lkundrak/jz4730/dmesg-20201127.txt

I now see the following instead of the above:

[    0.000000] clocksource: ingenic-timer: mask: 0xffff max_cycles: 0xffff, 
max_idle_ns: 7910990 ns
[    0.000054] sched_clock: 16 bits at 3686kHz, resolution 271ns, wraps every 
8888753ns

This is more like what I would expect if the TCU were providing a timer for 
scheduling, which is what I imagined my patch would achieve. This was just 
guesswork from me, though.

> 
> 1.) I'm using clk_ignore_unused because disabling of the dma clock seems
>     to make the cpu grind to a halt (not even jtag works at that point).
>     Also, if dma clock is kept enabled, disabling of some other clock
>     (no idea which one yet) makes things go very slow.
> 
> 2.) I'm using clocksource=jiffies because switch to ingenic-timer makes
>     the scheduler clock poll callback not fire and thus the clock ends
>     up loop aroud in 65535 ticks.

Yes, the kernel is reporting that the TCU only provides a 16-bit timer, but 
looking at my patches for Fiasco, I have the counter as a 32-bit register, and 
this corresponds to the header files from the legacy kernel. Recall that this 
TCU support for the JZ4730 actually uses the 3-channel OST (operating system 
timer), though.

Meanwhile, the JZ4740 has no OST but an 8-channel TCU, but the counters are 
all 16-bit registers. So, we might usefully need to change the TCU driver to 
permit 32-bit counters or just use the OST support in the TCU driver instead 
(although that appears to treat the OST as a singular timer like the WDT, not 
as something with multiple channels).

> 3.) The scheduler clock poll doesn't probably run often enough because
>     the clock seems overflow and go backwards sometimes.

Perhaps that could be a result of the 32-bit counter being treated as a 16-bit 
counter.

> 4.) Some errors in LCD and DMA DT notes are now apparent and the MMC
>     doesn't work. I guess there might be more driver issues.
> 
> I'll be looking into above as time permits, but would be thankful for
> hints.

I can probably look a bit at the LCD driver in the coming days. I hope that my 
other remarks are helpful, however.

Paul