[Bug 86201] [VLV Bisected] Delayed boot and distorted text console after commit 773538e8

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=86201

--- Comment #5 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to Egbert Eich from comment #4)
> (In reply to Ville Syrjala from comment #3)
> > You have this?
> > 
> > commit 1e74a324465e5a4f8e3ee7c423aef92c54de8a72
> > Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > Date:   Tue Oct 28 16:15:51 2014 +0200
> > 
> >     drm/i915: Initialize PPS timestamps on vlv/chv
> 
> Yup. 
> 
> HEAD of my build is at 
> 
> commit ea361c1700ccb5acdc0f5970fd4d64c94c6aa6ee
> Author: Daniel Vetter <daniel.vetter at ffwll.ch>
> Date:   Wed Nov 12 10:28:50 2014 +0100
> 
>     drm-intel-nightly: 2014y-11m-12d-09h-28m-33s UTC integration manifest

The log is from an older kernel since it doesn't have the port information in
the vdd debug messages. But I guess you're sayng it still happens with the more
recent kernels too.

Apart from the massive delay there's one other WTF in the logs:
[    3.840671] [drm:intel_dp_init_panel_power_sequencer_registers] panel power
sequencer register settings: PP_ON 0x87d00001, PP_OFF 0x1f40001, PP_DIV
0x270f06
[    5.068936] [drm:intel_dp_init_panel_power_sequencer_registers] panel power
sequencer register settings: PP_ON 0x80000001, PP_OFF 0x1, PP_DIV 0x270f00

I'm left wondering what happened to the delays we had in those registers.
Somehow they got zeroed after we already computed them to !=0 values. Althoguh
that issue was already present in the "good" log.

Also can you make edp_panel_vdd_on() dump a backtrace so we can see where it's
coming from. I guess it's some AUX stuff (EDID read perhaps). I can't see why
it would suddenly take forever. Especially since it doesn't appear to time out
or anything.

I don't see any "disabling display" power well debug messages in the log, so at
least resetting pps_pipe doesn't seem to happen anywhere. The other part of the
patch adds the power_domain get/put around the pps_mutex, but since we have
init power enabled here, these should be mostly nops. It does mean we grab and
release the power domain mutex a few extra times as well, so there's some
overhead, but I would think there would have to some serious contention on the
lock to get this kind of effect.

Sadly I can't reproduce this here.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20141118/1fa9fc49/attachment.html>