Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp5494710ybf; Thu, 5 Mar 2020 01:41:59 -0800 (PST) X-Google-Smtp-Source: ADFU+vtu1e71Wr+/ob2Dz28p9UNfVQq2nOl09k4lL/H6oeUVOKLeWtmhxgwNAH/xl6nM5W3gFC2W X-Received: by 2002:aca:56c4:: with SMTP id k187mr4178260oib.44.1583401319709; Thu, 05 Mar 2020 01:41:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583401319; cv=none; d=google.com; s=arc-20160816; b=tydwwbw5PkxZFotL8291lhGxdfyygT4tUGSjdtRsqzKcncXUcgIk7msqTdFwqEWNRu 0N6nO4k1NGeLRvZI+SlB+4ma6ReVktB54ZYJSx0wvvmk9PNZrLg4iBlLEUaCenshj3kg GIO+c7+J9tNjPDL2gASA00Z3c0Mt6/dE1U8a0v6Aat36Y3fNgu4QAnzbeEQbD5hFOt3y 5tyWDo5mRggG+W2Nv/nsBsVHJr53OKUY3koRMn3uAGU7rijLNfNRlEr+CV3+RQrt70px twcMz6K90vemPAs/C5Y/hIh9x3+/5sgsjkO75UhcWAbwBbGvyE+Ia5GoLANcfcw4l2IK zrnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from; bh=I+2JwFIL15bMGATzWPW62/dY3FvFDelYyy1j/4UlMVY=; b=RGNtLrgfqVGMI1EvZr1Tj3AHXidsTIamtp68RkZPpAw4ZvJqWZ0gPhqjQK3bg2zz6q OwKQmgS9Nbf3iQAbPP8/NkkYYISKnF4tihxQgVz+YQ+ypGohyKh8rOY6kEc2LDJz+Nu0 WJt9lrU7vsS+vaSybkjIXoKa55ZIqPPTJeyL8XzgoLUUiMUZMIwRzqm7B5Q4RWnSMLL7 005NgTjyQwX4+7gfMeR8Kn7pPSgYzzeQZevQ9qaOa3yriGb9Wr1UIKa5C6RGxOOnb/8P XArqkMffLyuPdkC5zlS1lhCS1PYuxqIibKoZ66jHLpwV2vmb/K+QNBTfVfbCmtAKaWX6 gbWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q4si3126337oth.163.2020.03.05.01.41.47; Thu, 05 Mar 2020 01:41:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726049AbgCEJky (ORCPT + 99 others); Thu, 5 Mar 2020 04:40:54 -0500 Received: from mga04.intel.com ([192.55.52.120]:13116 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725880AbgCEJky (ORCPT ); Thu, 5 Mar 2020 04:40:54 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2020 01:40:53 -0800 X-IronPort-AV: E=Sophos;i="5.70,517,1574150400"; d="scan'208";a="234361803" Received: from bennur-mobl1.ger.corp.intel.com (HELO localhost) ([10.249.38.13]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2020 01:40:44 -0800 From: Jani Nikula To: Rajat Jain , Maarten Lankhorst , Maxime Ripard , Sean Paul , David Airlie , Daniel Vetter , Joonas Lahtinen , Rodrigo Vivi , Ville =?utf-8?B?U3lyasOkbMOk?= , Chris Wilson , Imre Deak , =?utf-8?Q?Jo?= =?utf-8?Q?s=C3=A9?= Roberto de Souza , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, gregkh@linuxfoundation.org, mathewk@google.com, Daniel Thompson , Jonathan Corbet , Pavel Machek , seanpaul@google.com, Duncan Laurie , jsbarnes@google.com, Thierry Reding , mpearson@lenovo.com, Nitin Joshi1 , Sugumaran Lacshiminarayanan , Tomoki Maruichi Cc: Rajat Jain , rajatxjain@gmail.com Subject: Re: [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors In-Reply-To: <20200305012338.219746-3-rajatja@google.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200305012338.219746-1-rajatja@google.com> <20200305012338.219746-3-rajatja@google.com> Date: Thu, 05 Mar 2020 11:40:45 +0200 Message-ID: <87o8tbnnqa.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 04 Mar 2020, Rajat Jain wrote: > Lookup and attach ACPI nodes for intel connectors. The lookup is done > in compliance with ACPI Spec 6.3 > https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf > (Ref: Pages 1119 - 1123). > > This can be useful for any connector specific platform properties. (This > will be used for privacy screen in next patch). > > Signed-off-by: Rajat Jain > --- > v6: Addressed minor comments from Jani at > https://lkml.org/lkml/2020/1/24/1143 > - local variable renamed. > - used drm_dbg_kms() > - used acpi_device_handle() > - Used opaque type acpi_handle instead of void* > v5: same as v4 > v4: Same as v3 > v3: fold the code into existing acpi_device_id_update() function > v2: formed by splitting the original patch into ACPI lookup, and privacy > screen property. Also move it into i915 now that I found existing code > in i915 that can be re-used. > > drivers/gpu/drm/i915/display/intel_acpi.c | 24 +++++++++++++++++++ > .../drm/i915/display/intel_display_types.h | 5 ++++ > drivers/gpu/drm/i915/display/intel_dp.c | 3 +++ > 3 files changed, 32 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c b/drivers/gpu/drm/i915/display/intel_acpi.c > index 3e6831cca4ac1..870c1ad98df92 100644 > --- a/drivers/gpu/drm/i915/display/intel_acpi.c > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c > @@ -222,11 +222,22 @@ static u32 acpi_display_type(struct intel_connector *connector) > return display_type; > } > > +/* > + * Ref: ACPI Spec 6.3 > + * https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf > + * Pages 1119 - 1123 describe, what I believe, a standard way of > + * identifying / addressing "display panels" in the ACPI. It provides > + * a way for the ACPI to define devices for the display panels attached > + * to the system. It thus provides a way for the BIOS to export any panel > + * specific properties to the system via ACPI (like device trees). > + */ > void intel_acpi_device_id_update(struct drm_i915_private *dev_priv) > { > struct drm_device *dev = &dev_priv->drm; > struct intel_connector *connector; > struct drm_connector_list_iter conn_iter; > + struct acpi_device *conn_dev; > + u64 conn_addr; > u8 display_index[16] = {}; > > /* Populate the ACPI IDs for all connectors for a given drm_device */ > @@ -242,6 +253,19 @@ void intel_acpi_device_id_update(struct drm_i915_private *dev_priv) > device_id |= display_index[type]++ << ACPI_DISPLAY_INDEX_SHIFT; > > connector->acpi_device_id = device_id; > + > + /* Build the _ADR to look for */ > + conn_addr = device_id | ACPI_DEVICE_ID_SCHEME | > + ACPI_BIOS_CAN_DETECT; > + > + drm_dbg_kms(dev, "Checking connector ACPI node at _ADR=%llX\n", > + conn_addr); > + > + /* Look up the connector device, under the PCI device */ > + conn_dev = acpi_find_child_device( > + ACPI_COMPANION(&dev->pdev->dev), > + conn_addr, false); > + connector->acpi_handle = acpi_device_handle(conn_dev); > } > drm_connector_list_iter_end(&conn_iter); > } > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h > index 5e00e611f077f..d70612cc1ba2a 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_types.h > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h > @@ -411,9 +411,14 @@ struct intel_connector { > */ > struct intel_encoder *encoder; > > +#ifdef CONFIG_ACPI > /* ACPI device id for ACPI and driver cooperation */ > u32 acpi_device_id; > > + /* ACPI handle corresponding to this connector display, if found */ > + acpi_handle acpi_handle; > +#endif > + > /* Reads out the current hw, returning true if the connector is enabled > * and active (i.e. dpms ON state). */ > bool (*get_hw_state)(struct intel_connector *); > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c > index 0a417cd2af2bc..171821113d362 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -44,6 +44,7 @@ > #include "i915_debugfs.h" > #include "i915_drv.h" > #include "i915_trace.h" > +#include "intel_acpi.h" > #include "intel_atomic.h" > #include "intel_audio.h" > #include "intel_connector.h" > @@ -6868,6 +6869,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect > > connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT; > > + /* Lookup the ACPI node corresponding to the connector */ > + intel_acpi_device_id_update(dev_priv); I find this part problematic. Normally, we call the function at probe via i915_driver_register() -> intel_opregion_register() -> intel_opregion_resume() -> intel_didl_outputs() -> intel_acpi_device_id_update(). It gets called *once* at probe, after we have all the outputs (and thus connectors) figured out. This in turn calls it for every DP connector, before we even have all connectors registered. But it also re-iterates the previously handled connectors again and again. The problem, of course, is that you'll need connector->acpi_handle to figure out whether the feature is present and whether the property is needed. Figuring out acpi_handle also requires connector->acpi_device_id. It's a bit of a catch-22. I think the options are: 1) See if we can postpone creating and attaching properties to connector ->late_register hook. (I didn't have the time to look into it yet, at all.) 2) Provide a way to populate connector->acpi_device_id and connector->acpi_handle on a per-connector basis. At least the device id remains constant for the lifetime of the drm_device (why do we keep updating it at every resume?!) but can we be sure ->acpi_handle does too? (I don't really know my way around ACPI.) BR, Jani. > } > } -- Jani Nikula, Intel Open Source Graphics Center