From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Daniel Vetter <daniel@ffwll.ch>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Russell King <rmk+kernel@arm.linux.org.uk>,
Rob Clark <robdclark@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] component: Move host device to end of device lists on binding
Date: Tue, 11 May 2021 12:52:06 +0200 [thread overview]
Message-ID: <CAJZ5v0h42fTKueFxrB6fpc9YBVNyDsCBryAf_geS-=0+OQQqjg@mail.gmail.com> (raw)
In-Reply-To: <CAE-0n50d8_OtZTpBGaz0uhj6AO823_kwHg9+SJK6ar=e+rGxFA@mail.gmail.com>
On Mon, May 10, 2021 at 9:08 PM Stephen Boyd <swboyd@chromium.org> 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?
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Russell King <rmk+kernel@arm.linux.org.uk>
Subject: Re: [PATCH] component: Move host device to end of device lists on binding
Date: Tue, 11 May 2021 12:52:06 +0200 [thread overview]
Message-ID: <CAJZ5v0h42fTKueFxrB6fpc9YBVNyDsCBryAf_geS-=0+OQQqjg@mail.gmail.com> (raw)
In-Reply-To: <CAE-0n50d8_OtZTpBGaz0uhj6AO823_kwHg9+SJK6ar=e+rGxFA@mail.gmail.com>
On Mon, May 10, 2021 at 9:08 PM Stephen Boyd <swboyd@chromium.org> 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?
next prev parent reply other threads:[~2021-05-11 10:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-08 7:41 [PATCH] component: Move host device to end of device lists on binding Stephen Boyd
2021-05-08 7:41 ` Stephen Boyd
2021-05-10 11:59 ` Rafael J. Wysocki
2021-05-10 11:59 ` Rafael J. Wysocki
2021-05-11 17:59 ` Saravana Kannan
2021-05-11 17:59 ` Saravana Kannan
2021-05-10 16:05 ` Daniel Vetter
2021-05-10 16:05 ` Daniel Vetter
2021-05-10 17:52 ` Stephen Boyd
2021-05-10 17:52 ` Stephen Boyd
2021-05-10 18:26 ` Daniel Vetter
2021-05-10 18:26 ` Daniel Vetter
2021-05-10 19:08 ` Stephen Boyd
2021-05-10 19:08 ` Stephen Boyd
2021-05-11 10:52 ` Rafael J. Wysocki [this message]
2021-05-11 10:52 ` Rafael J. Wysocki
2021-05-11 13:39 ` Daniel Vetter
2021-05-11 13:39 ` Daniel Vetter
2021-05-11 17:19 ` Stephen Boyd
2021-05-11 17:19 ` Stephen Boyd
2021-05-11 17:25 ` Daniel Vetter
2021-05-11 17:25 ` Daniel Vetter
2021-05-11 19:12 ` Saravana Kannan
2021-05-11 19:12 ` Saravana Kannan
2021-05-11 17:00 ` Stephen Boyd
2021-05-11 17:00 ` Stephen Boyd
2021-05-11 17:20 ` Rafael J. Wysocki
2021-05-11 17:20 ` Rafael J. Wysocki
2021-05-13 13:40 ` Russell King - ARM Linux admin
2021-05-13 13:40 ` Russell King - ARM Linux admin
2021-05-11 14:42 ` Russell King - ARM Linux admin
2021-05-11 14:42 ` Russell King - ARM Linux admin
2021-05-11 17:22 ` Stephen Boyd
2021-05-11 17:22 ` Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJZ5v0h42fTKueFxrB6fpc9YBVNyDsCBryAf_geS-=0+OQQqjg@mail.gmail.com' \
--to=rafael@kernel.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=robdclark@gmail.com \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.