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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,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 F0F8BC433B4 for ; Tue, 11 May 2021 17:00:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BCE67617C9 for ; Tue, 11 May 2021 17:00:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231476AbhEKRBx (ORCPT ); Tue, 11 May 2021 13:01:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231230AbhEKRBw (ORCPT ); Tue, 11 May 2021 13:01:52 -0400 Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBB16C061574 for ; Tue, 11 May 2021 10:00:44 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id q7-20020a9d57870000b02902a5c2bd8c17so18109305oth.5 for ; Tue, 11 May 2021 10:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=+kc9oZEJ14VtCjgrFBVdOi9/5rD3BSHSZSNV5GjZufU=; b=PwB1lvevVfB5Kbm7k/H348W91Tj9WxfX+YOZ70lpfrPoOc2vzHtRmS5rzAxstsVpqY Zl0ZnQ2lcLSRGIrkT1mPSfwIH/C9/vw9xKaTCm97G55DwAuj0An0UPbRbckwhMyctHF/ Zgehk3RmB3QlbD21BR0O3H+D2qgTa39u0LNUA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=+kc9oZEJ14VtCjgrFBVdOi9/5rD3BSHSZSNV5GjZufU=; b=t0SU2lWcnwejiBy4W4N1IL5nqp7w9YdqwPFEEeE/6xv1oGDsR8HMEOMKgy8u3XfrMM bcTGUjpP2DssLrdTtlthXKhXnTdzTS2y3+0MU83q3P9zBjPEK1cCW3uSpulyQpBv3BJ+ xiKODUzbGxtRrCpVQv9kczGT6cTEzemkJnMoItbw9aSVQnjWGkEmzigp9APCmRW+KMB7 kqD+KP5Gj3l9Hk72GyeqZ3cgpcAREh7VpiHJUbm6/Gr1o5YsQtQMn8VbUktjvbau80Q3 Xi0U0KR1ThyRdPDAel7y/pLeSHWXT7l27YYEA2cXxcLz18abPtvxhXxWsmY2HVWxcW9m vYMA== X-Gm-Message-State: AOAM530dO6MJNIrnjYk7jCYT++YbtM/cWckQcJApBwx9jIVcftSpfUAu gDMExDVrn5pJ16OC//OwCRGZaUjVH197RINPOZkXueMRBwI= X-Google-Smtp-Source: ABdhPJzW1noUSaOfHP3CiUI7zDa9O8HOgGEUnZzp7SKJNkf/LeqfB00UDdoZldzFkZBlJffiYsv995L7sOx4TuPsCo4= X-Received: by 2002:a9d:425:: with SMTP id 34mr27097167otc.25.1620752444214; Tue, 11 May 2021 10:00:44 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 May 2021 10:00:43 -0700 MIME-Version: 1.0 In-Reply-To: References: <20210508074118.1621729-1-swboyd@chromium.org> From: Stephen Boyd User-Agent: alot/0.9.1 Date: Tue, 11 May 2021 10:00:43 -0700 Message-ID: Subject: Re: [PATCH] component: Move host device to end of device lists on binding To: "Rafael J. Wysocki" Cc: Daniel Vetter , Greg Kroah-Hartman , Linux Kernel Mailing List , Russell King , Rob Clark , dri-devel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Rafael J. Wysocki (2021-05-11 03:52:06) > On Mon, May 10, 2021 at 9:08 PM Stephen Boyd wrote: > > [cut] > > > > > > > > > > I will try it, but then I wonder about things like system wide > > > > suspend/resume too. The drm encoder chain would need to reimplement the > > > > logic for system wide suspend/resume so that any PM ops attached to the > > > > msm device run in the correct order. Right now the bridge PM ops will > > > > run, the i2c bus PM ops will run, and then the msm PM ops will run. > > > > After this change, the msm PM ops will run, the bridge PM ops will run, > > > > and then the i2c bus PM ops will run. It feels like that could be a > > > > problem if we're suspending the DSI encoder while the bridge is still > > > > active. > > > > > > Yup suspend/resume has the exact same problem as shutdown. > > > > I think suspend/resume has the exact opposite problem. At least I think > > the correct order is to suspend the bridge, then the encoder, i.e. DSI, > > like is happening today. It looks like drm_atomic_helper_shutdown() > > operates from the top down when we want bottom up? I admit I have no > > idea what is supposed to happen here. > > Why would the system-wide suspend ordering be different from the > shutdown ordering? I don't really know. I'm mostly noting that today the order of suspend is to suspend the bridge device first and then the aggregate device. If the suspend of the aggregate device is traversing the devices like drm_atomic_helper_shutdown() then it would operate on the bridge device after it has been suspended, like is happening during shutdown. But it looks like that isn't happening. At least for the msm driver we're suspending the aggregate device after the bridge, and there are some weird usages of prepare and complete in there (see msm_pm_prepare() and msm_pm_complete) which makes me think that it's all working around this component code. The prepare phase is going to suspend the display pipeline, and then the bridge device will run its suspend hooks, and then the aggregate driver will run its suspend hooks. If we had a proper device for the aggregate device instead of the bind/unbind component hooks we could clean this up. 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,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 4D2ADC433ED for ; Tue, 11 May 2021 17:00:47 +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 BAC73610C9 for ; Tue, 11 May 2021 17:00:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAC73610C9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 02CFB6E7D1; Tue, 11 May 2021 17:00:46 +0000 (UTC) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by gabe.freedesktop.org (Postfix) with ESMTPS id E23066EA85 for ; Tue, 11 May 2021 17:00:44 +0000 (UTC) Received: by mail-ot1-x336.google.com with SMTP id d3-20020a9d29030000b029027e8019067fso18053063otb.13 for ; Tue, 11 May 2021 10:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=+kc9oZEJ14VtCjgrFBVdOi9/5rD3BSHSZSNV5GjZufU=; b=PwB1lvevVfB5Kbm7k/H348W91Tj9WxfX+YOZ70lpfrPoOc2vzHtRmS5rzAxstsVpqY Zl0ZnQ2lcLSRGIrkT1mPSfwIH/C9/vw9xKaTCm97G55DwAuj0An0UPbRbckwhMyctHF/ Zgehk3RmB3QlbD21BR0O3H+D2qgTa39u0LNUA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=+kc9oZEJ14VtCjgrFBVdOi9/5rD3BSHSZSNV5GjZufU=; b=XVo7CmCQcnt1OVcFkXlSihW78at5uCU6zt9MyvXSklc+E3azhI0kwsapq0RATmKli9 im59v4xmOjxFsUB5pFw87zxK7B6DFcRaw2nlOVGua9PzLsfXdHIPWkqEUMfSPuIBnfll vccPZlmHNjSr5SS9/kCoX1jT5Dh+LMRg1A66Oys67BPaEPovDInrisvZ6RDD2PEmhNIJ 4IRcetvIF4cIWX7Dtd4ysAeQmEmSvYJh+e74OLEW3xfyNN+wr/C735pEMB+H+AMdB4Se pJ7juyfQXr01ayrn2jE/fLCKFzkV7gfPKjNdSKASeJKbMe4GsAhmFH+LOZLLYzCPLm9t +u5w== X-Gm-Message-State: AOAM531vIZiuyomoNhl9MuKDv2mYX2EAK9kfdjDOtGg4n8RuGE5QjcLg oH9SlRukpF+1Mr4bB0ZBOzsB36QNSB4pOZdM8hq+1Q== X-Google-Smtp-Source: ABdhPJzW1noUSaOfHP3CiUI7zDa9O8HOgGEUnZzp7SKJNkf/LeqfB00UDdoZldzFkZBlJffiYsv995L7sOx4TuPsCo4= X-Received: by 2002:a9d:425:: with SMTP id 34mr27097167otc.25.1620752444214; Tue, 11 May 2021 10:00:44 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 May 2021 10:00:43 -0700 MIME-Version: 1.0 In-Reply-To: References: <20210508074118.1621729-1-swboyd@chromium.org> From: Stephen Boyd User-Agent: alot/0.9.1 Date: Tue, 11 May 2021 10:00:43 -0700 Message-ID: Subject: Re: [PATCH] component: Move host device to end of device lists on binding To: "Rafael J. Wysocki" Content-Type: text/plain; charset="UTF-8" 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: Greg Kroah-Hartman , Linux Kernel Mailing List , dri-devel , Russell King Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Quoting Rafael J. Wysocki (2021-05-11 03:52:06) > On Mon, May 10, 2021 at 9:08 PM Stephen Boyd wrote: > > [cut] > > > > > > > > > > I will try it, but then I wonder about things like system wide > > > > suspend/resume too. The drm encoder chain would need to reimplement the > > > > logic for system wide suspend/resume so that any PM ops attached to the > > > > msm device run in the correct order. Right now the bridge PM ops will > > > > run, the i2c bus PM ops will run, and then the msm PM ops will run. > > > > After this change, the msm PM ops will run, the bridge PM ops will run, > > > > and then the i2c bus PM ops will run. It feels like that could be a > > > > problem if we're suspending the DSI encoder while the bridge is still > > > > active. > > > > > > Yup suspend/resume has the exact same problem as shutdown. > > > > I think suspend/resume has the exact opposite problem. At least I think > > the correct order is to suspend the bridge, then the encoder, i.e. DSI, > > like is happening today. It looks like drm_atomic_helper_shutdown() > > operates from the top down when we want bottom up? I admit I have no > > idea what is supposed to happen here. > > Why would the system-wide suspend ordering be different from the > shutdown ordering? I don't really know. I'm mostly noting that today the order of suspend is to suspend the bridge device first and then the aggregate device. If the suspend of the aggregate device is traversing the devices like drm_atomic_helper_shutdown() then it would operate on the bridge device after it has been suspended, like is happening during shutdown. But it looks like that isn't happening. At least for the msm driver we're suspending the aggregate device after the bridge, and there are some weird usages of prepare and complete in there (see msm_pm_prepare() and msm_pm_complete) which makes me think that it's all working around this component code. The prepare phase is going to suspend the display pipeline, and then the bridge device will run its suspend hooks, and then the aggregate driver will run its suspend hooks. If we had a proper device for the aggregate device instead of the bind/unbind component hooks we could clean this up.