From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2 3/8] drm/i915/psr: Avoid initializing PSR if there is no sink support.
Date: Wed, 3 Jan 2018 13:59:11 -0800 [thread overview]
Message-ID: <20180103215911.66dk2mwghwb4r4wi@intel.com> (raw)
In-Reply-To: <1513720900.22022.28.camel@dk-H97M-D3H>
first of all sorry for not getting back sooner on this...
On Tue, Dec 19, 2017 at 09:40:01PM +0000, Pandiyan, Dhinakaran wrote:
>
>
>
> On Tue, 2017-12-19 at 13:29 -0800, Rodrigo Vivi wrote:
> > On Tue, Dec 19, 2017 at 05:26:54AM +0000, Dhinakaran Pandiyan wrote:
> > > DPCD read for the eDP is complete by the time intel_psr_init() is
> > > called, which means we can avoid initializing PSR structures and state
> > > if there is no sink support.
> > >
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 7 ++++++-
> > > drivers/gpu/drm/i915/intel_psr.c | 9 +++++++++
> > > 2 files changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 64e5a263458c..1a7b28f62570 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2532,14 +2532,19 @@ static int i915_edp_psr_status(struct seq_file *m, void *data)
> > > u32 stat[3];
> > > enum pipe pipe;
> > > bool enabled = false;
> > > + bool sink_support;
> > >
> > > if (!HAS_PSR(dev_priv))
> > > return -ENODEV;
> > >
> > > + sink_support = dev_priv->psr.sink_support;
> > > + seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
> > > + if (!sink_support)
> > > + return 0;
> > > +
> > > intel_runtime_pm_get(dev_priv);
> > >
> > > mutex_lock(&dev_priv->psr.lock);
> > > - seq_printf(m, "Sink_Support: %s\n", yesno(dev_priv->psr.sink_support));
> > > seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> > > seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
> > > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
> > > index 76339cf387cb..095e0a5a8574 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -503,6 +503,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> > > if (!crtc_state->has_psr)
> > > return;
> > >
> > > + if (WARN_ON(!CAN_PSR(dev_priv)))
> > > + return;
> >
> > hmm... I believe we will see this warning sooner than later...
> >
> > has_psr is not the same as CAN_PSR.
>
> has_psr should not be set in psr_compute_config() unless both source and
> sink have PSR. So, the warn_on is if we mess up the state preparation.
> >
> > also, btw I didn't like all this crtc_state has_psr x has_psr2. :/
> >
> > probably this series could also unify that and clean it up.
> > to many has_psr like cases.
> >
> > > +
> > > WARN_ON(dev_priv->drrs.dp);
> > > mutex_lock(&dev_priv->psr.lock);
> > > if (dev_priv->psr.enabled) {
> > > @@ -633,6 +636,9 @@ void intel_psr_disable(struct intel_dp *intel_dp,
> > > if (!old_crtc_state->has_psr)
> > > return;
> > >
> > > + if (WARN_ON(!CAN_PSR(dev_priv)))
> > > + return;
> > > +
> > > mutex_lock(&dev_priv->psr.lock);
> > > if (!dev_priv->psr.enabled) {
> > > mutex_unlock(&dev_priv->psr.lock);
> > > @@ -913,6 +919,9 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> > > dev_priv->psr_mmio_base = IS_HASWELL(dev_priv) ?
> > > HSW_EDP_PSR_BASE : BDW_EDP_PSR_BASE;
> > >
> > > + if (!dev_priv->psr.sink_support)
> > > + return;
> > > +
> >
> > Why not use CAN_PSR here?
>
>
> So that we have the right MMIO's in case we want to probe the HW with no
> sink support. I wasn't what would happen if we reg_read() on PSR
> registers without the correct MMIO base.
But isn't the goal of CAN_PSR to avoid any extra calls on platforms
that either doesn't have support nor the panel? In this case we should
never being touching any register.
>
> >
> > > /* Per platform default: all disabled. */
> > > if (i915_modparams.enable_psr == -1)
> > > i915_modparams.enable_psr = 0;
> > > --
> > > 2.11.0
> > >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-01-03 21:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 5:26 [PATCH v2 0/8] Fix PSR-vblank-DMC interaction Dhinakaran Pandiyan
2017-12-19 5:26 ` [PATCH v2 1/8] drm/i915/psr: Kill psr.source_ok flag Dhinakaran Pandiyan
2017-12-19 21:16 ` Rodrigo Vivi
2017-12-19 5:26 ` [PATCH v2 2/8] drm/i915/psr: CAN_PSR() macro to check for PSR source and sink support Dhinakaran Pandiyan
2017-12-19 21:23 ` Rodrigo Vivi
2017-12-19 5:26 ` [PATCH v2 3/8] drm/i915/psr: Avoid initializing PSR if there is no " Dhinakaran Pandiyan
2017-12-19 21:29 ` Rodrigo Vivi
2017-12-19 21:40 ` Pandiyan, Dhinakaran
2018-01-03 21:59 ` Rodrigo Vivi [this message]
2017-12-19 5:26 ` [PATCH v2 4/8] drm/vblank: Do not update vblank counts if vblanks are already disabled Dhinakaran Pandiyan
2017-12-19 5:26 ` [PATCH v2 5/8] drm/vblank: Restoring vblank counts after device runtime PM events Dhinakaran Pandiyan
2017-12-19 5:26 ` [PATCH v2 6/8] drm/i915: Use an atomic_t array to track power domain use count Dhinakaran Pandiyan
2017-12-21 12:37 ` Maarten Lankhorst
2017-12-22 6:13 ` Pandiyan, Dhinakaran
2017-12-19 5:26 ` [PATCH v2 7/8] drm/i915: Introduce a non-blocking power domain for vblank interrupts Dhinakaran Pandiyan
2017-12-19 21:41 ` Rodrigo Vivi
2017-12-19 23:20 ` Pandiyan, Dhinakaran
2017-12-19 5:26 ` [PATCH v2 8/8] drm/i915: Use the vblank power domain disallow or disable DC states Dhinakaran Pandiyan
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=20180103215911.66dk2mwghwb4r4wi@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=dhinakaran.pandiyan@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox