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

[Neil Armstrong]

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 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

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