Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp880804ybl; Fri, 24 Jan 2020 11:13:57 -0800 (PST) X-Google-Smtp-Source: APXvYqxy3MpChr894zBIQC7PdYRRP+nU9o7R2s44o9NNXCJfajSEnPdGH/yPcQ2tozlFiyMu/hdZ X-Received: by 2002:a54:4715:: with SMTP id k21mr203775oik.163.1579893237669; Fri, 24 Jan 2020 11:13:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579893237; cv=none; d=google.com; s=arc-20160816; b=MvJax1RTQESmWj7MDxksAkSsFmvIF4k0rxFP2XmSVfC8B4PS4pOpKvNFM5e74CEj2V d+JMsGX7QSxafgl9UlWMNDQC1N6+0tWX2WIuvTYS80ORtPm2XdE4vDddg2Am+k/z2Cpw lgaV0yaLfLwZnkFno+/Pr7yhiQcgJBcSmK7wxw+URadHFJm3kALHhSGX4kgjcN/TUWXf 6e+mf0/SM0Tt1q5HEurK2ChNP+NpQiJY0O0oJX5/IgxVkb7KN2+wK+DrrGi/D6lhe8jM wqItEpSSc/mV+VHmq9BxJeTGhBldI1PA8X2+QrJdLIhR+a7r0lMkd0HToUOu16qEVmmT /FJQ== 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=iuNl7Oq2/HnR7vtcqUFZ/EVs8dc6z2UJ7zRIz3n3lfw=; b=ZOLl8BymDgamYsv1bL8yNPcAb0bjTnS9A2BmYDXIHAzqvsgq8DMiEFvOVfrq2b/sDO KBOnTNKVcfraF5FxwaJWFh49AJodbI2KV2Ayd6yJW/IFW4jPvPwaIxnVcbd6PPwzpBMF U7ar0AH9o012YI+Ij0WI0GR55dCk4X+fdNjRj9tPZFFnchVRm8oTfQ/KUDjxOHbhQyy9 KJ1KQkJ9YdXyGVJ82HLm0xnPih48/WJ16M47cmEEvX8mP7ThHIBq75qZyIcDCgTpwCez iPUaiuaKXQ1fbgI6SqT/2A3+JxkWIU4quSvWeEoEXCoUgyApUrohS6h/RQgoBOQjWIZI QJcw== 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 k13si187300oij.118.2020.01.24.11.13.45; Fri, 24 Jan 2020 11:13:57 -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 S2389034AbgAXLhZ (ORCPT + 99 others); Fri, 24 Jan 2020 06:37:25 -0500 Received: from mga18.intel.com ([134.134.136.126]:54239 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404959AbgAXLg5 (ORCPT ); Fri, 24 Jan 2020 06:36:57 -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 orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2020 03:36:56 -0800 X-IronPort-AV: E=Sophos;i="5.70,357,1574150400"; d="scan'208";a="220996786" Received: from omarkovx-mobl.ger.corp.intel.com (HELO localhost) ([10.249.37.60]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2020 03:36:49 -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?Jos=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 Cc: Rajat Jain , rajatxjain@gmail.com Subject: Re: [PATCH v5 2/3] drm/i915: Lookup and attach ACPI device node for connectors In-Reply-To: <20191220200353.252399-2-rajatja@google.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20191220200353.252399-1-rajatja@google.com> <20191220200353.252399-2-rajatja@google.com> Date: Fri, 24 Jan 2020 13:37:48 +0200 Message-ID: <87v9p1gk4z.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 Fri, 20 Dec 2019, 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 > --- > 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 | 3 +++ > drivers/gpu/drm/i915/display/intel_dp.c | 3 +++ > 3 files changed, 30 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c b/drivers/gpu/drm/i915/display/intel_acpi.c > index e21fb14d5e07..101a56c08996 100644 > --- a/drivers/gpu/drm/i915/display/intel_acpi.c > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c > @@ -222,11 +222,23 @@ 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 *drm_dev = &dev_priv->drm; > struct intel_connector *connector; > struct drm_connector_list_iter conn_iter; > + struct device *dev = &drm_dev->pdev->dev; Hmm, already pushed patch 1 with the unfortunate "drm_dev" local. We use "dev" for struct drm_device * and almost never use struct device. > + 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 +254,18 @@ 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_DEV_INFO(dev, "Checking connector ACPI node at _ADR=%llX\n", > + conn_addr); This is more than a little verbose. One line of INFO level dmesg for every connector at boot and at resume. Please use the new drm_dbg_kms() macro for this. > + > + /* Look up the connector device, under the PCI device */ > + conn_dev = acpi_find_child_device(ACPI_COMPANION(dev), > + conn_addr, false); > + connector->acpi_handle = conn_dev ? conn_dev->handle : NULL; 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 1a7334dbe802..0a4a04116091 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_types.h > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h > @@ -407,6 +407,9 @@ struct intel_connector { > /* ACPI device id for ACPI and driver cooperation */ > u32 acpi_device_id; > > + /* ACPI handle corresponding to this connector display, if found */ > + void *acpi_handle; > + The type is acpi_handle. It's none of our business to know what the underlying type is. > /* 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 b05b2191b919..93cece8e2516 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -45,6 +45,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" > @@ -6623,6 +6624,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); Auch, this is problematic. It iterates all connectors, for every DP connector being added. In the middle of registering all connectors. From the POV of this patch alone, this is also unnecessary. This gets called via intel_opregion_register() after all connectors have been registered. I am aware it's not enough for your next patch, because it will need the acpi handle right here. I'm wondering if we need to maintain display_index[] in struct drm_i915_private, and update that as connectors get added instead of all at once in the end. connector->acpi_device_id never changes, does it, even though we keep updating it? BR, Jani. > } > } -- Jani Nikula, Intel Open Source Graphics Center