Re: [git pull] drm tree for 4.2

[Jani Nikula]

On Mon, 29 Jun 2015, Ander Conselvan De Oliveira <conselvan2@xxxxxxxxx> wrote:
> On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
>> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie <airlied@xxxxxxxx> wrote:
>> >
>> > This is the main drm pull request for v4.2.
>> 
>> It seems to work ok for me, but it causes quite a few new warnings on
>> my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka
>> Haswell, aka 4th gen Intel Core i5)
>> 
>> Most of them are in check_crtc_state(), and I currently have 18 of
>> these in my log:
>> 
>>   [drm:check_crtc_state [i915]] *ERROR* mismatch in
>> dpll_hw_state.wrpll (expected 0x90280202, found 0x00000000)
>>   WARNING: CPU: 0 PID: 115 at
>> drivers/gpu/drm/i915/intel_display.c:12319
>> check_crtc_state+0x8be/0xf60 [i915]()
>>   pipe state doesn't match!
>> 
>> but there's a few others too:
>> 
>>   WARNING: CPU: 3 PID: 1871 at
>> drivers/gpu/drm/i915/intel_display.c:1362 hsw_disable_ips+0x34/0x160
>> [i915]()
>>   plane A assertion failure (expected on, current off)
>> 
>>   WARNING: CPU: 3 PID: 1871 at drivers/gpu/drm/drm_irq.c:1162
>> drm_wait_one_vblank+0x148/0x1a0 [drm]()
>>   vblank not available on crtc 0, ret=-22
>> 
>> and the backtraces aren't all that interesting, but I'm attaching the
>> cleaned-up dmesg, duplicate callchains and all.
>
> Please provide a full dmesg with drm.debug=0x1f in the kernel command
> line.

Ander, I think I was able to reproduce this on the BDW NUC here. Bisect
points at...

commit dd3cd74acf12723045a64f1f2c6298ac7b34a5d5
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx>
Date:   Fri May 15 13:34:29 2015 +0300

    drm/i915: Don't overwrite (e)DP PLL selection on SKL
    
    In the following commit, the place where the contents of dpll_hw_state
    in crtc_state where zeroed was changed. Prior to that commit, it
    happened when the new state was allocated, but now that happens just
    before the call the .crtc_compute_clock() hook. The DP code for SKL,
    however, sets up the (private) PLL in the encoder compute config
    function that has already run by the time that memset() is reached,
    causing the previous value to be lost.
    
    This patch fixes the issue by moving the memset() down the call chain,
    so that it is only called if the values in dpll_hw_state are going to be
    updated.
    
    commit 4978cc93d9ac240b435ce60431aef24239b4c270
    Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx>
    Date:   Tue Apr 21 17:13:21 2015 +0300
    
        drm/i915: Preserve shared DPLL information in new pipe_config
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90462
    Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx>
    Reviewed-by: Damien Lespiau <damien.lespiau@xxxxxxxxx>
    Reported-and-tested-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx>
    Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>

This doesn't revert cleanly on Linus' master, and I didn't have the time
to look deeper right now. However I confirmed that this commit fails and
its parent doesn't.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/