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

[Paul Boddie]

On Friday 15. May 2020 09.43.54 Neil Armstrong wrote:
> 
> On 15/05/2020 00:04, Paul Boddie wrote:
> > 
> > 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.

I have taken a look at the clocks to see what they get initialised to. Here 
are the details of the LCD controller clocks from this experiment as reported 
by /sys/kernel/debug/clk/clk_summary:

    lcd                               1        1        0    48000000
       tve                            1        1        0    48000000
    vpll                              2        2        2   888000000
       hdmi                           1        1        0    26909090
       lcd1pixclk                     0        0        0   888000000
       lcd0pixclk                     1        1        0    98666666

>From the 3.18 vendor kernel:

    lcd                                   1            1    48000000
       tve                                1            1    48000000
    vpll                                  2            2   888000000
       hdmi                               1            1    26909090
       lcd1pixclk                         0            0   888000000
       lcd0pixclk                         1            1   111000000

(The 3.18 output lacks the "protect count" value.)

Here, the only obvious difference is a slower pixel clock in the experimental 
system: 98.7MHz versus 111MHz.

[...]

> Perfect, EDID reading works fine.

We're fairly confident about this now, at least. ;-) For the record, the 
Synopsys peripheral's own I2C support seems far preferable to Ingenic's own 
I2C peripherals and was a nice discovery amongst the bridge driver's 
capabilities.

[...]

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

Yes. Permission denied for all that I have tried.

[...]

> >>> 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.
> 
> Replying to your previous email concerning the bus formats, yeah should
> probably look at the bus format configured, because if you have a DDR bus
> format, the clock will be half and thus won't work.

I can easily imagine that I am missing something with regard to bus formats 
and flags. However, I reviewed differences between drivers and found a few 
more things that are not done in the ingenic-drm driver, mostly because they 
won't be needed by other SoCs or aren't even supported by them. Some of these 
things are not so easy to explain, but maybe they sound familiar to someone.

The 3.18 kernel driver sets up two DMA descriptors, rather than the usual one 
that would be sufficient, and it enables 8-word descriptors that seem to use 
on-screen display functionality in their additional 4 words. The programming 
manual doesn't say anything obvious about this, but it did make me wonder 
whether this extra functionality might need to be enabled in order to activate 
the HDMI output. All it seems to do is to make a foreground layer equivalent 
to the size of the framebuffer.

(With the above noted, the 3.18 kernel doesn't obviously activate the on-
screen display support using the "OSD configure" register, although the vendor 
3.0.8 kernel does, alongside much else.)

There are some registers used that are probably not available on other SoCs in 
the family. An RGB control register sets up RGB output and odd/even line 
formats. A "priority level threshold configure" register seems to be used for 
some kind of bus arbitration. Again, I can imagine that the pipeline to the 
HDMI peripheral may need a specific configuration, but I haven't found an 
explanation yet.

I have tried to introduce these extra measures in a fairly sensible way to the 
ingenic-drm driver, but no further progress has been made so far.

Thanks once again for comments and suggestions!

Paul