From: Dmitry Osipenko <email@example.com> To: Thierry Reding <firstname.lastname@example.org> Cc: email@example.com, "Rafael J. Wysocki" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 2/2] drm/tegra: Do not implement runtime PM Date: Wed, 4 Dec 2019 18:22:19 +0300 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 03.12.2019 19:27, Thierry Reding пишет: > From: Thierry Reding <email@example.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 <firstname.lastname@example.org> > --- 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?
prev parent reply index Thread overview: 5+ 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 ` [PATCH 2/2] drm/tegra: Do not implement runtime PM Thierry Reding 2019-12-04 8:37 ` Mikko Perttunen 2019-12-04 9:36 ` Thierry Reding 2019-12-04 15:22 ` Dmitry Osipenko [this message]
Reply instructions: You may reply publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
Linux-PM Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-pm/0 linux-pm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-pm linux-pm/ https://lore.kernel.org/linux-pm \ firstname.lastname@example.org public-inbox-index linux-pm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git