From: Liu Ying <victor.liu@nxp.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"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>,
"Rob Clark" <robin.clark@oss.qualcomm.com>,
"Dmitry Baryshkov" <lumag@kernel.org>,
"Abhinav Kumar" <abhinav.kumar@linux.dev>,
"Jessica Zhang" <jessica.zhang@oss.qualcomm.com>,
"Sean Paul" <sean@poorly.run>,
"Marijn Suijten" <marijn.suijten@somainline.org>,
"Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Samuel Holland" <samuel@sholland.org>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v2 3/9] drm/bridge: ite-it6263: handle unsupported InfoFrames
Date: Mon, 29 Sep 2025 17:10:59 +0800 [thread overview]
Message-ID: <6db3337a-ba59-4901-b0e2-2b0b93c8a4e7@nxp.com> (raw)
In-Reply-To: <y3sndmfnwtljkbrssyycg6scjujt4kkjfo3gjclo3suzvqdahl@bdrdzmiolcb4>
On 09/29/2025, Dmitry Baryshkov wrote:
> On Mon, Sep 29, 2025 at 03:56:31PM +0800, Liu Ying wrote:
>> On 09/28/2025, Dmitry Baryshkov wrote:
>>> Make hdmi_write_hdmi_infoframe() and hdmi_clear_infoframe() callbacks
>>> return -EOPNOTSUPP for unsupported InfoFrames and make sure that
>>> atomic_check() callback doesn't allow unsupported InfoFrames to be
>>> enabled.
>>>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>> drivers/gpu/drm/bridge/ite-it6263.c | 27 +++++++++++++++++++++++++--
>>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/ite-it6263.c b/drivers/gpu/drm/bridge/ite-it6263.c
>>> index 2eb8fba7016cbf0dcb19aec4ca8849f1fffaa64c..cf3d76d748dde51e93b2b19cc2cbe023ca2629b8 100644
>>> --- a/drivers/gpu/drm/bridge/ite-it6263.c
>>> +++ b/drivers/gpu/drm/bridge/ite-it6263.c
>>> @@ -26,6 +26,7 @@
>>> #include <drm/drm_crtc.h>
>>> #include <drm/drm_edid.h>
>>> #include <drm/drm_of.h>
>>> +#include <drm/drm_print.h>
>>> #include <drm/drm_probe_helper.h>
>>>
>>> /* -----------------------------------------------------------------------------
>>> @@ -772,7 +773,7 @@ static int it6263_hdmi_clear_infoframe(struct drm_bridge *bridge,
>>> regmap_write(it->hdmi_regmap, HDMI_REG_PKT_NULL_CTRL, 0);
>>> break;
>>> default:
>>> - dev_dbg(it->dev, "unsupported HDMI infoframe 0x%x\n", type);
>>> + return -EOPNOTSUPP;
>>> }
>>>
>>> return 0;
>>> @@ -812,13 +813,35 @@ static int it6263_hdmi_write_infoframe(struct drm_bridge *bridge,
>>> ENABLE_PKT | REPEAT_PKT);
>>> break;
>>> default:
>>> - dev_dbg(it->dev, "unsupported HDMI infoframe 0x%x\n", type);
>>> + return -EOPNOTSUPP;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> +static int it6263_bridge_atomic_check(struct drm_bridge *bridge,
>>> + struct drm_bridge_state *bridge_state,
>>> + struct drm_crtc_state *crtc_state,
>>> + struct drm_connector_state *conn_state)
>>> +{
>>> + /* not supported by the driver */
>>> + conn_state->hdmi.infoframes.spd.set = false;
>>> +
>>> + /* should not happen, audio support not enabled */
>>> + if (drm_WARN_ON_ONCE(bridge->encoder->dev,
>>> + conn_state->connector->hdmi.infoframes.audio.set))
>>
>> Maybe use drm_err_once() instead to provide the reason for the warning in
>> a string?
>
> I can change all of them to drm_err_once(), sure.
With those changed,
Acked-by: Liu Ying <victor.liu@nxp.com>
>
>>
>>> + return -EOPNOTSUPP;
>>
>> As this check could return error, it should be moved before
>> 'conn_state->hdmi.infoframes.spd.set = false;' to gain a little performance.
>
> I'd say, it would be negligible.
Fine, up to you :)
>
>>
>>> +
>>> + /* should not happen, HDR support not enabled */
>>> + if (drm_WARN_ON_ONCE(bridge->encoder->dev,
>>> + conn_state->hdmi.infoframes.hdr_drm.set))
>>> + return -EOPNOTSUPP;
>>
>> I don't think IT6263 chip supports DRM infoframe. The drm_WARN_ON_ONCE()
>> call could make driver readers think that DRM infoframe could be enabled
>> in the future as audio infoframe has the same warning and IT6263 chip does
>> support audio infoframe. So, maybe:
>>
>> /* IT6263 chip doesn't support DRM infoframe. */
>> conn_state->hdmi.infoframes.hdr_drm.set = false;
>
> I'd rather not do that. My point here was that the driver can not end up
> in the state where this frame is enabled, because it can only happen if
> the driver sets max_bpc (which it doesn't). Likewise Audio InfoFrame can
> not get enabled because the driver doesn't call into audio functions. On
> the contrary, SPD frame (or HDMI in several other drivers) can be
> enabled by the framework, so we silently turn then off here.
Ditto.
>
>>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static const struct drm_bridge_funcs it6263_bridge_funcs = {
>>> + .atomic_check = it6263_bridge_atomic_check,
>>> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
>>> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
>>> .atomic_reset = drm_atomic_helper_bridge_reset,
>>>
>>
>>
>> --
>> Regards,
>> Liu Ying
>
--
Regards,
Liu Ying
next prev parent reply other threads:[~2025-09-29 9:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-28 8:24 [PATCH v2 0/9] drm/connector: hdmi: limit infoframes per driver capabilities, second approach Dmitry Baryshkov
2025-09-28 8:24 ` [PATCH v2 1/9] drm/display: hdmi-state-helpers: warn on unsupported InfoFrame types Dmitry Baryshkov
2025-10-03 13:03 ` Maxime Ripard
2025-09-28 8:24 ` [PATCH v2 2/9] drm/bridge: adv7511: handle unsupported InfoFrames Dmitry Baryshkov
2025-10-03 13:06 ` Maxime Ripard
2025-09-28 8:24 ` [PATCH v2 3/9] drm/bridge: ite-it6263: " Dmitry Baryshkov
2025-09-29 7:56 ` Liu Ying
2025-09-29 8:58 ` Dmitry Baryshkov
2025-09-29 9:10 ` Liu Ying [this message]
2025-09-28 8:24 ` [PATCH v2 4/9] drm/bridge: lontium-lt9611: " Dmitry Baryshkov
2025-09-28 8:24 ` [PATCH v2 5/9] drm/bridge: synopsys/dw-hdmi-qp: " Dmitry Baryshkov
2025-09-28 8:24 ` [PATCH v2 6/9] drm/msm: hdmi: " Dmitry Baryshkov
2025-09-28 8:24 ` [PATCH v2 7/9] drm/rockchip: rk3066_hdmi: " Dmitry Baryshkov
2025-09-28 8:24 ` [PATCH v2 8/9] drm/rockchip: inno-hdmi: " Dmitry Baryshkov
2025-09-28 8:24 ` [PATCH v2 9/9] drm/sun4i: hdmi: " Dmitry Baryshkov
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=6db3337a-ba59-4901-b0e2-2b0b93c8a4e7@nxp.com \
--to=victor.liu@nxp.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=jernej.skrabec@gmail.com \
--cc=jessica.zhang@oss.qualcomm.com \
--cc=jonas@kwiboo.se \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=lumag@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=robin.clark@oss.qualcomm.com \
--cc=samuel@sholland.org \
--cc=sean@poorly.run \
--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