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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 4B526C433B4 for ; Tue, 11 May 2021 13:39:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1084A6191E for ; Tue, 11 May 2021 13:39:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231530AbhEKNk6 (ORCPT ); Tue, 11 May 2021 09:40:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37330 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229921AbhEKNkz (ORCPT ); Tue, 11 May 2021 09:40:55 -0400 Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22EF3C061574 for ; Tue, 11 May 2021 06:39:48 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id x15so5273703oic.13 for ; Tue, 11 May 2021 06:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DiQlUoRS1KcIp4jb80Idacb5jWTO0UHM89k4RPNvhAM=; b=V0SPnP29kVRwVzyYu3yn381mPXr37L4GkNlTSpRf9Z1Lg+xnDbQdJV76vtPxr3dW8v G8wcNTNdk/tqvS8IWkyzfV/1AMa1opftnowZP2pvmspSIGvp1WMjZIONfBoapA12eCEl pif4tQNvizE6BFuH2BaDH4ht+YXXoHhWNA0fk= 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=DiQlUoRS1KcIp4jb80Idacb5jWTO0UHM89k4RPNvhAM=; b=ZqEK9DfkMNeH8nm8ijSGg160cq7kh5Y3NJCfiB4yD3dI+DxgQifp7nE9e2iaSJ/rKw k9f3rvHyXKNYSr9dl47JYAvBzpJWbH1aAV8w6oBayyvbb6az//ZJUSXWjwIqELYS1Jdm byzKDPoUT/sole4DophkDEHBw8rQhP2kt6gZYN9gAtNkCFvIbaHkmhxTz20Y+Hb7A2Qd LmO9/ua+UOguYFbFVhjh1+Z0bG1ZKgTfPBoAZ7VHKBTIVKQLQhJs+MchdfQKO+xYEwX9 oQcoTexffLz2LqPm/ejYdmANSwQFmsc0iMYjCOd1AiyXv3uvxKKD0TTngE9GoGIXWHI6 h/qQ== X-Gm-Message-State: AOAM532ZuEKMPbj4YsL6StidchVk3Djrv3qS3VpsXlFExjz2PB6EfDYE e0HA7ogYgOBnXPHwr4jAFTl//jvXzDqLnmJGtRdQSA== X-Google-Smtp-Source: ABdhPJypOemzDTmFObHTWqXEMZiMoy0D4neOiUWh21fpySuirlm4zFsGDyTRcXNm9CEqwqwnkS3yp1efP8vxyCLQf5s= X-Received: by 2002:aca:df87:: with SMTP id w129mr22385363oig.128.1620740387581; Tue, 11 May 2021 06:39:47 -0700 (PDT) MIME-Version: 1.0 References: <20210508074118.1621729-1-swboyd@chromium.org> In-Reply-To: From: Daniel Vetter Date: Tue, 11 May 2021 15:39:36 +0200 Message-ID: Subject: Re: [PATCH] component: Move host device to end of device lists on binding To: "Rafael J. Wysocki" Cc: Stephen Boyd , 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 On Tue, May 11, 2021 at 12:52 PM Rafael J. Wysocki wrote: > > 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? At least my point was that both shutdown and suspend/resume have the same problem, and the righ fix is (I think at least) to add these hooks to the component.c aggregate ops structure. Hence just adding new callbacks for shutdown will be an incomplete solution. I don't feel like changing the global device order is the right approach, since essentially that's what component was meant to fix. Except it's incomplete since it only provides a solution for bind/unbind and not for shutdown or suspend/resume as other global state changes. I think some drivers "fixed" this by putting stuff like drm_atomic_helper_shutdown/suspend/resume into early/late hooks, to make sure that everything is ready with that trick. But that doesn't compose very well :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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.6 required=3.0 tests=BAYES_00,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 B2691C433ED for ; Tue, 11 May 2021 13:39:50 +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 AF2B761264 for ; Tue, 11 May 2021 13:39:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AF2B761264 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 F3F0E6E216; Tue, 11 May 2021 13:39:48 +0000 (UTC) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by gabe.freedesktop.org (Postfix) with ESMTPS id 43DA06E216 for ; Tue, 11 May 2021 13:39:48 +0000 (UTC) Received: by mail-oi1-x233.google.com with SMTP id v22so14160375oic.2 for ; Tue, 11 May 2021 06:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DiQlUoRS1KcIp4jb80Idacb5jWTO0UHM89k4RPNvhAM=; b=V0SPnP29kVRwVzyYu3yn381mPXr37L4GkNlTSpRf9Z1Lg+xnDbQdJV76vtPxr3dW8v G8wcNTNdk/tqvS8IWkyzfV/1AMa1opftnowZP2pvmspSIGvp1WMjZIONfBoapA12eCEl pif4tQNvizE6BFuH2BaDH4ht+YXXoHhWNA0fk= 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=DiQlUoRS1KcIp4jb80Idacb5jWTO0UHM89k4RPNvhAM=; b=ZcvFrspBFQORnZ0NTKdeo2yEL1G+a8gwDmRawNXQlIeGfBLlkaktIcBgQlbwzKZkaC a1haxx6Aq1A+hTIFDFOKFrKNcZgCNz+0+gjnTKpicR7boov/nSDxt4jdcvO4od9KZlKi kBk68DXllodeW8Q/nLUwj/N0eKGFNg72RfeH19lslj3xRaaw4Re12J7dBMpYGpWl2occ NPYREXUuHsRErd/u0zXZV0o0xfIoHy6bNV/5mQW1CvKeJhZj1xLvqBeCwn4uxDNcWT1w kl4ZJqHYxPE4/vn7Auz+PbSjGQ90N7+yp5Ug1HJ1bdLphnWcWW9Y4NuKXxiQ6pf9ukM6 5h2w== X-Gm-Message-State: AOAM531XcnOrGmfdf8d42Y81Doh/+MULzm5HZvcAH8mMd7ByfmmKspfs xiWH4U8Gl8odJ2HbYC99wrd2mjSW9YI5BMrZb2Bf+Q== X-Google-Smtp-Source: ABdhPJypOemzDTmFObHTWqXEMZiMoy0D4neOiUWh21fpySuirlm4zFsGDyTRcXNm9CEqwqwnkS3yp1efP8vxyCLQf5s= X-Received: by 2002:aca:df87:: with SMTP id w129mr22385363oig.128.1620740387581; Tue, 11 May 2021 06:39:47 -0700 (PDT) MIME-Version: 1.0 References: <20210508074118.1621729-1-swboyd@chromium.org> In-Reply-To: From: Daniel Vetter Date: Tue, 11 May 2021 15:39:36 +0200 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 , Stephen Boyd , Russell King Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, May 11, 2021 at 12:52 PM Rafael J. Wysocki wrote: > > 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? At least my point was that both shutdown and suspend/resume have the same problem, and the righ fix is (I think at least) to add these hooks to the component.c aggregate ops structure. Hence just adding new callbacks for shutdown will be an incomplete solution. I don't feel like changing the global device order is the right approach, since essentially that's what component was meant to fix. Except it's incomplete since it only provides a solution for bind/unbind and not for shutdown or suspend/resume as other global state changes. I think some drivers "fixed" this by putting stuff like drm_atomic_helper_shutdown/suspend/resume into early/late hooks, to make sure that everything is ready with that trick. But that doesn't compose very well :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch