Thread (52 messages) 52 messages, 8 authors, 2018-10-15

Re: [PATCH v2 15/29] drm/bridge/synopsys: dw-hdmi: Enable workaround for v2.12a

From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: 2018-10-09 21:23:55
Also in: dri-devel, linux-arm-kernel, linux-clk, lkml

On Tue, Oct 09, 2018 at 01:56:04PM -0400, Ilia Mirkin wrote:
On Tue, Oct 9, 2018 at 1:40 PM Laurent Pinchart
[off-list ref] wrote:
quoted
commit 9c305eb442f3b371fc722ade827bbf673514123e
Author: Neil Armstrong [off-list ref]
Date:   Fri Feb 23 12:44:37 2018 +0100

    drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs

I haven't paid too much attention to the patch back then, and have now double-
checked the HDMI output on R-Car Gen3. Enabling the workaround doesn't cause
any regression, and reverting the commit doesn't cause any issue either. I
thus wonder whether we shouldn't enable the workaround with count = 1 in the
default case instead of adding new IP core versions to the list. It would be
nice if someone from Synopsys could comment on this.
I hope this comment isn't *incredibly* off-topic, but we encountered a
similar issue with NVIDIA (and I believe AMD) hardware a while back,
related to HDMI. This was due to infoframes not being sent, but
(perhaps) HDMI Audio being enabled.
You're probably right about the infoframes.  The errata documentation
for this workaround on iMX6 states:

 Each time one writes to some FC registers, and depending on the clock relation of sfr clk and tmds
 clk, some of these train of pulses (when these registers are configured in sequence), may not be
 caught by the arithmetic unit while it is busy processing/updating the first ones, so, it gets wrong
 video timing values, although the registers FC_* hold correct values. Even a soft reset will not
 make the arithmetic unit update correctly. Video will still pass correctly to the HDMI, but packets
 would not because the frame composer is holding internally incorrect video timing and this will
 quickly build up and overflow the packet FIFOs.

So, the workaround is about kicking the frame composer so that the
packets (iow, non-video data) are passed through correctly.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help