From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Jani Nikula <jani.nikula@intel.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] drm/i915: improve assert_panel_unlocked
Date: Fri, 22 Aug 2014 11:00:15 +0300 [thread overview]
Message-ID: <20140822080015.GQ4193@intel.com> (raw)
In-Reply-To: <CA+gsUGQ9uJ2tEVSk7GXuHBe1QJxkvM4nuS0JPrvf_baSsgzhjQ@mail.gmail.com>
On Thu, Aug 21, 2014 at 12:01:07PM -0300, Paulo Zanoni wrote:
> 2014-08-21 11:56 GMT-03:00 Ville Syrjälä <ville.syrjala@linux.intel.com>:
> > On Thu, Aug 21, 2014 at 03:06:26PM +0300, Jani Nikula wrote:
> >> Fix assert_panel_unlocked for vlv/chv, and improve it a bit for
> >> non-LVDS. Also don't pretend it works for DDI. There's still work to do
> >> to get this right for eDP on PCH platforms, but this is a start.
> >>
> >> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> >>
> >> ---
> >>
> >> So I wanted to quickly fix assert_panel_unlocked, but for such a short
> >> piece of code it's too involved to _quickly_ get right across all
> >> platforms. I think this is a worthwhile improvement though.
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 27 ++++++++++++++++++++-------
> >> 1 file changed, 20 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >> index fe1d00dc9ef5..d6b48496d7f4 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -1193,17 +1193,33 @@ void assert_fdi_rx_pll(struct drm_i915_private *dev_priv,
> >> static void assert_panel_unlocked(struct drm_i915_private *dev_priv,
> >> enum pipe pipe)
> >> {
> >> - int pp_reg, lvds_reg;
> >> + struct drm_device *dev = dev_priv->dev;
> >> + int pp_reg;
> >> u32 val;
> >> enum pipe panel_pipe = PIPE_A;
> >> bool locked = true;
> >>
> >> - if (HAS_PCH_SPLIT(dev_priv->dev)) {
> >> + if (HAS_DDI(dev)) {
> >> + /* XXX: this neither works nor gets called for DDI */
> >
> > Not sure why the XXX here. Seems to me there's nothing to fix here for
> > DDI. Maybe just make that a WARN_ON(HAS_DDI()) or just remove the check
> > entirely.
>
> As far as I remember, the "abcd" stuff is not even used/needed on DDI.
> But this is just what my memory tells me, it may be wrong. Someone
> needs to double-check.
Bspec just says "spare" for those bits.
>
> >
> >> + return;
> >> + } else if (HAS_PCH_SPLIT(dev)) {
> >> + u32 port_sel;
> >> +
> >> pp_reg = PCH_PP_CONTROL;
> >> - lvds_reg = PCH_LVDS;
> >> + port_sel = I915_READ(PCH_PP_ON_DELAYS) & PANEL_PORT_SELECT_MASK;
> >> +
> >> + if (port_sel == PANEL_PORT_SELECT_LVDS &&
> >> + I915_READ(PCH_LVDS) & LVDS_PIPEB_SELECT)
> >> + panel_pipe = PIPE_B;
> >> + /* XXX: else fix for eDP */
> >> + } else if (IS_VALLEYVIEW(dev)) {
> >> + /* presumably write lock depends on pipe, not port select */
> >
> > Hmm. This is a good question. Needs a bit if testing I suppose. In the
> > worst case it somehow gets tied in with how the power sequencer gets locked
> > to the port. For that we'd probably just have to check both power sequencers
> > here and complain if either has the registers locked. Or maybe we should
> > just do that anyway because it's such a simple solution? But we could
> > do that simply by calling assert_panel_unlocked() twice (once for each pipe)
> > from VLV specific code, so this patch seems to be exactly what we need as
> > a first step.
> >
> > Apart from the XXX in the comment:
> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> >> + pp_reg = VLV_PIPE_PP_CONTROL(pipe);
> >> + panel_pipe = pipe;
> >> } else {
> >> pp_reg = PP_CONTROL;
> >> - lvds_reg = LVDS;
> >> + if (I915_READ(LVDS) & LVDS_PIPEB_SELECT)
> >> + panel_pipe = PIPE_B;
> >> }
> >>
> >> val = I915_READ(pp_reg);
> >> @@ -1211,9 +1227,6 @@ static void assert_panel_unlocked(struct drm_i915_private *dev_priv,
> >> ((val & PANEL_UNLOCK_MASK) == PANEL_UNLOCK_REGS))
> >> locked = false;
> >>
> >> - if (I915_READ(lvds_reg) & LVDS_PIPEB_SELECT)
> >> - panel_pipe = PIPE_B;
> >> -
> >> WARN(panel_pipe == pipe && locked,
> >> "panel assertion failure, pipe %c regs locked\n",
> >> pipe_name(pipe));
> >> --
> >> 1.9.1
> >>
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-08-22 8:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-21 12:06 [PATCH 1/2] drm/i915: fix panel unlock register mask Jani Nikula
2014-08-21 12:06 ` [PATCH 2/2] drm/i915: improve assert_panel_unlocked Jani Nikula
2014-08-21 14:56 ` Ville Syrjälä
2014-08-21 15:01 ` Paulo Zanoni
2014-08-22 8:00 ` Ville Syrjälä [this message]
2014-08-26 14:38 ` Daniel Vetter
2014-08-22 12:04 ` [PATCH v2 " Jani Nikula
2014-08-21 13:36 ` [PATCH 1/2] drm/i915: fix panel unlock register mask Paulo Zanoni
2014-08-21 13:39 ` Ville Syrjälä
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=20140822080015.GQ4193@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=przanoni@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