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

12 May 2020


      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. 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
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.
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.
== 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.
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/...