From nobody Sun Dec 14 19:29:41 2025 Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 705CE255E4D for ; Mon, 21 Apr 2025 06:49:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.254.224.33 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745218201; cv=none; b=lB5oPa/dBuPP6lEUn60puqpIx96qzyxHkNor0+JlgZsVSIWU0Mzg3adU+8O4kSSAc4vE1ovDBKrS2r1LKed2ozGGqXPjJHrFWkaFU1e6aMp2Cay/2drxpgQYbho0P9OVKDEjU3zFYawn64HXL5L8Oo+GsId+GdauGPjJQ/MGqlc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745218201; c=relaxed/simple; bh=J8gfubvR8xdU8KhWSrCT1xjBe9lNsAVzMtr72P9J4Tc=; h=Mime-Version:Subject:From:To:CC:In-Reply-To:Message-ID:Date: Content-Type:References; b=c0p9Gjw26CjrdO4qusY368kmo9VKbLYlpRvO+O5AhUxrTHKi8MHXN6NzrEzRp3fm5+oF/Tc4uY6QidMCuFxYoABIR5BMXH913iJKFXzmnCy8gS96D2c1z5vlrqh+haJJLlzIHSbi010zQnd0e7eNh0YIP/iFRMsEfHg3vrsoGeU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com; spf=pass smtp.mailfrom=samsung.com; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b=j1xXU1TQ; arc=none smtp.client-ip=203.254.224.33 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=samsung.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="j1xXU1TQ" Received: from epcas5p4.samsung.com (unknown [182.195.41.42]) by mailout3.samsung.com (KnoxPortal) with ESMTP id 20250421064953epoutp0305496382b9c367cfd70180e85cfb215e~4QrM5e0eI1397513975epoutp03W for ; Mon, 21 Apr 2025 06:49:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout3.samsung.com 20250421064953epoutp0305496382b9c367cfd70180e85cfb215e~4QrM5e0eI1397513975epoutp03W DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1745218193; bh=6E/7VFpyvsMUlIQaY+I45HAEDDr2hRhsdBc9fxsVaO4=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=j1xXU1TQIKMbjNg+hAr84gXkb7ydpPW1Rw77624q50UUGDriA/iNrfBATUKdWx6sO E555tSzi0MRk4xrceohbvUF1FsOVnY5RSEjjEJVYZ+wLLURksHlQUucLFy1nTRrkME kPGzGZefz/pcnZH8b/G3Fgd1HXCfSkaQ8NZThgnE= Received: from epsnrtp03.localdomain (unknown [182.195.42.155]) by epcas5p3.samsung.com (KnoxPortal) with ESMTPS id 20250421064952epcas5p3f0f1267aea243c0043c1618cb44a381a~4QrMWK6Gm2773527735epcas5p3r; Mon, 21 Apr 2025 06:49:52 +0000 (GMT) Received: from epcas5p4.samsung.com (unknown [182.195.41.42]) by epsnrtp03.localdomain (Postfix) with ESMTP id 4ZgwwJ3cVBz3hhTP; Mon, 21 Apr 2025 06:49:52 +0000 (GMT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Subject: RE: Re: [PATCH] drm/edid: fixed the bug that hdr metadata was not cleared Reply-To: feijuan.li@samsung.com Sender: =?UTF-8?B?5p2O6aOe5aif?= From: =?UTF-8?B?5p2O6aOe5aif?= To: Jani Nikula , =?UTF-8?B?5p2O6aOe5aif?= , "jingoohan1@gmail.com" , "maarten.lankhorst@linux.intel.com" , "mripard@kernel.org" , "tzimmermann@suse.de" , "airlied@gmail.com" , "simona@ffwll.ch" , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" CC: =?UTF-8?B?5ZSQ57qi6aOe?= , =?UTF-8?B?5Lil5piO6LS1?= , =?UTF-8?B?546L55Cq55Cz?= X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: <87cydbp5gs.fsf@intel.com> X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20250421064952epcms5p50fcd97121f3b977d561e41b858e3ae21@epcms5p5> Date: Mon, 21 Apr 2025 15:49:52 +0900 X-CMS-MailID: 20250421064952epcms5p50fcd97121f3b977d561e41b858e3ae21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" CMS-TYPE: 105P X-CMS-RootMailID: 20250416093607epcms5p344bcffd7430fe5e30ef9b73db73f7388 References: <87cydbp5gs.fsf@intel.com> <20250416093607epcms5p344bcffd7430fe5e30ef9b73db73f7388@epcms5p3> From 7da04ef9ba0c201e7817a21f8c4a1bf88973c8b9 Mon Sep 17 00:00:00 2001 From: "feijuan.li" Date: Fri, 18 Apr 2025 14:56:49 +0000 Subject: [PATCH] drm/edid: fixed the bug that hdr metadata was not reset When DP connected to a device with HDR capability, the hdr structure was filled.Then connected to another sink device without hdr capability, but the hdr info still exist. Signed-off-by: feijuan.li --- drivers/gpu/drm/drm_edid.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 13bc4c290b17..cd0e4148f6b0 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -6576,6 +6576,11 @@ static void drm_update_mso(struct drm_connector *con= nector, displayid_iter_end(&iter); } =20 +static void drm_reset_hdr_sink_metadata(struct drm_connector *connector) +{ + memset(&connector->hdr_sink_metadata, 0, sizeof(connector->hdr_sink_metad= ata)); +} + /* A connector has no EDID information, so we've got no EDID to compute qu= irks from. Reset * all of the values which would have been set from EDID */ @@ -6651,6 +6656,7 @@ static void update_display_info(struct drm_connector = *connector, struct drm_display_info *info =3D &connector->display_info; const struct edid *edid; =20 + drm_reset_hdr_sink_metadata(connector); drm_reset_display_info(connector); clear_eld(connector); =20 --=20 2.25.1 I changed the patch, not to avoid other functions.pls check. BR~ feijuan =C2=A0 --------- Original Message --------- Sender : Jani Nikula Date : 2025-04-17 17:17 (GMT+9) Title : Re: [PATCH] drm/edid: fixed the bug that hdr metadata was not clear= ed =C2=A0 On Wed, 16 Apr 2025, =E6=9D=8E=E9=A3=9E=E5=A8=9F w= rote: > From a34a1e2dd7aacd45f18775564fce12b03ae4009c Mon Sep 17 00:00:00 2001 > From: "feijuan.li" > Date: Wed, 16 Apr 2025 11:07:39 +0000 > Subject: [PATCH] drm/edid: fixed the bug that hdr metadata was not cleared > > When DP connected to a device with HDR capability, > the hdr structure was filled.Then connected to another > sink device without hdr capability, but the hdr info > still exist. > > Signed-off-by: feijuan.li > --- >=C2=A0 drivers/gpu/drm/drm_edid.c 1 + >=C2=A0 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 13bc4c290b17..5cf5d30321b6 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -5607,6 +5607,7 @@ static void clear_eld(struct drm_connector *connect= or) >=C2=A0 { >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mutex_lock(&connector->eld_mutex); >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memset(connector->eld, 0, sizeof(connect= or->eld)); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0memset(&connector->hdr_sink_metadata, 0, siz= eof(connector->hdr_sink_metadata)); hdr_sink_metadata is not related to ELD, and should not be cleared within clear_eld(). I think this should be cleared in drm_reset_display_info(), and long-term fields like this should be moved within display info. BR, Jani. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mutex_unlock(&connector->eld_mutex); >=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connector->latency_present[0] =3D false; -- Jani Nikula, Intel