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

[H. Nikolaus Schaller]

> Am 11.01.2021 um 19:50 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Monday, 11 January 2021 17:13:29 CET H. Nikolaus Schaller wrote:
>>> Am 11.01.2021 um 16:27 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>> A problem seems to be that ingenic_drm_encoder_atomic_check() has no
>>> formats.
>>> 
>>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/ingenic/ing
>>> enic-drm-drv.c#L535
>>> 
>>> I think I remember this from the CI20 HDMI work but do not know the
>>> solution.
>> Just found something. In our case it should come from the panel_simple
>> driver. There is code to setup display_info.num_bus_formats:
>> 
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-s
>> imple.c#L222
>> 
>> But it is set only if there is hard-coded, i.e. panel table indexed by
>> compatible string. But not if it is initialized purely from device tree.
>> 
>> So it looks as if some mechanism is missing to define the connector (type,
>> bus formats) in device tree... Or I am missing where and how it can be
>> defined by DT.
>> 
>> BTW: hacking some desc->bus_format=MEDIA_BUS_FMT_RGB565_1X16; into this
>> function makes the jz4730 LCDC start up and enable backlight... But image
>> is wrong and leads to "vblank wait timed out". So there is now some
>> initialization of the LCDC, but it is wrong.
> 
> I don't think I ever found out what the "correct" solution was for this.

Well, for drivers which have a ".compatible" entry they can apparently set
it in their get_modes function. The panel_simple driver is some mixture.
If the panel is explicitly listed in the tables, there is a bus format.

But the fallback was forgotten to somehow provide one. The same is for
the connector-type. IMHO both should also be defined in the DT.

> It 
> seems incorrect to hack in the bus format, which was also necessary when 
> troubleshooting the CI20 so that the Ingenic DRM driver would then get 
> initialised, but I only ever really got advice to run various tools and to 
> report back on what those tools said. I seem to remember that beyond a certain 
> point, those tools produced sensible results, but only if we hacked in the bus 
> format...

IMHO doing it where I have hacked the panel_simple is indeed the right
place - because the table based initialization does it there as well -
but it should not be a constant in code.

> 
> I would have to look back on my discussions with the DRM people and to filter 
> out the hundreds of useless messages that I had to receive from the mailing 
> list just so that I could ask other people some apparently simple questions. 
> But certainly, the vblank error sounds very familiar. I think it was that 
> which made me get the HDMI peripheral *including* interrupts working in the L4 
> runtime environment, just to demonstrate that I hadn't missed something.

I have checked what is going on and there is another discrepancy. In
ingenic_drm_plane_config() the fourcc is DRM_FORMAT_RGB888 (no idea where
this comes from - not from the panel driver where I define MEDIA_BUS_FMT_RGB565_1X16)
which sets the BPP field to 0x05. The jz4730 does not permit such a value for
this register. Only the jz4740 and later SoC version. Otherwise they are
almost compatible, at least I have not seen another incompatibility.

The other issue (which may be the reason for the atomic timeout) is that
LCDCMD0 seems not to be initialized properly. Therefore the DMA probably
gets stuck and no SOF/EOF interrupts occur.

At the moment I wouldn't mind if the framebuffer is not displayed properly
(e.g. shows false colors, distorted or whatever) but the LCDC should scan
the panel from the framebuffer (something should blink or change if I type)
and there should be no warnings and errors during boot...

It seems as if we are close to get this hacked... Then we can look for a
general solution that does not disturb e.g. jz4780.

BR,
Nikolaus


PS: I get an idea where the wrong DRM_FORMAT_RGB888 comes from. There is
a new format table since v5.11-rc1 which defines the formats every Ingenic
SoC understands. And I have taken the same table as for the jz4740.
If user-space or the /dev/fb0 driver can access this table it assumes
that the jz4730 also understands DRM_FORMAT_XRGB8888. I'll try to add
a specific jz4730 format table later...