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

[H. Nikolaus Schaller]

Good news:

I think I have managed to get the new i2c driver working.
There are no more timeouts and I can read the hardware clock.
And "poweroff" finally turns off the machine (incl. power LED)
so that means our minipc-mcu driver is working well.

BTW: it appears as if the jz4740 doesn't have an i2c driver...
I thought quite late about looking for it and it even turned out
to have exactly the same register model and flowcharts.

So we could have simply used the jz4740-i2c driver - but fortunately
we did not do double-work because an jz4740-i2c driver doesn't seem
to exist at least in device tree based kernels.

There is also an jz4780-i2c driver but that has a more elaborated
controller with much more control registers.

And one more finding: with /dev/fb0 present my rootfs now starts
X11 and that seems to be running. It just takes a high CPU load
and seems to block uart interrupts and the console has some
hickups. Looking into /proc/interrupts didn't help much. i2c is silent,
mmc interrupts are not counting up, but usb interrupts. Maybe my
user-space is triggering something with spinlocks on the usb side.

Firstly, I will consolidate all the new patches... And then I can
look if I can fix the LCD and keyboard.

BR,
Nikolaus


> Am 26.12.2020 um 14:54 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Oh,
> nice. Yes, I'll try it even if it does not fix anything.
> 
> Simplifying code is also important, like I have done for the I2C driver.
> 
> Maybe a suggestion: according to upstream rules, commit messages should be
> imperative (i.e. tell what the patch is doing and not what we have done).
> I.e. "Simplify JZ4730 TCU driver modifications"
> 
> And it is usually helpful to prefix by the subsystem abbreviation, i.e.
> 
> "clk: ingenic: Simplify JZ4730 TCU driver modifications"
> 
> But it is not highest priority, especially as we will finally squeeze
> all our fixes into a single patch...
> 
> In the meantime I have added CONFIG_DRM_PANEL_SIMPLE and now we get a /dev/fb0.
> 
> But display remains black. There are three potential reasons:
> a) backlight is not enabled
> b) LCD timings are no longer defined in the DT but the panel-simple driver
> c) panel is not enabled by hardware setup (LCD_EN/TP204) which is an output of the P89LPC915
>   So this may be an I2C issue...
> 
> It may even be a mix of all of them.
> 
> BR and thanks,
> Nikolaus
> 
>> Am 25.12.2020 um 00:55 schrieb Paul Boddie <paul at boddie.org.uk>:
>> 
>> On Wednesday, 23 December 2020 17:18:44 CET Paul Boddie wrote:
>>> On Wednesday, 23 December 2020 15:56:01 CET H. Nikolaus Schaller wrote:
>>>> 
>>>> - date is counting in 1 second steps, so only the timing info in dmesg is
>>>> wrong (maybe the 1 second timer is ok, but the µs or ns count wrong)
>>> 
>>> I will still take a look at the OST peripheral. I'm still not sure whether
>>> to keep making the TCU driver pretend that it has TCU timers, as is done
>>> now, or whether to support multiple OST timers instead. But the width of
>>> the timers will need to be configurable.
>> 
>> I had a look at this and saw that a more elegant way of organising this driver 
>> might involve allowing the prescaler to be configured, at least if PCLK is 
>> selected as the input clock. This should then permit an identical clock 
>> configuration in the JZ4730 device tree to those used in other JZ-series 
>> device trees, which might not have been compatible with the way the driver has 
>> been organised (with separate, prescaled clocks) until now.
>> 
>> I don't know whether this patch would improve anything or not. It seems as if 
>> the correct value is already set by the driver in the input clock field of the 
>> OST's TCSR (timer control and status register): 5 if EXCLK is selected, which 
>> is what the Mipsbook device tree indicates (JZ4730_CLK_EXCLK).
>> 
>> Anyway, I have provided this patch in case it might help in some way. 
>> Potentially, if we change the assigned clock to JZ4730_CLK_PCLK, the timer 
>> clocks will be adjustable, which might be what we are missing with regard to 
>> the usability of these timers.
>> 
>> In any case, I hope this is helpful.
>> 
>> Paul<0001-Simplified-JZ4730-TCU-driver-modifications.patch>
> 
> _______________________________________________
> https://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel