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

[H. Nikolaus Schaller]

> Am 14.01.2021 um 22:42 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Thursday, 14 January 2021 19:02:12 CET H. Nikolaus Schaller wrote:
>> Am 14.01.2021 um 11:55 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>> So we have a problem with the pinmux function selection.
>> 
>> Found it. Can now boot to blinking cursor without any user-space
>> help. Unless I try to start X11. Maybe X11 needs too much memory
>> or is influenced by the schedluer timer.
>> 
>> The problem was that there are new macros INGENIC_PIN_GROUP() and
>> INGENIC_PIN_GROUP_FUNCS() in pinctrl-ingenic to optimize memory
>> useage. So I had updated the earlier jz4730 pinmux group tables.
>> 
>> And I defined one of the pinmux arrays as int[] instead of u8[].
>> So 3 bytes were 0x00 until the next valid function state was there.
>> This made the pin functions for the LCDC not properly initialized
>> and so there was no HSYNC/VSYNC output to the panel.
> 
> That was rather unfortunate and potentially difficult to spot, so it was a 
> nice piece of detective work!

Well, printk is our friend :)

> 
>> Running my devmem2 script did overwrite and the display worked.
>> 
>>> This means the LCDC hacks are already working and the different
>>> lcd and pix clocks are not that critical.
>> 
>> BTW, I think I have found a patch for the DMA descriptor number
>> which should not harm the SoC with OSD and two LCDs but still do
>> the right thing for jz4730 and jz4740. So this is potentially
>> upstreamable.
> 
> I'll make a note about that below.
> 
>> So what remains to be fixed? Only the issue with the connector
>> type and bus format. I think the hack should not disturb other
>> Letux devices so we can merge it temporarily into the Letux tree.
> 
> OK. It would be good to figure that out and get it tested by CI20 users.

Yes, I want to test soon.

> 
>> So the Display should work now. I will consolidate the patches
>> so that my printk stuff is removed... So we will have a 5.11-rc4
>> on Monday with working LCD.
>> 
>> Then we can take another look at the I2C issues and the sluggish
>> scheduler timer and DMA. And finally on sound and Ethernet and why
>> X11 is not running.
> 
> A quick note about the timer: I found that in my L4 environment, sleep 
> operations seem to be accurate. However, that environment employs the OST for 
> scheduling (unless I am mistaken), and might not be instructive about the 
> timing-related issues within Linux.

Well, on all other Linux systems it is also accurate. So it is still
a miracle what is going on there.

> 
> [...]
> 
>> commit 7f4e6eda5bc9b634900ff33ae0fa3e7a7ce832ea
>> Author: H. Nikolaus Schaller <hns at goldelico.com>
>> Date:   Thu Jan 14 17:41:00 2021 +0100
>> 
>>    drm/ingenic: fix assignment of DMA channels
>>    for SoC without OSD like jz4730 and jz4740. On those, the first DMA
>>    channel is for the single LCD and the second for the palette. If we
>>    leave the first uninitialized, the LCDC will not become enabled.

Ys, that was a quick shot for the description, based on how I did interpret
the programming manual. But of course it may still be wrong :)

We can fix that later, after having the full set of patches, and cleaned
them up (mainly squeezed and separated into subsystem patches).

> 
> Just to clarify this, the second channel is for a second panel (where STN/
> passive matrix panels are used). As I noted earlier, the palette details are 
> actually "chained" to framebuffer details using two descriptors associated 
> with a single channel.
> 
> Or in a simple diagram:
> 
> LCDDA0 -> palette descriptor <- next
>          ...                   ...
>          next ---------------> framebuffer descriptor
> 
> LCDDA1 -> (descriptors for the second STN panel, which we don't have)
> 
> Paul

BR,
Nikolaus