From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CADEC10F27 for ; Tue, 10 Mar 2020 00:10:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3AB7824655 for ; Tue, 10 Mar 2020 00:10:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MIynxTGD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727518AbgCJAKF (ORCPT ); Mon, 9 Mar 2020 20:10:05 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:34124 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726937AbgCJAKE (ORCPT ); Mon, 9 Mar 2020 20:10:04 -0400 Received: by mail-lf1-f66.google.com with SMTP id i19so3392327lfl.1 for ; Mon, 09 Mar 2020 17:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qgrrl/PIS4y9k8c+4r54kiLV+rLBtZ0nrsWDLZmeMn4=; b=MIynxTGDbmrJlCOvfmOik94Q8oGE0PsOjavcV+1d61XGYkRoLB1qrCJIi8VIhezGuR sMIhJZjGAfnmbCB/ldF9KkgTjYgL9aHpUWFKOH7MjRLCAakxN1pw5bsnfSC/v0H8kKsL zNhp/U/O8wx+lJ60wHTqEajE8uSFkfo4bulvlBhsjHmJOMQr7qLMz/wtXhQaWK2DgKs7 ULYhtHP6mxfbf0vk1XeDO61EfEW/SECdbsUMxFJZIGLTTUBQBLPP8o3g+RGbJpNkkqAx RpL4g4roKcNrreA2utPOR8gust4fdB8coMyE/9t3o5dg3Xntr0bpe/Zfbrz50BSMk/yW RTAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qgrrl/PIS4y9k8c+4r54kiLV+rLBtZ0nrsWDLZmeMn4=; b=eCLHTbK+NbjchXQFjd691D/02nvCTTiPAlz/+uWwBtX6gMPCpyW89wUyIsngIpbXPX x+AkNH92xVXC2L7E492Pe0RieszNypMr1q/SIB1TgFz+m28rXEgB9WyYiw9uTO2yzQqE y+7LbpS9GoseTj7fX5V2uMy3yh7sD9b3zxT35oSd5N60KiVRq7EhoprgObG9Vl3T9NNK Z0zC4XCqgXdVNXnyhNwbBHNuaHlkyVA+4enX3yDxIFTiR+GhFaeDH3SsuxmY8GCC2HHd yLQlTIcC7ICSIbdG/XnbuHDCcLtGZ8ULR7Xgxy8hkHmGWPnm4qyX6pVQx9quD8iucaHg IJ/w== X-Gm-Message-State: ANhLgQ03ZuqJ4vgxTzmyFv5irxHxz+z0vh4fmkn+w0UpaGTE9xhCRPQg 8TYCRGqpksope1/MUp+XnJUFFYuvT1iFHWR1PKJjvw== X-Google-Smtp-Source: ADFU+vt32UZtqnvEuXoVRdT8OyeT2tec9wmF5Ooht3N0fo2TBipeo6oX7FEFlDeeQ7mewl8OPgZY6Eb6w2C2DpYd0jY= X-Received: by 2002:a05:6512:512:: with SMTP id o18mr10503227lfb.122.1583799000954; Mon, 09 Mar 2020 17:10:00 -0700 (PDT) MIME-Version: 1.0 References: <20200305012338.219746-1-rajatja@google.com> <20200305012338.219746-3-rajatja@google.com> <87o8tbnnqa.fsf@intel.com> <87tv31om53.fsf@intel.com> In-Reply-To: From: Rajat Jain Date: Mon, 9 Mar 2020 17:09:23 -0700 Message-ID: Subject: Re: [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors To: Jani Nikula Cc: Maarten Lankhorst , Maxime Ripard , Sean Paul , David Airlie , Daniel Vetter , Joonas Lahtinen , Rodrigo Vivi , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Chris Wilson , Imre Deak , =?UTF-8?Q?Jos=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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 6, 2020 at 5:38 PM Rajat Jain wrote: > > On Fri, Mar 6, 2020 at 1:42 AM Jani Nikula wrote: > > > > 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. > > Thinking about it again, it looks like there is a difference in > creating a property and attaching a property. I'm wondering if drm > would let me (unconditionally) create a property before registering, > and attach it in late_register() only in case a privacy screen is > detected. (If not present, I can destroy the property in > late_register()). If this approach sound more promising, I can try it > out. I tried out this approach, and it worked. The new patchset is posted at: https://patchwork.freedesktop.org/series/74473/#rev1 Thanks! Rajat > > > > > >> 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. > > I propose that we: > > 1) Maintain a display_index[] array within the drm_dev, and increment > as connectors are added. > 2) Initialize connector->acpi_device_id and and connector->acpi_handle > while registering (one time per connector). > 3) Remove the code to update acpi_device_id on every resume. > > It doesn't look like anyone on the DP MST side has cared for ACPI so > far, so I doubt if we can do anything that might break MST currently. > In other words, the above should not make things any worse for MST, if > not better. For connectors other than MST, this should allow them to > get ACPI handle and play with it, if they need. > > WDYT? > > Thanks, > > Rajat > > > > > >> (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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F99AC10F27 for ; Tue, 10 Mar 2020 08:19:37 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 47C412253D for ; Tue, 10 Mar 2020 08:19:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="MIynxTGD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47C412253D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9ED3D6E81F; Tue, 10 Mar 2020 08:19:13 +0000 (UTC) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by gabe.freedesktop.org (Postfix) with ESMTPS id E8F446E5BD for ; Tue, 10 Mar 2020 00:10:02 +0000 (UTC) Received: by mail-lf1-x142.google.com with SMTP id j17so4788644lfe.7 for ; Mon, 09 Mar 2020 17:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qgrrl/PIS4y9k8c+4r54kiLV+rLBtZ0nrsWDLZmeMn4=; b=MIynxTGDbmrJlCOvfmOik94Q8oGE0PsOjavcV+1d61XGYkRoLB1qrCJIi8VIhezGuR sMIhJZjGAfnmbCB/ldF9KkgTjYgL9aHpUWFKOH7MjRLCAakxN1pw5bsnfSC/v0H8kKsL zNhp/U/O8wx+lJ60wHTqEajE8uSFkfo4bulvlBhsjHmJOMQr7qLMz/wtXhQaWK2DgKs7 ULYhtHP6mxfbf0vk1XeDO61EfEW/SECdbsUMxFJZIGLTTUBQBLPP8o3g+RGbJpNkkqAx RpL4g4roKcNrreA2utPOR8gust4fdB8coMyE/9t3o5dg3Xntr0bpe/Zfbrz50BSMk/yW RTAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qgrrl/PIS4y9k8c+4r54kiLV+rLBtZ0nrsWDLZmeMn4=; b=FO6W6MXWPgstyMkVbrc1qjFEMD3s1VglgnxitHBEdSEvQxirNBgAuTBIulUbuxzNIs 2HuEFeL9K3opJxLsx/g8RiQ6w68dxl0uAxyh0pLAy3ePuQTp9OqedoBpApP2Mo3NiUZw +rquCS28QEfbWkBnWDdLYG4kBqUxzJW6BxHeVj2qwGT0X0TyrS/jNoNY/HKW+YgYuelO IoBQJ9uaXXB4Vt91q+r4Qm0rBt15dMKV1T5Qz/1wPtqm8bgr+dekaP7/xrdBE/aWUQBB LB+kMMdD0y0e7d11YF4u4UBYN9ju07lqte2cOeQSLVSGPdjYE+MAAiPXeYqEAwS2Jyh7 X8Jw== X-Gm-Message-State: ANhLgQ0RpYAn++X76KfelMYeUrwr/GmYI+kGU4/idTTeNX70Et9tOfF1 k91+1mo8CLzyka8g9thPdu+vOm5wVKEYp9WM8S4HDQ== X-Google-Smtp-Source: ADFU+vt32UZtqnvEuXoVRdT8OyeT2tec9wmF5Ooht3N0fo2TBipeo6oX7FEFlDeeQ7mewl8OPgZY6Eb6w2C2DpYd0jY= X-Received: by 2002:a05:6512:512:: with SMTP id o18mr10503227lfb.122.1583799000954; Mon, 09 Mar 2020 17:10:00 -0700 (PDT) MIME-Version: 1.0 References: <20200305012338.219746-1-rajatja@google.com> <20200305012338.219746-3-rajatja@google.com> <87o8tbnnqa.fsf@intel.com> <87tv31om53.fsf@intel.com> In-Reply-To: From: Rajat Jain Date: Mon, 9 Mar 2020 17:09:23 -0700 Message-ID: Subject: Re: [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors To: Jani Nikula X-Mailman-Approved-At: Tue, 10 Mar 2020 08:19:05 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sean Paul , David Airlie , Sugumaran Lacshiminarayanan , dri-devel , Thierry Reding , Daniel Thompson , Jonathan Corbet , Mark Pearson , Tomoki Maruichi , Jesse Barnes , Rajat Jain , intel-gfx@lists.freedesktop.org, Mat King , =?UTF-8?Q?Jos=C3=A9_Roberto_de_Souza?= , Rodrigo Vivi , Sean Paul , Duncan Laurie , Greg Kroah-Hartman , Linux Kernel Mailing List , Pavel Machek , Nitin Joshi1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Mar 6, 2020 at 5:38 PM Rajat Jain wrote: > > On Fri, Mar 6, 2020 at 1:42 AM Jani Nikula wrote: > > > > 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. > > Thinking about it again, it looks like there is a difference in > creating a property and attaching a property. I'm wondering if drm > would let me (unconditionally) create a property before registering, > and attach it in late_register() only in case a privacy screen is > detected. (If not present, I can destroy the property in > late_register()). If this approach sound more promising, I can try it > out. I tried out this approach, and it worked. The new patchset is posted at: https://patchwork.freedesktop.org/series/74473/#rev1 Thanks! Rajat > > > > > >> 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. > > I propose that we: > > 1) Maintain a display_index[] array within the drm_dev, and increment > as connectors are added. > 2) Initialize connector->acpi_device_id and and connector->acpi_handle > while registering (one time per connector). > 3) Remove the code to update acpi_device_id on every resume. > > It doesn't look like anyone on the DP MST side has cared for ACPI so > far, so I doubt if we can do anything that might break MST currently. > In other words, the above should not make things any worse for MST, if > not better. For connectors other than MST, this should allow them to > get ACPI handle and play with it, if they need. > > WDYT? > > Thanks, > > Rajat > > > > > >> (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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83436C10F25 for ; Tue, 10 Mar 2020 00:10:04 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 544862253D for ; Tue, 10 Mar 2020 00:10:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="MIynxTGD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 544862253D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A8DC86E5BD; Tue, 10 Mar 2020 00:10:03 +0000 (UTC) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by gabe.freedesktop.org (Postfix) with ESMTPS id 00CCF6E5BE for ; Tue, 10 Mar 2020 00:10:02 +0000 (UTC) Received: by mail-lf1-x143.google.com with SMTP id q10so8580033lfo.8 for ; Mon, 09 Mar 2020 17:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qgrrl/PIS4y9k8c+4r54kiLV+rLBtZ0nrsWDLZmeMn4=; b=MIynxTGDbmrJlCOvfmOik94Q8oGE0PsOjavcV+1d61XGYkRoLB1qrCJIi8VIhezGuR sMIhJZjGAfnmbCB/ldF9KkgTjYgL9aHpUWFKOH7MjRLCAakxN1pw5bsnfSC/v0H8kKsL zNhp/U/O8wx+lJ60wHTqEajE8uSFkfo4bulvlBhsjHmJOMQr7qLMz/wtXhQaWK2DgKs7 ULYhtHP6mxfbf0vk1XeDO61EfEW/SECdbsUMxFJZIGLTTUBQBLPP8o3g+RGbJpNkkqAx RpL4g4roKcNrreA2utPOR8gust4fdB8coMyE/9t3o5dg3Xntr0bpe/Zfbrz50BSMk/yW RTAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qgrrl/PIS4y9k8c+4r54kiLV+rLBtZ0nrsWDLZmeMn4=; b=F/mRBJWzWzNt4GFI8TnX/I24WFzPKN8VL8GIJUBzEGu7zvsMmn586hE5S8NdYvPid4 1ea4/WEmjHB0GwZ2NyI+J1JgBcP1e/yemob0taHNUSpAj1WBa/6jbtk9OsYMwJ62OhAe c3l/Su4u9bZ8gA1/n9yfZBNnBFmXmL80ndQAQBU3WiAzSkBESZqHZMek6/Qf8Fho0zPd 7LyEpfEPdZAd+N6qHtbWtXiw2MC+F/3f+zyPZ5frps8isUW3JIjWb4ikx1sZlwcmwLta DyZOdeFXg7TVVfcSLdlfvYUdyQOy2k4nTiA8eO77WsxWkcg5q7RQ0y4K2NhD6NXydlJD Gl4g== X-Gm-Message-State: ANhLgQ1aVcGIV80ay6Rk2CANKKfCHpNzfwbNWHh0Io4pMeRAzIeyHHW5 ianWnOQS9RPTkJ66UtOm293Ot78VHK/X54PJoop0KA== X-Google-Smtp-Source: ADFU+vt32UZtqnvEuXoVRdT8OyeT2tec9wmF5Ooht3N0fo2TBipeo6oX7FEFlDeeQ7mewl8OPgZY6Eb6w2C2DpYd0jY= X-Received: by 2002:a05:6512:512:: with SMTP id o18mr10503227lfb.122.1583799000954; Mon, 09 Mar 2020 17:10:00 -0700 (PDT) MIME-Version: 1.0 References: <20200305012338.219746-1-rajatja@google.com> <20200305012338.219746-3-rajatja@google.com> <87o8tbnnqa.fsf@intel.com> <87tv31om53.fsf@intel.com> In-Reply-To: From: Rajat Jain Date: Mon, 9 Mar 2020 17:09:23 -0700 Message-ID: To: Jani Nikula Subject: Re: [Intel-gfx] [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sean Paul , David Airlie , Sugumaran Lacshiminarayanan , dri-devel , Daniel Thompson , Jonathan Corbet , Mark Pearson , Tomoki Maruichi , Rajat Jain , intel-gfx@lists.freedesktop.org, Maxime Ripard , Mat King , Duncan Laurie , Greg Kroah-Hartman , Linux Kernel Mailing List , Pavel Machek , Nitin Joshi1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Fri, Mar 6, 2020 at 5:38 PM Rajat Jain wrote: > > On Fri, Mar 6, 2020 at 1:42 AM Jani Nikula wrote: > > > > 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. > > Thinking about it again, it looks like there is a difference in > creating a property and attaching a property. I'm wondering if drm > would let me (unconditionally) create a property before registering, > and attach it in late_register() only in case a privacy screen is > detected. (If not present, I can destroy the property in > late_register()). If this approach sound more promising, I can try it > out. I tried out this approach, and it worked. The new patchset is posted at: https://patchwork.freedesktop.org/series/74473/#rev1 Thanks! Rajat > > > > > >> 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. > > I propose that we: > > 1) Maintain a display_index[] array within the drm_dev, and increment > as connectors are added. > 2) Initialize connector->acpi_device_id and and connector->acpi_handle > while registering (one time per connector). > 3) Remove the code to update acpi_device_id on every resume. > > It doesn't look like anyone on the DP MST side has cared for ACPI so > far, so I doubt if we can do anything that might break MST currently. > In other words, the above should not make things any worse for MST, if > not better. For connectors other than MST, this should allow them to > get ACPI handle and play with it, if they need. > > WDYT? > > Thanks, > > Rajat > > > > > >> (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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx