Re: [PATCH] drm/bridge: dw-hdmi-i2s: set insert_pcuv bit if hardware supports it

Re: [PATCH] drm/bridge: dw-hdmi-i2s: set insert_pcuv bit if hardware supports it

[Geraldo Nascimento]

On Mon, Aug 22, 2022 at 02:27:26PM +0100, Mark Brown wrote:
> On Sat, Aug 20, 2022 at 09:36:53PM -0300, Geraldo Nascimento wrote:
> 
> > +	/*
> > +	 * dw-hdmi introduced insert_pcuv bit in version 2.10a.
> > +	 * When set (1'b1), this bit enables the insertion of the PCUV
> > +	 * (Parity, Channel Status, User bit and Validity) bits on the
> > +	 * incoming audio stream (support limited to Linear PCM audio)
> > +	 */
> > +
> > +	if (hdmi_read(audio, HDMI_DESIGN_ID) >= 0x21)
> > +		conf2 |= HDMI_AUD_CONF2_INSERT_PCUV;
> 
> So what if we're not handlign linear PCM?

Good question, Mark. For HBR and NL-PCM there are different bits that
need to be set in aud_conf2 Sample Register, and then insert_pcuv bit
needs to be dropped.

I don't have a sink handy however to test the other modes. Do you have
a suggestion on how to make this the default for L-PCM specifically?

Thanks,
Geraldo Nascimento

Re: [PATCH] drm/bridge: dw-hdmi-i2s: set insert_pcuv bit if hardware supports it

[Geraldo Nascimento]

On Mon, Aug 22, 2022 at 02:27:26PM +0100, Mark Brown wrote:
> On Sat, Aug 20, 2022 at 09:36:53PM -0300, Geraldo Nascimento wrote:
> 
> > +	/*
> > +	 * dw-hdmi introduced insert_pcuv bit in version 2.10a.
> > +	 * When set (1'b1), this bit enables the insertion of the PCUV
> > +	 * (Parity, Channel Status, User bit and Validity) bits on the
> > +	 * incoming audio stream (support limited to Linear PCM audio)
> > +	 */
> > +
> > +	if (hdmi_read(audio, HDMI_DESIGN_ID) >= 0x21)
> > +		conf2 |= HDMI_AUD_CONF2_INSERT_PCUV;
> 
> So what if we're not handlign linear PCM?

Hi Mark,

I think we may be able to restrict the fix for L-PCM only by checking
byte 0 of iec.status, specifically bit 1. Our define is called
IEC958_AES0_NONAUDIO but https://tech.ebu.ch/docs/tech/tech3250.pdf
calls it the "Linear PCM identification" bit. There's also a
supplement to AES/EBU 3250 in https://tech.ebu.ch/docs/n/n009_1.pdf

Let me know if the following is OK. I'll be happy to submit V2 if
it is.

Thanks,
Geraldo Nascimento

--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -42,6 +42,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
 	struct dw_hdmi *hdmi = audio->hdmi;
 	u8 conf0 = 0;
 	u8 conf1 = 0;
+	u8 conf2 = 0;
 	u8 inputclkfs = 0;
 
 	/* it cares I2S only */
@@ -101,6 +102,18 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
 		return -EINVAL;
 	}
 
+	/*
+	 * dw-hdmi introduced insert_pcuv bit in version 2.10a.
+	 * When set (1'b1), this bit enables the insertion of the PCUV
+	 * (Parity, Channel Status, User bit and Validity) bits on the
+	 * incoming audio stream (support limited to Linear PCM audio)
+	 */
+
+	if (hdmi_read(audio, HDMI_DESIGN_ID) >= 0x21 &&
+			!(hparms->iec.status[0] & IEC958_AES0_NONAUDIO))
+		conf2 = HDMI_AUD_CONF2_INSERT_PCUV;
+
 	dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
 	dw_hdmi_set_channel_status(hdmi, hparms->iec.status);
 	dw_hdmi_set_channel_count(hdmi, hparms->channels);
@@ -109,6 +122,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
 	hdmi_write(audio, inputclkfs, HDMI_AUD_INPUTCLKFS);
 	hdmi_write(audio, conf0, HDMI_AUD_CONF0);
 	hdmi_write(audio, conf1, HDMI_AUD_CONF1);
+	hdmi_write(audio, conf2, HDMI_AUD_CONF2);
 
 	return 0;
 }

Re: [PATCH] drm/bridge: dw-hdmi-i2s: set insert_pcuv bit if hardware supports it

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Tue, Aug 23, 2022 at 11:46:38AM -0300, Geraldo Nascimento wrote:

> I think we may be able to restrict the fix for L-PCM only by checking
> byte 0 of iec.status, specifically bit 1. Our define is called
> IEC958_AES0_NONAUDIO but https://tech.ebu.ch/docs/tech/tech3250.pdf
> calls it the "Linear PCM identification" bit. There's also a
> supplement to AES/EBU 3250 in https://tech.ebu.ch/docs/n/n009_1.pdf

> Let me know if the following is OK. I'll be happy to submit V2 if
> it is.

LGTM, though I don't really know anything about the hardware
specifically.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]