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@32:1280x1024-60.02
> >
> > ...yields the following:
> >
> > failed to set mode: Permission denied
> > setting mode 1280x1024-60.02Hz@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@32:1280x1024-60.02
...now yields this:
setting mode 1280x1024-60.02Hz@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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
