Message ID | 20240223223958.3887423-1-hsinyi@chromium.org |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-79273-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp880133dyb; Fri, 23 Feb 2024 14:40:23 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXyBBB/GiSo5y/aBhczvcSotTvis4S2lf9y6PDUg+va0qsBexZb97r9EhiOpzfkWE4GR1VnDOPXtNUU4diNzReZJIzW3g== X-Google-Smtp-Source: AGHT+IF+lCXD0jLbNZywjOnff3mdLaqXR02C1tM+XwklDv4g1Tl7403T2nWgh/fgqt9A16CGXI2f X-Received: by 2002:ad4:5946:0:b0:68f:5c66:a92f with SMTP id eo6-20020ad45946000000b0068f5c66a92fmr1349789qvb.45.1708728022808; Fri, 23 Feb 2024 14:40:22 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708728022; cv=pass; d=google.com; s=arc-20160816; b=TJKSakBxdlssyzQm7cpaMGUYcAklNUd5GoeVnfmrle3A0c6qwvbdpUmfw9jgPr039g 8ZNlFzdbGZXNRbDbU7NQEtt8DpyHC9I36LfeLIujKrUlrTNDTyDtACMBNvgpE/kmaIvt 14c7vUNrun/UJG+6e9jvZKK/b2on/mJNmrySdl/vrsrhB6UvtzRm6AfvhL6fSlsRg29Q 2xgQ3yfamk6YKrCsw0QmH4J8lhfCxpNDvsiPfgL9sXAg5/fsW7k+lIWnaqPwWmA+teM3 4ad5vOTY1iBrTv3HlWxAUHJN+4v3Ila41ptNn9ZEllEFYwVEviNvokjkaRMBzCAQYSs9 qXgQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=izkBVtvZeid9EW6DkeQXaaTaSvfcQ1H0IJ+Swz72A+s=; fh=BERBmgHG6IqAfhxg9QcKtwjxQCn41SXg8K+tzCVDkoU=; b=RWDd6+KmBZ0abIaER+DzMwPAB3TuPwm39qJ8/YnPgkCdkb39OaOyIM7Itnd/bxVxNX AICEF9+uadJwvxXAQc38nOyfK9L4Ja8ynLMghnkaMIBFa/TxXQy5wdhq9u2ErU72b558 GpzjVEiTpM52Y6Rz0lAprOZR7Aw3mcvWTXG1D/NFVfcOBiIxLTQEZ+xPysQYFS5d0ZSE K81VwU98xR9eRJr+YPpeWepxNFodtkRqj0D5CCB+qWNagQEDsJRb0xu2qM6cEm51kxoG q3JIJUWNzchb5+FsRNzOCkgx+bKFEu190YWh69q04aHbqjtvq7bNfJuVgp88oOwy74lc I6Pw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=iPCLuslI; arc=pass (i=1 spf=pass spfdomain=chromium.org dkim=pass dkdomain=chromium.org dmarc=pass fromdomain=chromium.org); spf=pass (google.com: domain of linux-kernel+bounces-79273-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-79273-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id jp15-20020ad45f8f000000b0068fb8232dc1si874960qvb.519.2024.02.23.14.40.22 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 14:40:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-79273-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=iPCLuslI; arc=pass (i=1 spf=pass spfdomain=chromium.org dkim=pass dkdomain=chromium.org dmarc=pass fromdomain=chromium.org); spf=pass (google.com: domain of linux-kernel+bounces-79273-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-79273-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 845BA1C20DAF for <ouuuleilei@gmail.com>; Fri, 23 Feb 2024 22:40:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AF45414DFE0; Fri, 23 Feb 2024 22:40:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="iPCLuslI" Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8CDBF38FA1 for <linux-kernel@vger.kernel.org>; Fri, 23 Feb 2024 22:40:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708728005; cv=none; b=XnPbv7DZuiJk2qDbH1j0yEd5wMHXOaSBgTOnKR+gUmoKq93PTmhCZe6k0ht7pEa4BWCOtEBNr09Q+vOZm/NlcQxSgF2x+5J6pbnA5i2RzhBRMHGi6scnNyAzCaduUlL8+WZFmnppv38bEksFzl1AN4fSAVyrDu5Efj2FId96cns= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708728005; c=relaxed/simple; bh=vi82t7F67vWmb9wn1/YBBQ4WZjEbzfWwx0aAy75cEkw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=XR5jYY/Ftha89MrcCdlgleytHul5mPsbIauuuvVncp+g7to6GowTEF17k8QLZ6WMG8h6v1EHF24VaGbhErwZEZawa9L5n/b42bl6EeISpF5Bt4KAuNlSYB1N1eW3M6fmWIJdx0qhy/zIinT9nlPZXR4Bm2uZ4GtAAEJ1bJjI89I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=iPCLuslI; arc=none smtp.client-ip=209.85.215.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-5d8b887bb0cso729966a12.2 for <linux-kernel@vger.kernel.org>; Fri, 23 Feb 2024 14:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1708728003; x=1709332803; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=izkBVtvZeid9EW6DkeQXaaTaSvfcQ1H0IJ+Swz72A+s=; b=iPCLuslI9iTXUDpMy+ekI3bgqPVDfqklwTCx/SW0xEtpXM/kyTnMjcctgOXWlOnONk k8eYsCqSbK/tSzLhOnAxRybQ2BuxI08nydh9J2eHSdGcVi7K5cqcSa5+NUPrs+WdWmji YJRk6MjVPwvk+NrRW8HtHeaFRtMTWgHeBVEMo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708728003; x=1709332803; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=izkBVtvZeid9EW6DkeQXaaTaSvfcQ1H0IJ+Swz72A+s=; b=kcrJfXXJ8M+EMmLasFTd420qwX2bAxTt05FcojREQOPdARyACEHA4O9OLCduFhCoY0 iinQjxbK/eSEYM44p3869hwB9plCTTk+3sk1siAfzCXml1CW2Ww/HVLpei7aYr5ExuIH q0Rv/m6BLIdrKxdRPc/7+6BQBOm4NlE3tO9Ccg1YjgM/xsFwgNKBjdq0eW7eECFjczeh Zc2l5PHfoUJuKTvA03ECpvBylLxE1c+DwGnCpdIou5RntOZpiCBG6ngrRwSw4xxczc6J alwdThWnWEGlcjQdK4uLpBYMRQL+MF8LPAguhS4lmKPZ9g007YjGC4kfgt2k2j7ApL5z 0Y+Q== X-Forwarded-Encrypted: i=1; AJvYcCWStgk7nZWPcjHogiRXWB0irO/vqKDhe3zN2GlNyhdLK8cIDpdLgY0ZNT64AYqw1EuZ/kIIIFgFT+lySL8VHPaxSwRHFjEetQUmqukb X-Gm-Message-State: AOJu0Yw0dUFLQWbmw5f5EiW6rDZRnAhSD/Uc/MJGsuXuAIlpuMow8z3Q jbxSHyyB8cRwLF7ykrvM75RR9y4u8yF2V1Ui+SP90RrML1gzZ0W+LoXwsiNUow== X-Received: by 2002:a17:90a:fb4f:b0:29a:8b5a:892a with SMTP id iq15-20020a17090afb4f00b0029a8b5a892amr1200115pjb.39.1708728002781; Fri, 23 Feb 2024 14:40:02 -0800 (PST) Received: from hsinyi.sjc.corp.google.com ([2620:15c:9d:2:8ff9:a089:c05c:9af]) by smtp.gmail.com with ESMTPSA id cz4-20020a17090ad44400b002966a13f2e9sm2032873pjb.37.2024.02.23.14.40.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 14:40:02 -0800 (PST) From: Hsin-Yi Wang <hsinyi@chromium.org> To: Douglas Anderson <dianders@chromium.org> Cc: Neil Armstrong <neil.armstrong@linaro.org>, Jessica Zhang <quic_jesszhan@quicinc.com>, Sam Ravnborg <sam@ravnborg.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/2] Match panel hash for overridden mode Date: Fri, 23 Feb 2024 14:29:16 -0800 Message-ID: <20240223223958.3887423-1-hsinyi@chromium.org> X-Mailer: git-send-email 2.44.0.rc0.258.g7320e95886-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791731195198809497 X-GMAIL-MSGID: 1791731195198809497 |
Series |
Match panel hash for overridden mode
|
|
Message
Hsin-Yi Wang
Feb. 23, 2024, 10:29 p.m. UTC
This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add auo_b116xa3_mode""). It's found that 2 different AUO panels use the same product id. One of them requires an overridden mode, while the other should use the mode directly from edid. Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended to check the crc hash of the entire edid base block. Hsin-Yi Wang (2): drm_edid: Add a function to get EDID base block drm/panel: panel-edp: Match with panel hash for overridden modes drivers/gpu/drm/drm_edid.c | 55 +++++++++++++++------------- drivers/gpu/drm/panel/panel-edp.c | 60 ++++++++++++++++++++++++++----- include/drm/drm_edid.h | 3 +- 3 files changed, 84 insertions(+), 34 deletions(-)
Comments
On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same > product id. One of them requires an overridden mode, while the other should > use the mode directly from edid. > > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended > to check the crc hash of the entire edid base block. Do you have these EDIDs posted somewhere? Can we use something less cryptic than hash for matching the panel, e.g. strings from Monitor Descriptors? > > Hsin-Yi Wang (2): > drm_edid: Add a function to get EDID base block > drm/panel: panel-edp: Match with panel hash for overridden modes > > drivers/gpu/drm/drm_edid.c | 55 +++++++++++++++------------- > drivers/gpu/drm/panel/panel-edp.c | 60 ++++++++++++++++++++++++++----- > include/drm/drm_edid.h | 3 +- > 3 files changed, 84 insertions(+), 34 deletions(-) > > -- > 2.44.0.rc0.258.g7320e95886-goog >
Hi, On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add > > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same > > product id. One of them requires an overridden mode, while the other should > > use the mode directly from edid. > > > > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended > > to check the crc hash of the entire edid base block. > > Do you have these EDIDs posted somewhere? Can we use something less > cryptic than hash for matching the panel, e.g. strings from Monitor > Descriptors? We could try it if need be. I guess I'm worried that if panel vendors ended up re-using the panel ID for two different panels that they might also re-use the name field too. Hashing the majority of the descriptor's base block makes us more likely not to mix two panels up. In general it feels like the goal is that if there is any doubt that we shouldn't override the mode and including more fields in the hash works towards that goal. I guess one thing that might help would be to make it a policy that any time a panel is added to this list that a full EDID is included in the commit message. That would mean that if we ever needed to change things we could. What do you think? That being said, if everyone thinks that the "name" field is enough, we could do it. I think that in the one case that we ran into it would have been enough... -Doug
On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add > > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same > > product id. One of them requires an overridden mode, while the other should > > use the mode directly from edid. > > > > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended > > to check the crc hash of the entire edid base block. > > Do you have these EDIDs posted somewhere? Can we use something less > cryptic than hash for matching the panel, e.g. strings from Monitor > Descriptors? > Panel 1: 00 ff ff ff ff ff ff 00 06 af 5c 40 00 00 00 00 00 1a 01 04 95 1a 0e 78 02 99 85 95 55 56 92 28 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 12 1b 56 5a 50 00 19 30 30 20 46 00 00 90 10 00 00 18 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 31 36 58 41 4b 30 31 2e 30 20 0a 00 cc ---------------- Block 0, Base EDID: EDID Structure Version & Revision: 1.4 Vendor & Product Identification: Manufacturer: AUO Model: 16476 Made in: 2016 Basic Display Parameters & Features: Digital display Bits per primary color channel: 6 DisplayPort interface Maximum image size: 26 cm x 14 cm Gamma: 2.20 Supported color formats: RGB 4:4:4 First detailed timing includes the native pixel format and preferred refresh rate Color Characteristics: Red : 0.5839, 0.3330 Green: 0.3378, 0.5712 Blue : 0.1582, 0.1328 White: 0.3134, 0.3291 Established Timings I & II: none Standard Timings: none Detailed Timing Descriptors: DTD 1: 1366x768 60.020 Hz 683:384 47.596 kHz 69.300 MHz (256 mm x 144 mm) Hfront 48 Hsync 32 Hback 10 Hpol N Vfront 4 Vsync 6 Vback 15 Vpol N Manufacturer-Specified Display Descriptor (0x0f): 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 20 '............... ' Alphanumeric Data String: 'AUO' Alphanumeric Data String: 'B116XAK01.0 ' Checksum: 0xcc Panel 2: 00 ff ff ff ff ff ff 00 06 af 5c 40 00 00 00 00 00 19 01 04 95 1a 0e 78 02 99 85 95 55 56 92 28 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ce 1d 56 ea 50 00 1a 30 30 20 46 00 00 90 10 00 00 18 d4 17 56 ea 50 00 1a 30 30 20 46 00 00 90 10 00 00 18 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 31 36 58 41 4e 30 34 2e 30 20 0a 00 94 ---------------- Block 0, Base EDID: EDID Structure Version & Revision: 1.4 Vendor & Product Identification: Manufacturer: AUO Model: 16476 Made in: 2015 Basic Display Parameters & Features: Digital display Bits per primary color channel: 6 DisplayPort interface Maximum image size: 26 cm x 14 cm Gamma: 2.20 Supported color formats: RGB 4:4:4 First detailed timing includes the native pixel format and preferred refresh rate Color Characteristics: Red : 0.5839, 0.3330 Green: 0.3378, 0.5712 Blue : 0.1582, 0.1328 White: 0.3134, 0.3291 Established Timings I & II: none Standard Timings: none Detailed Timing Descriptors: DTD 1: 1366x768 60.059824 Hz 683:384 47.688 kHz 76.300000 MHz (256 mm x 144 mm) Hfront 48 Hsync 32 Hback 154 Hpol N Vfront 4 Vsync 6 Vback 16 Vpol N DTD 2: 1366x768 48.016373 Hz 683:384 38.125 kHz 61.000000 MHz (256 mm x 144 mm) Hfront 48 Hsync 32 Hback 154 Hpol N Vfront 4 Vsync 6 Vback 16 Vpol N Alphanumeric Data String: 'AUO' Alphanumeric Data String: 'B116XAN04.0 ' Checksum: 0x94 In this example, Descriptors can also be used to distinguish. But it's possible that the name field is also reused by mistake, for the same reason as model id is reused. > > > > Hsin-Yi Wang (2): > > drm_edid: Add a function to get EDID base block > > drm/panel: panel-edp: Match with panel hash for overridden modes > > > > drivers/gpu/drm/drm_edid.c | 55 +++++++++++++++------------- > > drivers/gpu/drm/panel/panel-edp.c | 60 ++++++++++++++++++++++++++----- > > include/drm/drm_edid.h | 3 +- > > 3 files changed, 84 insertions(+), 34 deletions(-) > > > > -- > > 2.44.0.rc0.258.g7320e95886-goog > > > > > -- > With best wishes > Dmitry
On Tue, 27 Feb 2024 at 03:00, Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov > <dmitry.baryshkov@linaro.org> wrote: > > > > On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add > > > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same > > > product id. One of them requires an overridden mode, while the other should > > > use the mode directly from edid. > > > > > > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended > > > to check the crc hash of the entire edid base block. > > > > Do you have these EDIDs posted somewhere? Can we use something less > > cryptic than hash for matching the panel, e.g. strings from Monitor > > Descriptors? > > We could try it if need be. I guess I'm worried that if panel vendors > ended up re-using the panel ID for two different panels that they > might also re-use the name field too. Hashing the majority of the > descriptor's base block makes us more likely not to mix two panels up. > In general it feels like the goal is that if there is any doubt that > we shouldn't override the mode and including more fields in the hash > works towards that goal. My main concern is that hash (or crc) is a non-obvious thing: even if we have EDID in the commit message, it takes some effort to calculate the value. If for any reason we decide to change the hashed bytes (e.g. by dropping any of the fields) it will be an error-prone process to update existing hash values. On the contrary, the 'strings' are easy to check / compare without any additional tools. > > I guess one thing that might help would be to make it a policy that > any time a panel is added to this list that a full EDID is included in > the commit message. That would mean that if we ever needed to change > things we could. What do you think? Definitely, that sounds like a good idea. > That being said, if everyone thinks that the "name" field is enough, > we could do it. I think that in the one case that we ran into it would > have been enough... Yes, I'd suggest using the string unless at some point we see two panels sharing both panel_id and names.
On Tue, 27 Feb 2024 at 03:10, Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov > <dmitry.baryshkov@linaro.org> wrote: > > > > On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add > > > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same > > > product id. One of them requires an overridden mode, while the other should > > > use the mode directly from edid. > > > > > > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended > > > to check the crc hash of the entire edid base block. > > > > Do you have these EDIDs posted somewhere? Can we use something less > > cryptic than hash for matching the panel, e.g. strings from Monitor > > Descriptors? > > > > Panel 1: > > 00 ff ff ff ff ff ff 00 06 af 5c 40 00 00 00 00 > 00 1a 01 04 95 1a 0e 78 02 99 85 95 55 56 92 28 > 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 > 01 01 01 01 01 01 12 1b 56 5a 50 00 19 30 30 20 > 46 00 00 90 10 00 00 18 00 00 00 0f 00 00 00 00 > 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 > 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe > 00 42 31 31 36 58 41 4b 30 31 2e 30 20 0a 00 cc > > ---------------- > > Block 0, Base EDID: > EDID Structure Version & Revision: 1.4 > Vendor & Product Identification: > Manufacturer: AUO > Model: 16476 > Made in: 2016 > Basic Display Parameters & Features: > Digital display > Bits per primary color channel: 6 > DisplayPort interface > Maximum image size: 26 cm x 14 cm > Gamma: 2.20 > Supported color formats: RGB 4:4:4 > First detailed timing includes the native pixel format and > preferred refresh rate > Color Characteristics: > Red : 0.5839, 0.3330 > Green: 0.3378, 0.5712 > Blue : 0.1582, 0.1328 > White: 0.3134, 0.3291 > Established Timings I & II: none > Standard Timings: none > Detailed Timing Descriptors: > DTD 1: 1366x768 60.020 Hz 683:384 47.596 kHz 69.300 MHz > (256 mm x 144 mm) > Hfront 48 Hsync 32 Hback 10 Hpol N > Vfront 4 Vsync 6 Vback 15 Vpol N > Manufacturer-Specified Display Descriptor (0x0f): 00 0f 00 00 00 > 00 00 00 00 00 00 00 00 00 00 20 '............... ' > Alphanumeric Data String: 'AUO' > Alphanumeric Data String: 'B116XAK01.0 ' > Checksum: 0xcc > > > Panel 2: > > 00 ff ff ff ff ff ff 00 06 af 5c 40 00 00 00 00 > 00 19 01 04 95 1a 0e 78 02 99 85 95 55 56 92 28 > 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 > 01 01 01 01 01 01 ce 1d 56 ea 50 00 1a 30 30 20 > 46 00 00 90 10 00 00 18 d4 17 56 ea 50 00 1a 30 > 30 20 46 00 00 90 10 00 00 18 00 00 00 fe 00 41 > 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe > 00 42 31 31 36 58 41 4e 30 34 2e 30 20 0a 00 94 > > ---------------- > > Block 0, Base EDID: > EDID Structure Version & Revision: 1.4 > Vendor & Product Identification: > Manufacturer: AUO > Model: 16476 > Made in: 2015 > Basic Display Parameters & Features: > Digital display > Bits per primary color channel: 6 > DisplayPort interface > Maximum image size: 26 cm x 14 cm > Gamma: 2.20 > Supported color formats: RGB 4:4:4 > First detailed timing includes the native pixel format and > preferred refresh rate > Color Characteristics: > Red : 0.5839, 0.3330 > Green: 0.3378, 0.5712 > Blue : 0.1582, 0.1328 > White: 0.3134, 0.3291 > Established Timings I & II: none > Standard Timings: none > Detailed Timing Descriptors: > DTD 1: 1366x768 60.059824 Hz 683:384 47.688 kHz > 76.300000 MHz (256 mm x 144 mm) > Hfront 48 Hsync 32 Hback 154 Hpol N > Vfront 4 Vsync 6 Vback 16 Vpol N > DTD 2: 1366x768 48.016373 Hz 683:384 38.125 kHz > 61.000000 MHz (256 mm x 144 mm) > Hfront 48 Hsync 32 Hback 154 Hpol N > Vfront 4 Vsync 6 Vback 16 Vpol N > Alphanumeric Data String: 'AUO' > Alphanumeric Data String: 'B116XAN04.0 ' > Checksum: 0x94 > > In this example, Descriptors can also be used to distinguish. But it's > possible that the name field is also reused by mistake, for the same > reason as model id is reused. Thank you! Let's settle the discussion at the cover letter. > > > > > > > > Hsin-Yi Wang (2): > > > drm_edid: Add a function to get EDID base block > > > drm/panel: panel-edp: Match with panel hash for overridden modes > > > > > > drivers/gpu/drm/drm_edid.c | 55 +++++++++++++++------------- > > > drivers/gpu/drm/panel/panel-edp.c | 60 ++++++++++++++++++++++++++----- > > > include/drm/drm_edid.h | 3 +- > > > 3 files changed, 84 insertions(+), 34 deletions(-) > > > > > > -- > > > 2.44.0.rc0.258.g7320e95886-goog > > > > > > > > > -- > > With best wishes > > Dmitry