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 at boddie.org.uk
Sat May 16 17:01:49 UTC 2020
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
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
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
> > 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
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!
More information about the dri-devel