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]
Message-ID: <20200504073422.7322-1-matthias.blankertz@cetitec.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ