Hi,
On 06/07/2020 01:57, Paul Boddie wrote:
> 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 };
> ...
> (&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).
I think this is specific to the ingenic DRM driver, so yeah it may be needed in your case.
>
> 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.
It does but when not provided, it doesn't use it.
It's handled in drm_atomic_bridge_chain_select_bus_fmts() :
if (conn->display_info.num_bus_formats &&
conn->display_info.bus_formats)
out_bus_fmts[0] = conn->display_info.bus_formats[0];
else
out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
>
> [...]
>
>>> 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
This is because you don't provide the gamma setup ioctl, it's not a fatal error at all.
It should be warning since it's optional.
Did you check all modes ?
>
> 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
>
>
Neil
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
