[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel
H. Nikolaus Schaller
hns at goldelico.com
Thu Jan 14 22:58:58 CET 2021
> 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
> 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)
More information about the Letux-kernel