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

I'm one of the drm/bridge maintainer and, with Jernel & Jonas, we did most of the
changes on the dw-hdmi driver recently for the Amlogic, Rockchip & Allwinner platforms.

On 12/05/2020 21:37, Paul Boddie wrote:
> Hello,
> 
> On and off over the past few months, I have been looking at getting the 
> Synopsys DesignWare HDMI peripheral used in the Ingenic JZ4780 SoC working 
> with a recent kernel. Unfortunately, what probably should be a straightforward 
> task is proving more difficult than it seems, and I have been advised to ask 
> for advice on this list.
> 
> == Background ==
> 
> Previously, in the vendor kernels released by Imagination Technologies for the 
> MIPS Creator CI20, there were specialised HDMI drivers for the JZ4780:
> 
> * One (based on Linux 3.0.8) which seems to use a Synopsys hardware
>   abstraction layer.
> 
> * Another (based on Linux 3.18) where the driver incorporates code used to
>   support Freescale products and cooperates with a "CRTC" driver that has
>   since been replaced by the ingenic-drm.c driver.
> 
> Since the Freescale-related code now seems to reside as a kind of generic 
> driver in drivers/gpu/drm/bridge/synopsys [1], with some other drivers 
> specialising this generic support, I thought that it might be straightforward 
> to specialise the code similarly for the JZ4780. Unfortunately, I have not 
> managed to achieve this so far, and I imagine that I must have overlooked 
> something.
> 
> == Summary of Work ==
> 
> What I have done so far is to add a new file to...
> 
> drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c
> 
> (See [2] for the full file.)
> 
> This specialises the generic dw-hdmi.c driver and is heavily based on the 
> existing driver in...
> 
> drivers/gpu/drm/imx/dw_hdmi-imx.c
> 
> However, the probe and remove functions are defined in a similar way to...
> 
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> 
> It would appear, looking at the vendor kernel code, that the configuration of 
> the peripheral in the JZ4780 is most similar to that done in the i.MX 
> products, with various configuration operations that are done in their own 
> particular way in the vendor kernel code now being done in a more generic way 
> in the bridge driver code. So, I have a certain amount of confidence that the 
> PLL and current control tables are reasonable.
> 
> == Observations ==
> 
> When powering up the system with the driver built into the kernel, the driver 
> is able to obtain mode information over DDC using the Synopsys peripheral's 
> own I2C support (which is more reliable than using the JZ4780's I2C 
> peripherals), and a viable list of modes is obtained. 

Can you run the kernel with drm debug enabled ? drm.debug=0x3f for example
you'll have all the modes checks & so on

> However, the debugfs 
> state information in /sys/kernel/debug/dri/0/state is largely unpopulated:
> 
> plane[31]: plane-0
>         crtc=(null)
>         fb=0
>         crtc-pos=0x0+0+0
>         src-pos=0.000000x0.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=0
>         color-encoding=ITU-R BT.601 YCbCr
>         color-range=YCbCr limited range
> crtc[32]: crtc-0
>         enable=0
>         active=0
>         self_refresh_active=0
>         planes_changed=0
>         mode_changed=0
>         active_changed=0
>         connectors_changed=0
>         color_mgmt_changed=0
>         plane_mask=0
>         connector_mask=0
>         encoder_mask=0
>         mode: "": 0 0 0 0 0 0 0 0 0 0 0x0 0x0
> connector[34]: HDMI-A-1
>         crtc=(null)
>         self_refresh_aware=0

Please use the "modetest" utility from the libdrm source package, it will
list all the available mode and permit testing other modes.

> 
> At the moment, I and others who have tried to test this code have seen that 
> the peripheral is not enabled (as confirmed by inspecting the appropriate 
> entry under /sys/devices/platform). It appears that one obstacle is that the 
> "bus format" is not set for the connector. Here, I noticed (and was reminded 
> again recently) that in the bridge driver, there is no call to 
> drm_display_info_set_bus_formats unlike in other bridge drivers.

This call is optional, if your video pipeline outputs RGB for the dw-hdmi, then
you can leave the default for now and omit the bus format negotiation.
When you'll push the driver, you'll have to implement it correctly like I did
in the meson-dw-hdmi glue (and in RFC for rockchip driver).

> 
> If such a call is added with a plausible bus format, the peripheral will be 
> enabled, but the signal is not correct (monitors report things like "Input not 
> supported"). It also occurs to me that other aspects of the signal may need to 
> be defined. However, the debugfs state information will be populated with 
> plausible values and seems to indicate that initialisation has taken place.

"Input not supported" means the timings/clk are incorrect.

Of you had an format issue, you'll have incorrect colors/garbled output.

> 
> == Conclusions ==
> 
> Without direct modifications to dw-hdmi.c, it seems like the initialisation of 
> the appropriate data structures is not being completed. Without the call to 
> drm_display_info_set_bus_formats in dw_hdmi_bridge_attach, the encoder does 
> not get set on the connector, and the chain of components is not fully 
> traversed for initialisation.
> 
> One part of this situation is the dw_hdmi_setup function in the bridge driver. 
> Here, there is the following code:
> 
>         /* TOFIX: Get input format from plat data or fallback to RGB888 */
>         if (hdmi->plat_data->input_bus_format)
>                 hdmi->hdmi_data.enc_in_bus_format =
>                         hdmi->plat_data->input_bus_format;
>         else
>                 hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> 
>         /* TOFIX: Get input encoding from plat data or fallback to none */
>         if (hdmi->plat_data->input_bus_encoding)
>                 hdmi->hdmi_data.enc_in_encoding =
>                         hdmi->plat_data->input_bus_encoding;
>         else
>                 hdmi->hdmi_data.enc_in_encoding = V4L2_YCBCR_ENC_DEFAULT;
> 
> What I seek guidance on is whether the unfixed nature of this code is having 
> an impact and what I should be doing to make this driver initialise correctly. 
> Given that there is no obvious documentation for the Synopsys peripheral, I 
> feel that it will be a long journey figuring this out by myself.

Please enable the dw-hdmi debug prints and enable the DRM debug prints to check
if everything is negociated.

But if you have "Input not supported" on your monitor, this means you have TMDS going
out on your hardware, which is good, this means all the power/reset/system clocks
are ok.
This could mean you have a timing/clock issue, please check if something is not
done on the pixel clock before going to the dw-hdmi block.

Neil

> 
> Thanks for any advice that anyone might have!
> 
> Paul
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2017-March/134666.html
> 
> [2] http://git.goldelico.com/?p=letux-kernel.git;a=blob_plain;f=drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c;hb=75c6904c2f198825f67172a0a5a98190fa54ae05
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>