From: Lucas Stach <dev@lynxeye.de>
To: Dmitry Osipenko <digetx@gmail.com>,
Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] drm/tegra: Support disabled CONFIG_PM
Date: Fri, 15 Dec 2017 21:25:32 +0100 [thread overview]
Message-ID: <1513369532.16053.6.camel@lynxeye.de> (raw)
In-Reply-To: <f20a67a1-92c6-2dff-aa60-958801e53c06@gmail.com>
Am Freitag, den 15.12.2017, 01:45 +0300 schrieb Dmitry Osipenko:
> On 15.12.2017 00:41, Lucas Stach wrote:
> > Am Montag, den 11.12.2017, 18:26 +0300 schrieb Dmitry Osipenko:
> > > On 11.12.2017 17:27, Thierry Reding wrote:
> > > > On Mon, Dec 11, 2017 at 04:53:56PM +0300, Dmitry Osipenko
> > > > wrote:
> > > > > On 11.12.2017 13:13, Thierry Reding wrote:
> > > > > > On Mon, Dec 11, 2017 at 02:19:44AM +0300, Dmitry Osipenko
> > > > > > wrote:
> > > > > > > Add manual HW power management to drivers probe/remove in
> > > > > > > order to
> > > > > > > not fail in a case of runtime power management being
> > > > > > > disabled
> > > > > > > in kernel
> > > > > > > config.
> > > > > > >
> > > > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> > > > > > > ---
> > > > > > > drivers/gpu/drm/tegra/dc.c | 164
> > > > > > > +++++++++++++++++++++++++++----------------
> > > > > > > drivers/gpu/drm/tegra/dsi.c | 138
> > > > > > > +++++++++++++++++++++--
> > > > > > > -------------
> > > > > > > drivers/gpu/drm/tegra/hdmi.c | 90 ++++++++++++++++-----
> > > > > > > ---
> > > > > > > drivers/gpu/drm/tegra/sor.c | 103 +++++++++++++++++--
> > > > > > > ----
> > > > > > > ----
> > > > > > > 4 files changed, 310 insertions(+), 185 deletions(-)
> > > > > >
> > > > > > I think that's the wrong way around. We unconditionally
> > > > > > select
> > > > > > PM on
> > > > > > 64-bit ARM already, and I think we should do the same on
> > > > > > 32-bit
> > > > > > ARM.
> > > > > > There's really no excuse not to enable runtime PM these
> > > > > > days.
> > > > >
> > > > > What is the rational behind enabling PM unconditionally? It
> > > > > is
> > > > > actually a very
> > > > > useful debug feature when there is something wrong with the
> > > > > PM.
> > > > > It looks like
> > > > > Tegra DRM driver is the only driver on Tegra that doesn't
> > > > > work
> > > > > properly with PM
> > > > > being disabled. Please, let's just fix it.
> > > >
> > > > What's useful about disabling PM? The problem with allowing !PM
> > > > is
> > > > that
> > > > it adds one more combination that needs to be build- and
> > > > runtime
> > > > tested.
> > >
> > > As I already stated, disabling PM is very useful for debugging
> > > when
> > > system hangs
> > > unexpectedly. I found it very helpful several times.
> >
> > This assumes that the bootloader/firmware left the power domains
> > powered up. Without PM_GENERIC_DOMAINS, which depends on CONFIG_PM
> > the
> > kernel has no means to control the state of the power domains.
> > Probe
> > deferral based on the power domain will also not work, so driver
> > may
> > probe and try to access power-gated devices, leading to system
> > hangs in
> > the common case.
>
> Pre-186 Tegra's do not use generic PM domains, but a custom API.
> Meanwhile T186
> always has CONFIG_PM enabled.
This is incorrect since a38045121bf4 (soc/tegra: pmc: Add generic PM
domain support), i.e. kernel 4.7.
Regards,
Lucas
next prev parent reply other threads:[~2017-12-15 20:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-10 23:19 [PATCH v1 1/2] drm/tegra: dc: Link DC1 to DC0 on Tegra20 Dmitry Osipenko
2017-12-10 23:19 ` [PATCH v1 2/2] drm/tegra: Support disabled CONFIG_PM Dmitry Osipenko
2017-12-11 10:13 ` Thierry Reding
2017-12-11 13:53 ` Dmitry Osipenko
2017-12-11 14:08 ` Dmitry Osipenko
2017-12-11 14:27 ` Thierry Reding
2017-12-11 15:26 ` Dmitry Osipenko
2017-12-14 21:41 ` Lucas Stach
2017-12-14 22:45 ` Dmitry Osipenko
2017-12-15 20:25 ` Lucas Stach [this message]
2017-12-15 20:54 ` Dmitry Osipenko
2017-12-14 23:19 ` Dmitry Osipenko
2017-12-11 10:12 ` [PATCH v1 1/2] drm/tegra: dc: Link DC1 to DC0 on Tegra20 Thierry Reding
2017-12-11 14:59 ` 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=1513369532.16053.6.camel@lynxeye.de \
--to=dev@lynxeye.de \
--cc=digetx@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome