Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6645719ybf; Fri, 6 Mar 2020 01:42:56 -0800 (PST) X-Google-Smtp-Source: ADFU+vtBQhSa7LjxYZraOX8kapRIJV0w1f9BtGgVmmKdBsYJ0L2qAQeaV+Fuu8S1ltmv713i0ica X-Received: by 2002:a05:6830:1dcb:: with SMTP id a11mr1865532otj.260.1583487776280; Fri, 06 Mar 2020 01:42:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583487776; cv=none; d=google.com; s=arc-20160816; b=b/amRBwuzBcSr+jpzkwQw8QG4H35I78STkdgVq7vNQ0bmRY6iLD93GTtLARO/LzJgb KNW+35U/HjUMfLmQl+Nbd5GFnaLULnD8UFxu/dtmbLPxpTYj6L4INQbpkOgqsKg1qoEy DwBWO4K1+VpnFe7ZaREJErEWE/b3ypPGqbAWJXMWWD+rN3iouBLqBvtqYxzcv+9TLWee Heo9dVb3nNgvJMllaBhrNf5a6hDTrcyzo6UuHWhsFtwT5oTrmA6/iGwBKRu4Wm5dW7GJ d+WewJWeJUxZthiwHBpv654pf6JO1Rb79wxuZtvyHLAWt1dTjkVG0SwjdA08K2NkzSQF B2Nw== 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=GrWXF+EfngVB/aOT0zjtpnPQ3AcPpxutxdhNxv1fS+I=; b=R79ArTU4henTpxm354bjFE/3fe1H+IhV+i7duwnZgW8oY5q7CKOrpHar00lTAtDrhV vU6EHz3nIBMiNF1NmHYk33MV9TqsLlrBLQZi5Wa2np5fp7Xn7i8lS7Q78c6pa+s32RC9 97lbVS2fTbFvFBPDpZFw7nw58XmUtqyeFL055oGKMXYnaNTr283mPNBjCfWToPEZABjP VUX4ZClc4BJZC1pv+m6xLwczpotIDUx3ggusrZvmsaYfAh7WEYcjTpKRTWoqXA29neIB RB1PbbKYDP5r+QlLUulytJnW4fwzbQhQkkcJxI9o0fI6y4VZrU0+XFaGJXcDI2CrDJM0 Q8iA== 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 c20si1142183oic.99.2020.03.06.01.42.42; Fri, 06 Mar 2020 01:42:56 -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 S1726231AbgCFJmN (ORCPT + 99 others); Fri, 6 Mar 2020 04:42:13 -0500 Received: from mga12.intel.com ([192.55.52.136]:52520 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726069AbgCFJmN (ORCPT ); Fri, 6 Mar 2020 04:42:13 -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 fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2020 01:42:12 -0800 X-IronPort-AV: E=Sophos;i="5.70,521,1574150400"; d="scan'208";a="234747642" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2020 01:42:03 -0800 From: Jani Nikula To: Rajat Jain Cc: 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 Mailing List , dri-devel , intel-gfx@lists.freedesktop.org, Greg Kroah-Hartman , Mat King , Daniel Thompson , Jonathan Corbet , Pavel Machek , Sean Paul , Duncan Laurie , Jesse Barnes , Thierry Reding , Mark Pearson , Nitin Joshi1 , Sugumaran Lacshiminarayanan , Tomoki Maruichi , Rajat Jain Subject: Re: [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200305012338.219746-1-rajatja@google.com> <20200305012338.219746-3-rajatja@google.com> <87o8tbnnqa.fsf@intel.com> Date: Fri, 06 Mar 2020 11:42:00 +0200 Message-ID: <87tv31om53.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 Thu, 05 Mar 2020, Rajat Jain wrote: > On Thu, Mar 5, 2020 at 1:41 AM Jani Nikula wrote: >> >> On Wed, 04 Mar 2020, Rajat Jain wrote: >> 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.) > > Apparently not. The drm core doesn't like to add properties in > late_register() callback. I just tried it and get this warning: I kind of had a feeling this would be the case, thanks for checking. >> 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 > > Are you confirming that the connector->acpi_device_id remains constant > for the lifetime of the drm_device, as calculated in > intel_acpi_device_id_update()? Even in the face of external displays > (monitors) being connected and disconnected during the lifetime of the > system? If so, then I think we can have a solution. First I thought so. Alas it does not hold for DP MST, where you can have connectors added and removed dynamically. I think we could ensure they stay the same for all other connectors though. I'm pretty sure this is already the case; they get added/removed after all others. Another thought, from the ACPI perspective, I'm not sure the dynamically added/removed DP MST connectors should even have acpi handles. But again, tying all this together with ACPI stuff is not something I am an expert on. >> (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.) > > I don't understand why this was being updated on every resume in that > case (this existed even before my patchset). I believe we do not need > it. Yes, the ->acpi_handle will not change if the ->acpi_device_id > does not change. I believe the way forward should then be to populate > connector->acpi_device_id and connector->acpi_handle ONE TIME at the > time of connector init (and not update it on every resume). Does this > sound ok? If a DP MST connector gets removed, should the other ACPI display indexes after that shift, or remain the same? I really don't know. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center