Received: by 2002:a89:2c3:0:b0:1ed:23cc:44d1 with SMTP id d3csp88791lqs; Mon, 4 Mar 2024 16:19:21 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVzFHTRqOfH3D7q8zTmtWOeGvFR7l1AFMWKCMLHd/EjrDYkqSluZ/HagX+M++7DmvE40xX7MjExux0ODTzJF+0l006ZJtKLyJe8gmdeEg== X-Google-Smtp-Source: AGHT+IGl4m6kQDdE499IIo7Cz0i1XQcYUwLHELdzz8EUZ9yxqCrLI/+lA62SxhsLw4y0h3XpIaoJ X-Received: by 2002:a05:6a20:938f:b0:1a1:4ca5:86cf with SMTP id x15-20020a056a20938f00b001a14ca586cfmr343402pzh.12.1709597961357; Mon, 04 Mar 2024 16:19:21 -0800 (PST) Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id h26-20020a63575a000000b005df42c5313bsi9145381pgm.16.2024.03.04.16.19.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 16:19:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-91443-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@chromium.org header.s=google header.b=Fyc1zZPx; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-91443-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-91443-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (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 sv.mirrors.kernel.org (Postfix) with ESMTPS id EED9928348E for ; Tue, 5 Mar 2024 00:19:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6B54D1C06; Tue, 5 Mar 2024 00:19:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Fyc1zZPx" Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 6CF4A647 for ; Tue, 5 Mar 2024 00:18:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709597940; cv=none; b=q0SrPbVC6usp1R0OYepEWuKoYZ5YmuK5VFshQsYUBq0eTbNqPmoLavhK+S6lkPxCNLZosgkZbkftWRt2QePKh7wiaWxXwuflPQC/xo6rUMPxVkKbJx4FO90yqhu8H7jop1AynDzPLbuq7QoTBc+yGFo50Zwkk52Zc0WhYGU9uK8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709597940; c=relaxed/simple; bh=LzdohdDpDDid/57kXe8/kfp8grCNy+QawIdLdHzUHmE=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=lw2T/CfLBfBaWDvEvM+U+A2YhyXoLOA1TgH4/rdzNrJ8gStYzXUn3RfKkRd+mdyL08YOVwAgihgjs2Stz9dicYKf3bG+pkfeSDZMmdAeqe0ZTrJ7mtCi+Wrq0zcnMRqzIrYQrwO8eGS24vnqg7lv6gg9iuWEqYEiS1I9NIbU6RE= 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=Fyc1zZPx; arc=none smtp.client-ip=209.85.210.54 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-ot1-f54.google.com with SMTP id 46e09a7af769-6e4a0e80d14so3788001a34.1 for ; Mon, 04 Mar 2024 16:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709597937; x=1710202737; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=swn12VaGynTrjKnCX7p5SdN+ZnxqYXUx6V579Vptc8k=; b=Fyc1zZPxFNJqOVVX1i4GQnhF85onAe3eeKDnySXcitXlmoPBmvh0lLTpJRc0fpnWAJ TY/Lxw5SesZ7yL6BP+RbDd2SvmQfv+9qMEdiUC72DDUN6CzLPON11a9v6Tbj55wqDwOB 4Asi8XrkiLiR5myvVHZfThlqmcVxo5yz7G2Sc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709597937; x=1710202737; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=swn12VaGynTrjKnCX7p5SdN+ZnxqYXUx6V579Vptc8k=; b=NypZ+GCQD9hUovay0eDaBYDiphkPbE2/esw7ZUcUWBb1Djgs7FJ/v9VLIkWn+4q3Q+ 6UNgzO/7d0ld1Qsa46jMdvrO/8qZn40WVVAQK/fsX47dFy4lZKS7OjjGsvaQTraCQdyS 8ih7r1Z3s75+eapjwg2TNxSZjrFBVXus/+udO0h39IZ/HIFlJoRgIM57SC/StROQkW38 1nUp+T+oyGIDtQgqGB1U1ROcfl/tq+EHfrJf6FR0/CLH9t+HUXidAPH4ZavVnUpNP2bl fTUDelcT6N5aiVhQoOTuzabsUhm4iKFbhG1CV3GyrNtWmNa5i5eRW/D4aRktCw5gcRdk JDuQ== X-Forwarded-Encrypted: i=1; AJvYcCV83nxeLtLYWtSI2hRehrXsAho3/RN1P1dcCBFyqJYtLZZdnbq0szD3SkVdwt9IuZA1N4GrO65+s0FjTeOM5gtIM5AI9ceXKZfngzfl X-Gm-Message-State: AOJu0Yz7nxKR5suEguRVFqPTamH9BpT14AZ11iIJF+LJ+wS72MQS8thr e79pOwXdjzo/+rPZNPxftW5YxXiSvtr6/ycK0XwF/kalZ1Xxjsfr98NgOLfagfwZDzHy+0YM7Dj HO82POUlVNQMJNoQG2pjMXP6PYdqdNq6GjZGI X-Received: by 2002:a9d:3e5b:0:b0:6e4:ebe1:308f with SMTP id h27-20020a9d3e5b000000b006e4ebe1308fmr496310otg.30.1709597937524; Mon, 04 Mar 2024 16:18:57 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240304195214.14563-1-hsinyi@chromium.org> <20240304195214.14563-3-hsinyi@chromium.org> <87a5nd4tsg.fsf@intel.com> <874jdl4k01.fsf@intel.com> In-Reply-To: <874jdl4k01.fsf@intel.com> From: Hsin-Yi Wang Date: Mon, 4 Mar 2024 16:18:31 -0800 Message-ID: Subject: Re: [PATCH v3 2/4] drm/edid: Add a function to check monitor string To: Jani Nikula Cc: Douglas Anderson , Neil Armstrong , Jessica Zhang , Sam Ravnborg , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Dmitry Baryshkov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 4, 2024 at 4:09=E2=80=AFPM Jani Nikula wrote: > > On Mon, 04 Mar 2024, Hsin-Yi Wang wrote: > > On Mon, Mar 4, 2024 at 12:38=E2=80=AFPM Jani Nikula wrote: > >> > >> On Mon, 04 Mar 2024, Hsin-Yi Wang wrote: > >> > Add a function to check if the EDID base block contains a given stri= ng. > >> > > >> > One of the use cases is fetching panel from a list of panel names, s= ince > >> > some panel vendors put the monitor name after EDID_DETAIL_MONITOR_ST= RING > >> > instead of EDID_DETAIL_MONITOR_NAME. > >> > > >> > Signed-off-by: Hsin-Yi Wang > >> > --- > >> > v2->v3: move string matching to drm_edid > >> > --- > >> > drivers/gpu/drm/drm_edid.c | 49 +++++++++++++++++++++++++++++++++++= +++ > >> > include/drm/drm_edid.h | 1 + > >> > 2 files changed, 50 insertions(+) > >> > > >> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> > index 13454bc64ca2..fcdc2bd143dd 100644 > >> > --- a/drivers/gpu/drm/drm_edid.c > >> > +++ b/drivers/gpu/drm/drm_edid.c > >> > @@ -2789,6 +2789,55 @@ u32 drm_edid_get_panel_id(struct edid_base_bl= ock *base_block) > >> > } > >> > EXPORT_SYMBOL(drm_edid_get_panel_id); > >> > > >> > +/** > >> > + * drm_edid_has_monitor_string - Check if a EDID base block has cer= tain string. > >> > + * @base_block: EDID base block to check. > >> > + * @str: pointer to a character array to hold the string to be chec= ked. > >> > + * > >> > + * Check if the detailed timings section of a EDID base block has t= he given > >> > + * string. > >> > + * > >> > + * Return: True if the EDID base block contains the string, false o= therwise. > >> > + */ > >> > +bool drm_edid_has_monitor_string(struct edid_base_block *base_block= , const char *str) > >> > +{ > >> > + unsigned int i, j, k, buflen =3D strlen(str); > >> > + > >> > + for (i =3D 0; i < EDID_DETAILED_TIMINGS; i++) { > >> > + struct detailed_timing *timing =3D &base_block->edid.d= etailed_timings[i]; > >> > + unsigned int size =3D ARRAY_SIZE(timing->data.other_da= ta.data.str.str); > >> > + > >> > + if (buflen > size || timing->pixel_clock !=3D 0 || > >> > + timing->data.other_data.pad1 !=3D 0 || > >> > + (timing->data.other_data.type !=3D EDID_DETAIL_MON= ITOR_NAME && > >> > + timing->data.other_data.type !=3D EDID_DETAIL_MON= ITOR_STRING)) > >> > + continue; > >> > + > >> > + for (j =3D 0; j < buflen; j++) { > >> > + char c =3D timing->data.other_data.data.str.st= r[j]; > >> > + > >> > + if (c !=3D str[j] || c =3D=3D '\n') > >> > + break; > >> > + } > >> > + > >> > + if (j =3D=3D buflen) { > >> > + /* Allow trailing white spaces. */ > >> > + for (k =3D j; k < size; k++) { > >> > + char c =3D timing->data.other_data.dat= a.str.str[k]; > >> > + > >> > + if (c =3D=3D '\n') > >> > + return true; > >> > + else if (c !=3D ' ') > >> > + break; > >> > + } > >> > + if (k =3D=3D size) > >> > + return true; > >> > + } > >> > + } > >> > + > >> > + return false; > >> > +} > >> > + > >> > >> So we've put a lot of effort into converting from struct edid to struc= t > >> drm_edid, passing that around in drm_edid.c, with the allocation size = it > >> provides, and generally cleaning stuff up. > >> > >> I'm not at all happy to see *another* struct added just for the base > >> block, and detailed timing iteration as well as monitor name parsing > >> duplicated. > >> > >> With struct drm_edid you can actually return an EDID that only has the > >> base block and size 128, even if the EDID indicates more > >> extensions. Because the whole thing is *designed* to handle that > >> gracefully. The allocated size matters, not what the blob originating > >> outside of the kernel tells you. > >> > >> What I'm thinking is: > >> > >> - Add some struct drm_edid_ident or similar. Add all the information > >> that's needed to identify a panel there. I guess initially that's > >> panel_id and name. > >> > >> struct drm_edid_ident { > >> u32 panel_id; > >> const char *name; > >> }; > >> > >> - Add function: > >> > >> bool drm_edid_match(const struct drm_edid *drm_edid, const struct = drm_edid_ident *ident); > >> > >> Check if stuff in ident matches drm_edid. You can use and extend the > >> existing drm_edid based iteration etc. in > >> drm_edid.c. Straightforward. The fields in ident can trivially be > >> extended later, and the stuff can be useful for other drivers and > >> quirks etc. > >> > >> - Restructure struct edp_panel_entry to contain struct > >> drm_edid_ident. Change the iteration of edp_panels array to use > >> drm_edid_match() on the array elements and the edid. > >> > >> - Add a function to read the EDID base block *but* make it return cons= t > >> struct drm_edid *. Add warnings in the comments that it's only for > >> panel and for transition until it switches to reading full EDIDs. > >> > >> const struct drm_edid *drm_edid_read_base_block(struct i2c_adapter= *adapter); > >> > >> This is the *only* hackish part of the whole thing, and it's nicely > >> isolated. For the most part you can use drm_edid_get_panel_id() code > >> for this, just return the blob wrapped in a struct drm_edid envelope= . > > > > To clarify: > > struct drm_edid currently is only internal to drm_edid.c. So with > > change we will have to move it to the header drm_edid.h > > Absolutely not, struct drm_edid must remain an opaque type. The point is > that you ask drm_edid.c if there's a match or not, and the panel code > does not need to care what's inside struct drm_edid. > > > > >> > >> - Remove function: > >> > >> u32 drm_edid_get_panel_id(struct i2c_adapter *adapter); > >> > > > > Probably change to u32 drm_edid_get_panel_id(const struct drm_edid > > *);? Given that we still need to parse id from > > drm_edid_read_base_block(). > > No, we no longer need to parse the id outside of drm_edid.c. You'll have > the id's in panel code in the form of struct drm_edid_ident (or > whatever), and use the match function to see if the opaque drm_edid > matches. > drm_panel prints the panel_id info on whether the panel is detected or not. https://elixir.bootlin.com/linux/v6.8-rc7/source/drivers/gpu/drm/panel/pane= l-edp.c#L792 Is it okay to remove this information? > > > >> - Refactor edid_quirk_list to use the same id struct and match functio= n > >> and mechanism within drm_edid.c (can be follow-up too). > >> > > > > edid_quirk currently doesn't have panel names in it, and it might be a > > bit difficult to get all the correct names of these panels without > > having the datasheets. > > One way is to leave the name as null and if the name is empty and skip > > matching the name in drm_edid_match(). > > Exactly. NULL in drm_edid_ident would mean "don't care". I think most of > the ones in panel code also won't use the name for matching. > > BR, > Jani. > > > > >> - Once you change the panel code to read the whole EDID using > >> drm_edid_read family of functions in the future, you don't have to > >> change *anything* about the iteration or matching or anything, becau= se > >> it's already passing struct drm_edid around. > >> > >> > >> I hope this covers everything. > >> > >> BR, > >> Jani. > >> > >> > >> > /** > >> > * drm_edid_get_base_block - Get a panel's EDID base block > >> > * @adapter: I2C adapter to use for DDC > >> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h > >> > index 2455d6ab2221..248ddb0a6b5d 100644 > >> > --- a/include/drm/drm_edid.h > >> > +++ b/include/drm/drm_edid.h > >> > @@ -416,6 +416,7 @@ struct edid *drm_get_edid(struct drm_connector *= connector, > >> > struct i2c_adapter *adapter); > >> > struct edid_base_block *drm_edid_get_base_block(struct i2c_adapter = *adapter); > >> > u32 drm_edid_get_panel_id(struct edid_base_block *base_block); > >> > +bool drm_edid_has_monitor_string(struct edid_base_block *base_block= , const char *str); > >> > struct edid *drm_get_edid_switcheroo(struct drm_connector *connecto= r, > >> > struct i2c_adapter *adapter); > >> > struct edid *drm_edid_duplicate(const struct edid *edid); > >> > >> -- > >> Jani Nikula, Intel > > -- > Jani Nikula, Intel