From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
dri-devel@lists.freedesktop.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/tegra: Do not implement runtime PM
Date: Wed, 4 Dec 2019 18:22:19 +0300 [thread overview]
Message-ID: <3d2b4fed-d2e6-bb4a-c94b-d493ba836661@gmail.com> (raw)
In-Reply-To: <20191203162733.1436800-2-thierry.reding@gmail.com>
03.12.2019 19:27, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
>
> The Tegra DRM driver heavily relies on the implementations for runtime
> suspend/resume to be called at specific times. Unfortunately, there are
> some cases where that doesn't work. One example is if the user disables
> runtime PM for a given subdevice. Another example is that the PM core
> acquires a reference to runtime PM during system sleep, effectively
> preventing devices from going into low power modes. This is intentional
> to avoid nasty race conditions, but it also causes system sleep to not
> function properly on all Tegra systems.
>
> Fix this by not implementing runtime PM at all. Instead, a minimal,
> reference-counted suspend/resume infrastructure is added to the host1x
> bus. This has the benefit that it can be used regardless of the system
> power state (or any transitions we might be in), or whether or not the
> user allows runtime PM.
>
> Atomic modesetting guarantees that these functions will end up being
> called at the right point in time, so the pitfalls for the more generic
> runtime PM do not apply here.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
Couldn't we just use pm_runtime_force_suspend/resume whenever it is
necessary to enforce the suspend/resume?
I briefly looked through the previous discussion and don't see why the
forced suspend/resume isn't suitable. Please excuse me if I'm missing
the point.
Why planes/outputs need to care about resuming DC controller at all?
Doesn't DRM core take care of enabling DC for us by enabling CRTC before
planes/outputs are enabled?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
dri-devel@lists.freedesktop.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/tegra: Do not implement runtime PM
Date: Wed, 4 Dec 2019 18:22:19 +0300 [thread overview]
Message-ID: <3d2b4fed-d2e6-bb4a-c94b-d493ba836661@gmail.com> (raw)
In-Reply-To: <20191203162733.1436800-2-thierry.reding@gmail.com>
03.12.2019 19:27, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
>
> The Tegra DRM driver heavily relies on the implementations for runtime
> suspend/resume to be called at specific times. Unfortunately, there are
> some cases where that doesn't work. One example is if the user disables
> runtime PM for a given subdevice. Another example is that the PM core
> acquires a reference to runtime PM during system sleep, effectively
> preventing devices from going into low power modes. This is intentional
> to avoid nasty race conditions, but it also causes system sleep to not
> function properly on all Tegra systems.
>
> Fix this by not implementing runtime PM at all. Instead, a minimal,
> reference-counted suspend/resume infrastructure is added to the host1x
> bus. This has the benefit that it can be used regardless of the system
> power state (or any transitions we might be in), or whether or not the
> user allows runtime PM.
>
> Atomic modesetting guarantees that these functions will end up being
> called at the right point in time, so the pitfalls for the more generic
> runtime PM do not apply here.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
Couldn't we just use pm_runtime_force_suspend/resume whenever it is
necessary to enforce the suspend/resume?
I briefly looked through the previous discussion and don't see why the
forced suspend/resume isn't suitable. Please excuse me if I'm missing
the point.
Why planes/outputs need to care about resuming DC controller at all?
Doesn't DRM core take care of enabling DC for us by enabling CRTC before
planes/outputs are enabled?
next prev parent reply other threads:[~2019-12-04 15:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 16:27 [PATCH 1/2] gpu: host1x: Rename "parent" to "host" Thierry Reding
2019-12-03 16:27 ` Thierry Reding
2019-12-03 16:27 ` [PATCH 2/2] drm/tegra: Do not implement runtime PM Thierry Reding
2019-12-03 16:27 ` Thierry Reding
2019-12-04 8:37 ` Mikko Perttunen
2019-12-04 8:37 ` Mikko Perttunen
2019-12-04 9:36 ` Thierry Reding
2019-12-04 9:36 ` Thierry Reding
2019-12-04 15:22 ` Dmitry Osipenko [this message]
2019-12-04 15:22 ` Dmitry Osipenko
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=3d2b4fed-d2e6-bb4a-c94b-d493ba836661@gmail.com \
--to=digetx@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=thierry.reding@gmail.com \
/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.