mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Robert Foss <rfoss@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Rob Clark <robdclark@gmail.com>,
	Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	Simona Vetter <simona@ffwll.ch>,
	Simona Vetter <simona.vetter@ffwll.ch>
Cc: <dri-devel@lists.freedesktop.org>,
	<linux-arm-msm@vger.kernel.org>,
	<freedreno@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 6/7] drm/msm/hdmi: also send the SPD and HDMI Vendor Specific InfoFrames
Date: Fri, 7 Feb 2025 17:31:20 -0800	[thread overview]
Message-ID: <9c35f577-2124-4f80-a5d3-542b47ed6825@quicinc.com> (raw)
In-Reply-To: <20250208-bridge-hdmi-connector-v7-6-0c3837f00258@linaro.org>



On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
> Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
> 
> While the HDMI block has special block to send HVS InfoFrame, use
> GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
> that requires manual repacking in the driver, while GENERIC0 doesn't
> have such format requirements. The msm-4.4 kernel uses GENERIC0 to send
> HDR InfoFrame which we do not at this point anyway.
> 

True that GENERIC_0/1 packets can be used for any infoframe. But because 
we have so many of them, thats why when there are dedicated registers 
for some of them, we use them to save the GENERIC0 ones for others.

Lets take a case where we want to send HVSIF, SPD and HDR together for 
the same frame, then we run out as there are no HDR specific infoframe 
registers we can use. Is the expectation that we will migrate to 
VENSPEC_INFO regs for HVSIF when we add HDR support?

Also from a validation standpoint, I guess to really validate this 
change you need an analyzer which decodes the HVSIF. So was this mostly 
sanity tested at this pointed to make sure that the sink just comes up?

> Acked-by: Maxime Ripard <mripard@kernel.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
>   drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 93 ++++++++++++++++++++++++++++++++++
>   1 file changed, 93 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> index 15ab0858105328c2f774ec1f79423614bbbaeb41..aee75eee3d4244cd95e44df46d65b8e3e53de735 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> @@ -69,6 +69,8 @@ static void power_off(struct drm_bridge *bridge)
>   }
>   
>   #define AVI_IFRAME_LINE_NUMBER 1
> +#define SPD_IFRAME_LINE_NUMBER 1
> +#define VENSPEC_IFRAME_LINE_NUMBER 3
>   
>   static int msm_hdmi_config_avi_infoframe(struct hdmi *hdmi,
>   					 const u8 *buffer, size_t len)
> @@ -142,6 +144,74 @@ static int msm_hdmi_config_audio_infoframe(struct hdmi *hdmi,
>   	return 0;
>   }
>   
> +static int msm_hdmi_config_spd_infoframe(struct hdmi *hdmi,
> +					 const u8 *buffer, size_t len)
> +{
> +	u32 buf[7] = {};
> +	u32 val;
> +	int i;
> +
> +	if (len != HDMI_INFOFRAME_SIZE(SPD) || len - 3 > sizeof(buf)) {
> +		DRM_DEV_ERROR(&hdmi->pdev->dev,
> +			"failed to configure SPD infoframe\n");
> +		return -EINVAL;
> +	}
> +
> +	/* checksum gets written together with the body of the frame */
> +	hdmi_write(hdmi, REG_HDMI_GENERIC1_HDR,
> +		   buffer[0] |
> +		   buffer[1] << 8 |
> +		   buffer[2] << 16);
> +
> +	memcpy(buf, &buffer[3], len - 3);
> +
> +	for (i = 0; i < ARRAY_SIZE(buf); i++)
> +		hdmi_write(hdmi, REG_HDMI_GENERIC1(i), buf[i]);
> +
> +	val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
> +	val |= HDMI_GEN_PKT_CTRL_GENERIC1_SEND |
> +		 HDMI_GEN_PKT_CTRL_GENERIC1_CONT |
> +		 HDMI_GEN_PKT_CTRL_GENERIC1_LINE(SPD_IFRAME_LINE_NUMBER);
> +	hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
> +
> +	return 0;
> +}
> +
> +static int msm_hdmi_config_hdmi_infoframe(struct hdmi *hdmi,
> +					  const u8 *buffer, size_t len)

msm_hdmi_config_hvsif_infoframe() to be more clear?

> +{
> +	u32 buf[7] = {};
> +	u32 val;
> +	int i;
> +
> +	if (len < HDMI_INFOFRAME_HEADER_SIZE + HDMI_VENDOR_INFOFRAME_SIZE ||
> +	    len - 3 > sizeof(buf)) {
> +		DRM_DEV_ERROR(&hdmi->pdev->dev,
> +			"failed to configure HDMI infoframe\n");
> +		return -EINVAL;
> +	}
> +
> +	/* checksum gets written together with the body of the frame */
> +	hdmi_write(hdmi, REG_HDMI_GENERIC0_HDR,
> +		   buffer[0] |
> +		   buffer[1] << 8 |
> +		   buffer[2] << 16);
> +
> +	memcpy(buf, &buffer[3], len - 3);
> +
> +	for (i = 0; i < ARRAY_SIZE(buf); i++)
> +		hdmi_write(hdmi, REG_HDMI_GENERIC0(i), buf[i]);
> +
> +	val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
> +	val |= HDMI_GEN_PKT_CTRL_GENERIC0_SEND |
> +		 HDMI_GEN_PKT_CTRL_GENERIC0_CONT |
> +		 HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE |
> +		 HDMI_GEN_PKT_CTRL_GENERIC0_LINE(VENSPEC_IFRAME_LINE_NUMBER);
> +	hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
> +
> +	return 0;
> +}
> +
>   static int msm_hdmi_bridge_clear_infoframe(struct drm_bridge *bridge,
>   					   enum hdmi_infoframe_type type)
>   {
> @@ -176,6 +246,25 @@ static int msm_hdmi_bridge_clear_infoframe(struct drm_bridge *bridge,
>   
>   		break;
>   
> +	case HDMI_INFOFRAME_TYPE_SPD:
> +		val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
> +		val &= ~(HDMI_GEN_PKT_CTRL_GENERIC1_SEND |
> +			 HDMI_GEN_PKT_CTRL_GENERIC1_CONT |
> +			 HDMI_GEN_PKT_CTRL_GENERIC1_LINE__MASK);
> +		hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
> +
> +		break;
> +
> +	case HDMI_INFOFRAME_TYPE_VENDOR:
> +		val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
> +		val &= ~(HDMI_GEN_PKT_CTRL_GENERIC0_SEND |
> +			 HDMI_GEN_PKT_CTRL_GENERIC0_CONT |
> +			 HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE |
> +			 HDMI_GEN_PKT_CTRL_GENERIC0_LINE__MASK);
> +		hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
> +
> +		break;
> +
>   	default:
>   		drm_dbg_driver(hdmi_bridge->base.dev, "Unsupported infoframe type %x\n", type);
>   	}
> @@ -197,6 +286,10 @@ static int msm_hdmi_bridge_write_infoframe(struct drm_bridge *bridge,
>   		return msm_hdmi_config_avi_infoframe(hdmi, buffer, len);
>   	case HDMI_INFOFRAME_TYPE_AUDIO:
>   		return msm_hdmi_config_audio_infoframe(hdmi, buffer, len);
> +	case HDMI_INFOFRAME_TYPE_SPD:
> +		return msm_hdmi_config_spd_infoframe(hdmi, buffer, len);
> +	case HDMI_INFOFRAME_TYPE_VENDOR:
> +		return msm_hdmi_config_hdmi_infoframe(hdmi, buffer, len);
>   	default:
>   		drm_dbg_driver(hdmi_bridge->base.dev, "Unsupported infoframe type %x\n", type);
>   		return 0;
> 


  reply	other threads:[~2025-02-08  1:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-08  0:26 [PATCH v7 0/7] drm/msm: make use of the HDMI connector infrastructure Dmitry Baryshkov
2025-02-08  0:27 ` [PATCH v7 1/7] drm/msm/hdmi: switch to atomic bridge callbacks Dmitry Baryshkov
2025-02-08  0:27 ` [PATCH v7 2/7] drm/msm/hdmi: program HDMI timings during atomic_pre_enable Dmitry Baryshkov
2025-02-08  0:42   ` Abhinav Kumar
2025-02-08  3:49     ` Dmitry Baryshkov
2025-02-08  0:27 ` [PATCH v7 3/7] drm/msm/hdmi: make use of the drm_connector_hdmi framework Dmitry Baryshkov
2025-02-08  4:14   ` Abhinav Kumar
2025-02-08  0:27 ` [PATCH v7 4/7] drm/msm/hdmi: get rid of hdmi_mode Dmitry Baryshkov
2025-02-08  0:27 ` [PATCH v7 5/7] drm/msm/hdmi: update HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE definition Dmitry Baryshkov
2025-02-08  0:27 ` [PATCH v7 6/7] drm/msm/hdmi: also send the SPD and HDMI Vendor Specific InfoFrames Dmitry Baryshkov
2025-02-08  1:31   ` Abhinav Kumar [this message]
2025-02-08  2:04     ` Dmitry Baryshkov
2025-02-08  3:05       ` Abhinav Kumar
2025-02-08  3:24         ` Dmitry Baryshkov
2025-02-08  0:27 ` [PATCH v7 7/7] drm/msm/hdmi: use DRM HDMI Audio framework Dmitry Baryshkov
2025-02-10 22:26   ` Abhinav Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c35f577-2124-4f80-a5d3-542b47ed6825@quicinc.com \
    --to=quic_abhinavk@quicinc.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marijn.suijten@somainline.org \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=simona.vetter@ffwll.ch \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®