@@ -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;
}
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@cetitec.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(+) base-commit: 7111951b8d4973bda27ff663f2cf18b663d15b48