From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Simplify i830 DVO 2x clock handling
Date: Mon, 4 Mar 2019 18:16:32 +0200 [thread overview]
Message-ID: <20190304161632.GX20097@intel.com> (raw)
In-Reply-To: <155171474959.18705.17582274098311462977@skylake-alporthouse-com>
On Mon, Mar 04, 2019 at 03:52:30PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-03-04 13:41:13)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Let's just always enable the DVO 2x clock on i830. This way we don't
> > have to track if DVO is being used or not. The spec does suggest we
> > should disable the clock when it isn't needed, but this does appear
> > to work just fine.
>
> And after i830, 2X_MODE seems to be the default? Whereas the only reason
> for i830 being special is that both pipes must be using the same mode,
> ergo we didn't do either (or something like that).
Post i830 the hw was fixed so we only have to enable the 2x clock
when the pipe is driving a DVO port. Driving the CRT and LVDS ports
does not require the 2x clock.
>
> > This removes another crtc->config usage.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > @@ -1468,26 +1455,12 @@ static void i9xx_enable_pll(struct intel_crtc *crtc,
> > /*
> > * Apparently we need to have VGA mode enabled prior to changing
> > * the P1/P2 dividers. Otherwise the DPLL will keep using the old
> > * dividers, even though the register value does change.
> > */
> > - I915_WRITE(reg, 0);
> > -
> > + I915_WRITE(reg, dpll & ~DPLL_VGA_MODE_DIS);
>
> This looks to be a separate tweak?
I didn't want to termporarily disable the DPLL, even for a miniscule
amount of time. Since the old code did work I suppose it's not
really needed, but this seems more consistent with the whole premise
of keeping both DPLLs on all the time.
I suppose I could extract this to a separate patch for clarity.
>
> > I915_WRITE(reg, dpll);
> >
> > /* Wait for the clocks to stabilize. */
>
> > @@ -7494,7 +7457,19 @@ static void i8xx_compute_dpll(struct intel_crtc *crtc,
> > dpll |= PLL_P2_DIVIDE_BY_4;
> > }
> >
> > - if (!IS_I830(dev_priv) &&
> > + /*
> > + * Bspec:
> > + * "[Almador Errata}: For the correct operation of the muxed DVO pins
> > + * (GDEVSELB/ I 2 Cdata, GIRDBY/I 2 CClk) and (GFRAMEB/DVI_Data,
> > + * GTRDYB/DVI_Clk): Bit 31 (DPLL VCO Enable) and Bit 30 (2X Clock
> > + * Enable) must be set to “1” in both the DPLL A Control Register
> > + * (06014h-06017h) and DPLL B Control Register (06018h-0601Bh)."
> > + *
> > + * For simplicity We simply keep both bits always enabled in
> > + * both DPLLS. The spec says we should disable the DVO 2X clock
> > + * when not needed, but this seems to work fine in practice.
> > + */
> > + if (IS_I830(dev_priv) ||
> > intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DVO))
> > dpll |= DPLL_DVO_2X_MODE;
>
> Is VGA/CRT a native encoder? That might be a useful test to check that
> still works.
Yes, and yes it still works.
>
> I couldn't see anything you missed for DPLL_DVO_2X_MODE, so happy that
> this does what it says on the tin, and I trust that you actually ran
> this on an i830...
Indeed I did. And I also tested the 's/0/dpll & ~DPLL_VGA_MODE_DIS/'
change on my ctg as those are known to suffer from the p1/p2 dividers
not latching issue. The new sequence still forces p1/p2 to latch.
>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Thanks.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-03-04 16:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-04 13:41 [PATCH] drm/i915: Simplify i830 DVO 2x clock handling Ville Syrjala
2019-03-04 14:26 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-03-04 15:52 ` [PATCH] " Chris Wilson
2019-03-04 16:16 ` Ville Syrjälä [this message]
2019-03-04 18:27 ` ✓ Fi.CI.IGT: success for " Patchwork
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=20190304161632.GX20097@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--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