[Intel-gfx] [PATCH v6 7/8] drm/i915: BDW clock change support

[Daniel Vetter]

On Mon, Jun 29, 2015 at 02:46:41PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 29, 2015 at 02:42:25PM +0300, Jani Nikula wrote:
> > On Mon, 29 Jun 2015, Mika Kahola <mika.kahola at intel.com> wrote:
> > > On Mon, 2015-06-29 at 14:24 +0300, Jani Nikula wrote:
> > >> On Tue, 16 Jun 2015, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> > >> > On Tue, 16 Jun 2015, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> > >> >> On Wed, 03 Jun 2015, Mika Kahola <mika.kahola at intel.com> wrote:
> > >> >>> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > >> >>>
> > >> >>> Add support for changing cdclk frequency during runtime on BDW. The
> > >> >>> procedure is quite a bit different on BDW from the one on HSW, so
> > >> >>> add a separate function for it.
> > >> >>>
> > >> >>> Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
> > >> >>> so take that into account when computing the max pixel rate.
> > >> >>>
> > >> >>> v2: Grab rps.hw_lock around sandybridge_pcode_write()
> > >> >>> v3: Rebase due to power well vs. .global_resources() reordering
> > >> >>> v4: Rebased to the latest
> > >> >>> v5: Rebased to the latest
> > >> >>> v6: Patch order shuffle so that Broadwell CD clock change is
> > >> >>>     applied before the patch for Haswell CD clock change
> > >> >>> v7: Fix for patch style problems
> > >> >>>
> > >> >>> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > >> >>> Signed-off-by: Mika Kahola <mika.kahola at intel.com>
> > >> >>
> > >> >> This patch hard hangs my BDW NUC at boot when both DP and HDMI are
> > >> >> connected. Either DP or HDMI alone are good, same with hotplugging the
> > >> >> other afterwards. Booting to grub with both connected, and unplugging
> > >> >> HDMI before loading the kernel also reproduces the issue.
> > >> >>
> > >> >> It looks like the problem boils down to the BIOS setting up a smaller
> > >> >> resolution on the DP display when both are connected, and this patch
> > >> >> fails to cope with that on i915 load.
> > >> >
> > >> > By "this patch" I obviously refer to
> > >> >
> > >> > commit b432e5cfd5e92127ad2dd83bfc3083f1dbce43fb
> > >> > Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > >> > Date:   Wed Jun 3 15:45:13 2015 +0300
> > >> >
> > >> >     drm/i915: BDW clock change support
> > >> >
> > >> > and everything works for the commit before that.
> > >> 
> > >> Anyone working on this, or should we revert?
> > >> 
> > >> BR,
> > >> Jani.
> > >> 
> > > My understanding is that Ville has an idea or how to fix this.
> > 
> > Ville, when do you think we can convert the idea into a patch? Should we
> > revert in the mean time?
> 
> I was thinking it may have been atomic making a mess of things and
> enabling planes while the pipe was off. But I may be totally off here
> since the current atomic code doesn't agree with my brain at all.
> 
> So no, I have no patch to fix it. Someone needs to first check where
> exactly the hang happens.

We do have evidence that at least the code in 4.2 does touch planes when
the pipe is off. Linus has backtraces at least.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch