intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: "Kumar, Shobhit" <shobhit.kumar@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os
Date: Tue, 06 Oct 2015 13:41:49 +0300	[thread overview]
Message-ID: <1444128109.8306.10.camel@intel.com> (raw)
In-Reply-To: <56139AD9.4020205@linux.intel.com>

On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
> On 10/05/2015 09:05 PM, Imre Deak wrote:
> > On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
> >> Mostly reuse what is programmed by pre-os, but in case there is no
> >> pre-os initialization, init the cdclk with the default value.
> >>
> >> Cc: Imre Deak <imre.deak@intel.com>
> >> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
> >> ---
> >>   drivers/gpu/drm/i915/intel_ddi.c | 6 ++----
> >>   1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> >> index 2d3cc82..675c60d 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
> >>
> >>   		cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
> >>   		dev_priv->skl_boot_cdclk = cdclk_freq;
> >> -		if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> >> -			DRM_ERROR("LCPLL1 is disabled\n");
> >> -		else
> >> -			intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
> >> +
> >> +		skl_init_cdclk(dev_priv);
> >
> > How does this prevent changing the clock if BIOS did enable some output?
> > We shouldn't change the clock in that case.
> 
> In that case it will try to re-apply the same clock that BIOS enabled. 
> Not sure if this is allowed, but I checked the cdclock change sequence 
> and it is mostly followed in skl_init_cdclk.
> In my tests where BIOS does enable this, I faced no issues in
> initializing again in driver.

The first step in that sequence:
"Disable all display engine functions using the full mode set disable
sequence on all pipes, ports, and planes."

So the problem is not that the PLL itself may be enabled here (as BIOS
left it), but that some output is also enabled.

> I have noticed on some pre-os this value is programmed correctly except
> for the decimal part. That causes AUX transactions to fail on SKl. That
> is what triggered this patch actually. So other way is to completely
> validate the value in get_display_clock_speed instead of bit[28:26] and
> then if wrong then only do the cdclk init.

I think we'd need to detect at this point if outputs are enabled and
only attempt to work around the above BIOS problem if this is not the
case. Alternatively you could also disable the active outputs as a first
step.

> 
> Regards
> Shobhit
> 
> >
> >>   	} else if (IS_BROXTON(dev)) {
> >>   		broxton_init_cdclk(dev);
> >>   		broxton_ddi_phy_init(dev);
> >
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-10-06 10:41 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-05 15:22 [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os Shobhit Kumar
2015-10-05 15:35 ` Imre Deak
2015-10-06  6:35   ` Jani Nikula
2015-10-06  9:57     ` Kumar, Shobhit
2015-10-06  9:56   ` Kumar, Shobhit
2015-10-06 10:41     ` Imre Deak [this message]
2015-10-06 11:03       ` Kumar, Shobhit
2015-10-06 11:19         ` Daniel Vetter
2015-10-06 11:41           ` Ville Syrjälä
2015-10-06 12:19             ` Daniel Vetter
2015-10-06 12:43               ` Kumar, Shobhit
2015-10-06 13:04                 ` Daniel Vetter
2015-10-06 13:29                   ` Ville Syrjälä
2015-10-06 13:25                 ` Ville Syrjälä
2015-10-07  6:31                   ` Kumar, Shobhit
2015-10-08  4:28 ` [v2] " Shobhit Kumar
2015-10-08 11:29   ` Imre Deak
2015-10-08 12:13     ` Kumar, Shobhit
2015-10-08 12:24       ` Ville Syrjälä
2015-10-09 10:53         ` Kumar, Shobhit
2015-10-16 13:08         ` Kumar, Shobhit
2015-10-16 13:18   ` [v3] drm/i915/skl: If needed sanitize bios programmed cdclk Shobhit Kumar
2015-10-19  7:43     ` Kumar, Shobhit
2015-10-19 13:48     ` Ville Syrjälä
2015-10-20  9:57       ` Kumar, Shobhit
2015-10-20 11:19         ` Ville Syrjälä
2015-10-20 12:27           ` Kumar, Shobhit
2015-10-20 12:43     ` [v4] " Shobhit Kumar
2015-10-20 12:52       ` Ville Syrjälä
2015-10-21  6:25         ` Daniel Vetter

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=1444128109.8306.10.camel@intel.com \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=shobhit.kumar@linux.intel.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;
as well as URLs for NNTP newsgroup(s).