drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

[Paul Boddie]

Hello,

On Friday, 15 May 2020 09:43:54 CEST Neil Armstrong wrote:
> 
> On 15/05/2020 00:04, Paul Boddie wrote:
> > 
> > Well, I've done this but I probably need to know what to look for. One
> > thing that appears regardless of this debugging output being enabled is a
> > problem with the vertical blanking functionality:
> > 
> > WARNING: CPU: 1 PID: 396 at drivers/gpu/drm/drm_atomic_helper.c:1457
> > drm_atomic_helper_wait_for_vblanks+0x1ec/0x25c
> > [CRTC:32:crtc-0] vblank wait timed out
> 
> This means the CRTC didn't start, usually because the Pixel clock didn't go
> through the pipeline to the pixel generator, thus not generating
> vblank/vsync interrupts.
> 
> You may check if there is not muxes to select the clock source/pixel
> destination.

It has obviously been a while since I asked about the DW-HDMI functionality. 
Since then, I have verified the initialisation of the Ingenic JZ4780 LCD 
controller and the Synopsys HDMI peripheral in the L4 Runtime Environment 
(running on the Fiasco.OC microkernel), producing a picture and handling 
display interrupts.

Having brought the necessary changes back to the Ingenic DRM driver, I can 
make the driver activate the LCD controller and produce vertical blank 
interrupts, and these are handled and counted in /proc/interrupts. The 
previous errors about timeouts are now gone.

However, the DRM driver can only be made to start if I set the bus format in 
dw_hdmi_bridge_attach:

  u32 bus_format[] = { MEDIA_BUS_FMT_RGB888_1X24 };
  ...
  drm_display_info_set_bus_formats(&connector->display_info,
                                   bus_format, ARRAY_SIZE(bus_format));

Without this, the DRM driver will test for a bus format on the connector's 
display_info structure in ingenic_drm_encoder_atomic_check and return EINVAL. 
There have previously been indications that this should not need to be done, 
but I see that other drivers do similar things (for example, ti-tfp410.c).

It also seems to be appropriate to set the input_bus_format on the platform-
specific HDMI driver; otherwise, I doubt that appropriate bus encodings will 
be chosen in the Synopsys driver.

[...]

> > Attempting to set a mode using...
> > 
> > modetest -D /dev/dri/card0 -M ingenic-drm -s 34 at 32:1280x1024-60.02
> > 
> > ...yields the following:
> > 
> > failed to set mode: Permission denied
> > setting mode 1280x1024-60.02Hz at XR24 on connectors 34, crtc 32
> 
> This is weird, the command line is ok, is it the same for all modes ?

Testing against 5.8-rc3 with the above changes seems to have moved the needle 
slightly. Although I still get "Input not supported" from my monitor, running 
modetest now gives a different error:

modetest -D /dev/dri/card0 -M ingenic-drm -s 34 at 32:1280x1024-60.02

...now yields this:

setting mode 1280x1024-60.02Hz at XR24 on connectors 34, crtc 32
failed to set gamma: Invalid argument

There also seems to be a card1, but I get the same result with that, and they 
both seem to produce similar output with modetest without the -s option.

Anyway, progress is rather slow trying to figure out the obstruction here, so 
any advice would still be appreciated.

Thanks in advance,

Paul