Received: by 2002:a05:7412:1e0b:b0:fc:a2b0:25d7 with SMTP id kr11csp469853rdb; Thu, 15 Feb 2024 06:01:29 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCW1M5DAvOX/vYsMuY07itWYch8gYIBMyDKgvvIfVRzkQk8ua9ap2Jr3pMG91/lAQO2orm16iSlHnd082hTnJnFLo/WP6QsDZesDidqOGA== X-Google-Smtp-Source: AGHT+IEnV2llNBY5ckwPKBPzg9ZMwYfGu6GV7SCEmnGXf1cszITp6URsOJfSr8ii6llfv9WWlvqK X-Received: by 2002:a17:90b:304:b0:299:df2:66b2 with SMTP id ay4-20020a17090b030400b002990df266b2mr1316673pjb.22.1708005688649; Thu, 15 Feb 2024 06:01:28 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708005688; cv=pass; d=google.com; s=arc-20160816; b=DIeEGuiy9UTWz2DD3Es8+KWRYFak+pL7PUPzsC/Ng4FJUwcC5ut/fEfZfFHk+cxIun 4vIm6lSqbIa4q5pu1wDY2cqhK5LUifENk7WitRKGxH7yWUyOwD8w1cVBAMmXMEFyIKXc XpYl5AH/iq0/KTVgpb/BMB2ydzBya0cX0wzFdDWVFjxhdNt2NTx43DTQtPIe8lzUBdXA jLIlALP5Ay41oDOdy97gCs40ms/RT+GCqKTgtUDdI2kb4P41Bka2vMoOqfBewa/i+4ck h88gG2jjK5oicl8hOXuPo7GjHTcOfKnwiBJ6bmv3dv+I57wO/9nVZ3jYohTl1S2xuBJ1 qn/g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :message-id:date:references:organization:in-reply-to:subject:cc:to :from:dkim-signature; bh=CCBmze/MLR//6iXk7hPqhkTchJgORuz4NkarZoyXT7A=; fh=B5OM1BnzjwdYb2CRJ4TqbHqwdu9pdtBDbvn1ucErs+U=; b=upkIJgSASN3M2xN2blYZnBxfzg6tIRgo6hLnHqwCcKZNlUspanO1nX/vRu3Ynrb+vu tMGvmJNNSIhDr79+k00eYKdHa7KrXkcMofeWXgRyklOSqhAskZrGL0lRehfJPCQd9vpH nMxj9xTRY2qN6I7dfhujctRlYNriuETyYjv1U9ZSoflduQr6zsausBNsOXEJJ9q23GDY qW91DsCwaqvreh0B+PUyN8SjG7wvMpK+53TGfyoxI2lUT0AsH3J5eRWRF6ebKVv+aZPG bdCz1V2iN59Z762tDaroVu24QPA25mYcWbc5BcD59ayxR0yOdOQU1mscSxwz1BwWEj/t YGVQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VQ4kc547; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-67040-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67040-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id i2-20020a17090adc0200b002970bd13107si1266005pjv.83.2024.02.15.06.01.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 06:01:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-67040-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VQ4kc547; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-67040-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67040-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com 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 3319E294081 for ; Thu, 15 Feb 2024 14:01:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 87FF9131E35; Thu, 15 Feb 2024 14:01:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VQ4kc547" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 E933112FF7C; Thu, 15 Feb 2024 14:01:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708005671; cv=none; b=UFRsimXpWmudoL2DYccGNG7tsER8LvvI6taT2K2zvceUVQ8kLt7id9ouzgOuhXtnBLbA5SBqkBrc6ZDXGvRtFXwi6vRFl3Cc4YcCKgnNc30EsFE3H/EK97/zdGz+Qlxj9/LnnL7poJ8Qx+xhjgLDiSDAMHhHjhLOjfuhHcxMqlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708005671; c=relaxed/simple; bh=NU9Se3/hUjZuq4O8oLC6OrFNJO05DdvNQarp036H6Ss=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=oJ7CpEdUpiFM6f9Yw8sG92tmibBz5jfzxm9udi8DBTJkDr82RNKh1mLACnRVCwxA8rp5OARJ13YFhp5FZKDE5Q0rkHILjTM1u0Mr2IBpObzQrsl2i3AAlNVxCXb4zZnbn3LGJrx4m3Z2K4WZa2g+l+0g40FPLhiCQe8q/DTTQ/k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=VQ4kc547; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708005669; x=1739541669; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=NU9Se3/hUjZuq4O8oLC6OrFNJO05DdvNQarp036H6Ss=; b=VQ4kc547LXGXQkGJxkbAgnTRR2JkarAVA+jBpzXoTqW7j1wpkOpGp/Hz tSAXc1F26lSCFHQG9d+xFWpYCQRz4aXSInMGKogq+hfrmtxRIkNJjMpbN p4nrZARD0nZPN69R5tkJkSV/uzVk4RuFlOtFLhKWuyjqM2rOH2D8Fu9LH lsOp2U8tJCajjg6AYHJy/hk/wZccsuq2RTK8SyTL8TbSn7zVbl3HGdsi4 aS/hf8bo3rOWOdO6/sKm4LLa1JtUIwfFIjoNcbgOXo8OrtyysSADbRp3A tXyF5YuoHq6ksYpBjbz60MtfptRmFJisI6k3MEzyDh5XpwN1OMpWP3OQ8 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10984"; a="5867666" X-IronPort-AV: E=Sophos;i="6.06,161,1705392000"; d="scan'208";a="5867666" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Feb 2024 06:01:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10984"; a="826416889" X-IronPort-AV: E=Sophos;i="6.06,161,1705392000"; d="scan'208";a="826416889" Received: from kraszkow-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.44.13]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Feb 2024 06:01:04 -0800 From: Jani Nikula To: Mario Limonciello , amd-gfx@lists.freedesktop.org, "open list:DRM DRIVERS" Cc: "open list:ACPI" , open list , Melissa Wen , Mark Pearson , Mario Limonciello Subject: Re: [PATCH v5 1/3] drm: Add support to get EDID from ACPI In-Reply-To: <20240211055011.3583-2-mario.limonciello@amd.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20240211055011.3583-1-mario.limonciello@amd.com> <20240211055011.3583-2-mario.limonciello@amd.com> Date: Thu, 15 Feb 2024 16:01:02 +0200 Message-ID: <87eddd6d41.fsf@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Sat, 10 Feb 2024, Mario Limonciello wrote: > Some manufacturers have intentionally put an EDID that differs from > the EDID on the internal panel on laptops. Drivers that prefer to > fetch this EDID can set a bit on the drm_connector to indicate that > the DRM EDID helpers should try to fetch it and it is preferred if > it's present. > > Signed-off-by: Mario Limonciello > --- > v1->v2: > * Split code from previous amdgpu specific helper to generic drm helper. > v2->v3: > * Add an extra select to fix a variety of randconfig errors found from > LKP robot. > v3->v4: > * Return struct drm_edid > v4->v5: > * Rename to drm_edid_read_acpi > * Drop selects > --- > drivers/gpu/drm/Kconfig | 7 +++ > drivers/gpu/drm/drm_edid.c | 113 +++++++++++++++++++++++++++++++++--- > include/drm/drm_connector.h | 6 ++ > include/drm/drm_edid.h | 1 + > 4 files changed, 119 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 2520db0b776e..a49740c528b9 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -103,6 +103,13 @@ config DRM_KMS_HELPER > help > CRTC helpers for KMS drivers. > > +config DRM_ACPI_HELPER > + tristate "ACPI support in DRM" > + depends on DRM > + depends on (ACPI_VIDEO || ACPI_VIDEO=n) > + help > + ACPI helpers for DRM drivers. > + > config DRM_DEBUG_DP_MST_TOPOLOGY_REFS > bool "Enable refcount backtrace history in the DP MST helpers" > depends on STACKTRACE_SUPPORT > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 69c68804023f..096c278b6f66 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -28,6 +28,7 @@ > * DEALINGS IN THE SOFTWARE. > */ > > +#include > #include > #include > #include > @@ -2188,6 +2189,62 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int block, size_t len) > return ret == xfers ? 0 : -1; > } > > +/** > + * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC > + * @data: struct drm_connector > + * @buf: EDID data buffer to be filled > + * @block: 128 byte EDID block to start fetching from > + * @len: EDID data buffer length to fetch > + * > + * Try to fetch EDID information by calling acpi_video_get_edid() function. > + * > + * Return: 0 on success or error code on failure. > + */ > +static int > +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len) > +{ > + struct drm_connector *connector = data; > + struct drm_device *ddev = connector->dev; > + struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev); > + unsigned char start = block * EDID_LENGTH; > + void *edid; > + int r; > + > + if (!acpidev) > + return -ENODEV; > + > + switch (connector->connector_type) { > + case DRM_MODE_CONNECTOR_LVDS: > + case DRM_MODE_CONNECTOR_eDP: > + break; > + default: > + return -EINVAL; > + } > + > + /* fetch the entire edid from BIOS */ > + if (IS_REACHABLE(CONFIG_DRM_ACPI_HELPER)) { > + r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, &edid); > + if (r < 0) { > + DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r); > + return -EINVAL; > + } > + } else { > + r = -EOPNOTSUPP; > + } > + if (len > r || start > r || start + len > r) { > + r = -EINVAL; > + goto cleanup; > + } > + > + memcpy(buf, edid + start, len); > + r = 0; > + > +cleanup: > + kfree(edid); > + > + return r; > +} > + > static void connector_bad_edid(struct drm_connector *connector, > const struct edid *edid, int num_blocks) > { > @@ -2621,7 +2678,8 @@ EXPORT_SYMBOL(drm_probe_ddc); > * @connector: connector we're probing > * @adapter: I2C adapter to use for DDC > * > - * Poke the given I2C channel to grab EDID data if possible. If found, > + * If the connector allows it, try to fetch EDID data using ACPI. If not found > + * poke the given I2C channel to grab EDID data if possible. If found, > * attach it to the connector. > * > * Return: Pointer to valid EDID or NULL if we couldn't find any. > @@ -2629,20 +2687,50 @@ EXPORT_SYMBOL(drm_probe_ddc); > struct edid *drm_get_edid(struct drm_connector *connector, > struct i2c_adapter *adapter) > { > - struct edid *edid; > + struct edid *edid = NULL; > > if (connector->force == DRM_FORCE_OFF) > return NULL; > > - if (connector->force == DRM_FORCE_UNSPECIFIED && !drm_probe_ddc(adapter)) > - return NULL; > + if (connector->acpi_edid_allowed) > + edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid, connector, NULL); > + > + if (!edid) { > + if (connector->force == DRM_FORCE_UNSPECIFIED && !drm_probe_ddc(adapter)) > + return NULL; > + edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter, NULL); > + } Hmm. So do you want the presence of ACPI EDID to determine whether the display is there or not? Note how the override and firmware EDID mechanisms only override the EDID *contents*. They are orthogonal from connector forcing. So you can override the EDID, but still rely on the DDC probe to determine if the display is there. The question is, how likely is it that the ACPI EDID is used not just because the actual EDID is bogus, but also because the display just doesn't respond to DDC at all? If possible, I'd like ACPI EDID to follow the override/firmware EDID semantics on this. > > - edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter, NULL); > drm_connector_update_edid_property(connector, edid); > return edid; > } > EXPORT_SYMBOL(drm_get_edid); > > +/** > + * drm_edid_read_acpi - get EDID data, if available > + * @connector: connector we're probing > + * > + * Use the BIOS to attempt to grab EDID data if possible. > + * > + * The returned pointer must be freed using drm_edid_free(). > + * > + * Return: Pointer to valid EDID or NULL if we couldn't find any. > + */ > +const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector) > +{ > + const struct drm_edid *drm_edid; > + > + if (connector->force == DRM_FORCE_OFF) > + return NULL; If the caller handled all the connector->force stuff, this could be dropped. > + > + drm_edid = drm_edid_read_custom(connector, drm_do_probe_acpi_edid, connector); > + > + /* Note: Do *not* call connector updates here. */ > + > + return drm_edid; > +} > +EXPORT_SYMBOL(drm_edid_read_acpi); > + > /** > * drm_edid_read_custom - Read EDID data using given EDID block read function > * @connector: Connector to use > @@ -2727,10 +2815,11 @@ const struct drm_edid *drm_edid_read_ddc(struct drm_connector *connector, > EXPORT_SYMBOL(drm_edid_read_ddc); > > /** > - * drm_edid_read - Read EDID data using connector's I2C adapter > + * drm_edid_read - Read EDID data using BIOS or connector's I2C adapter > * @connector: Connector to use > * > - * Read EDID using the connector's I2C adapter. > + * Read EDID from BIOS if allowed by connector or by using the connector's > + * I2C adapter. > * > * The EDID may be overridden using debugfs override_edid or firmware EDID > * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this priority > @@ -2742,10 +2831,18 @@ EXPORT_SYMBOL(drm_edid_read_ddc); > */ > const struct drm_edid *drm_edid_read(struct drm_connector *connector) > { > + const struct drm_edid *drm_edid = NULL; > + > if (drm_WARN_ON(connector->dev, !connector->ddc)) > return NULL; > > - return drm_edid_read_ddc(connector, connector->ddc); > + if (connector->acpi_edid_allowed) > + drm_edid = drm_edid_read_acpi(connector); > + > + if (!drm_edid) > + drm_edid = drm_edid_read_ddc(connector, connector->ddc); This should be in drm_edid_read_ddc() not drm_edid_read(). Please let's not make the two behave any different. It would be really weird if one had an ACPI check and the other not. > + > + return drm_edid; > } > EXPORT_SYMBOL(drm_edid_read); > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > index fe88d7fc6b8f..74ed47f37a69 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -1886,6 +1886,12 @@ struct drm_connector { > > /** @hdr_sink_metadata: HDR Metadata Information read from sink */ > struct hdr_sink_metadata hdr_sink_metadata; > + > + /** > + * @acpi_edid_allowed: Get the EDID from the BIOS, if available. > + * This is only applicable to eDP and LVDS displays. > + */ > + bool acpi_edid_allowed; > }; > > #define obj_to_connector(x) container_of(x, struct drm_connector, base) > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h > index 518d1b8106c7..38b5e1b5c773 100644 > --- a/include/drm/drm_edid.h > +++ b/include/drm/drm_edid.h > @@ -463,5 +463,6 @@ bool drm_edid_is_digital(const struct drm_edid *drm_edid); > > const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid, > int ext_id, int *ext_index); > +const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector); > > #endif /* __DRM_EDID_H__ */ -- Jani Nikula, Intel