linux-kernel - [RFC PATCH] drm: dw-hdmi-i2s: Workaround for interchannel sample offset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Mon, 4 May 2020 09:34:22 +0200
From:   Matthias Blankertz <matthias.blankertz@...itec.com>
To:     Neil Armstrong <narmstrong@...libre.com>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Jonas Karlman <jonas@...boo.se>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        Jerome Brunet <jbrunet@...libre.com>
CC:     <linux-kernel@...r.kernel.org>, <alsa-devel@...a-project.org>,
        <linux-renesas-soc@...r.kernel.org>
Subject: [RFC PATCH] drm: dw-hdmi-i2s: Workaround for interchannel sample offset

Add a second reset of the I2S block after the audio parameters are set.
Without this, it was observed on the R-Car Gen3 platform that in ~50% of
audio stream starts, the samples on each odd-numbered channel were delayed
by one sample relative to the even-numbered channels: A stereo test stream
was sent with a walking ones pattern, that is the data pattern was:
Sample  Left    Right
1       0x0001  0x0001
2       0x0002  0x0002
3       0x0004  0x0004
4       0x0008  0x0008
5       0x0010  0x0010
etc.
When the error occurred, the receiving device got the following data:
Left    Right
...
0x0004  0x0002
0x0008  0x0004
0x0010  0x0008
...

With the additional reset, the samples were always properly aligned on the
receiver.

Maybe this relates to the comment of commit 46cecde310bb ("drm/bridge:
dw-hdmi-i2s: reset audio fifo before applying new params"), but without
the datasheet it is only speculation.

Signed-off-by: Matthias Blankertz <matthias.blankertz@...itec.com>
---

Can someone with knowledge of the hardware, or access to the datasheet
give some insight if this is a "proper" fix, an ugly workaround, or the
problem is actually elsewhere and this only changes behaviour due to
e.g. timing changes?

Thanks,
	Matthias

 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index d7e65c869415..0cb526f6b8d9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -110,6 +110,14 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
 	hdmi_write(audio, conf0, HDMI_AUD_CONF0);
 	hdmi_write(audio, conf1, HDMI_AUD_CONF1);

+	/* Re-reset I2S in an attempt to fix inter-channel sample offset
+	 * Without this second reset of the I2S interface, it was observed on
+	 * the R-Car Gen3 platform that in ~50% of audio stream starts, the
+	 * samples on each odd-numbered channel were delayed by one sample
+	 * relative to the even-numbered channels.
+	 */
+	audio->write(audio->hdmi, (u8)~HDMI_MC_SWRSTZ_I2SSWRST_REQ,
+		     HDMI_MC_SWRSTZ);
 	return 0;
 }

base-commit: 7111951b8d4973bda27ff663f2cf18b663d15b48
-- 
2.26.2