From: Paul Boddie <paul@boddie.org.uk>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>,
dri-devel@lists.freedesktop.org, Jonas Karlman <jonas@kwiboo.se>
Subject: Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
Date: Sat, 16 May 2020 19:01:49 +0200 [thread overview]
Message-ID: <1684182.mmkAs6cchh@jeremy> (raw)
In-Reply-To: <1689d947-b2e1-c023-b2ed-1e9d23c075f3@baylibre.com>
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@32:1280x1024-60.02
> >
> > ...yields the following:
> >
> > failed to set mode: Permission denied
> > setting mode 1280x1024-60.02Hz@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-05-16 17:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 19:37 Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 Paul Boddie
2020-05-13 7:37 ` 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
2020-05-13 21:18 ` Paul Boddie
2020-05-14 22:04 ` Paul Boddie
2020-05-15 7:43 ` Neil Armstrong
2020-05-16 17:01 ` Paul Boddie [this message]
2020-07-05 23:57 ` Paul Boddie
2020-07-06 12:12 ` Neil Armstrong
2020-07-06 20:55 ` Paul Boddie
2020-08-19 10:21 ` Ezequiel Garcia
2020-08-19 16:22 ` Paul Boddie
2020-08-19 18:49 ` H. Nikolaus Schaller
2020-08-19 22:26 ` Ezequiel Garcia
2020-08-20 8:19 ` H. Nikolaus Schaller
2020-08-20 22:49 ` Paul Boddie
2020-08-21 13:32 ` Ezequiel Garcia
2020-08-21 22:11 ` Paul Boddie
2020-08-21 22:24 ` Paul Cercueil
2020-08-24 13:46 ` Ezequiel Garcia
2020-08-24 16:04 ` H. Nikolaus Schaller
2020-08-24 17:38 ` Ezequiel Garcia
2020-08-24 21:11 ` Paul Cercueil
2020-08-27 7:21 ` H. Nikolaus Schaller
2020-09-10 7:53 ` H. Nikolaus Schaller
2020-09-10 12:14 ` Ezequiel Garcia
2020-09-10 13:48 ` H. Nikolaus Schaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1684182.mmkAs6cchh@jeremy \
--to=paul@boddie.org.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=narmstrong@baylibre.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.