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@xxxxxxxxx> wrote: > > > On Mon, 2015-06-29 at 14:24 +0300, Jani Nikula wrote: > > >> On Tue, 16 Jun 2015, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > > >> > On Tue, 16 Jun 2015, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > > >> >> On Wed, 03 Jun 2015, Mika Kahola <mika.kahola@xxxxxxxxx> wrote: > > >> >>> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > >> >>> > > >> >>> 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@xxxxxxxxxxxxxxx> > > >> >>> Signed-off-by: Mika Kahola <mika.kahola@xxxxxxxxx> > > >> >> > > >> >> 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@xxxxxxxxxxxxxxx> > > >> > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
