Bug 69713

Summary: [845g regression] machine lockup during KMS takeover
Product: DRI Reporter: Chris Wilson <chris>
Component: DRM/IntelAssignee: Ville Syrjala <ville.syrjala>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: blocker    
Priority: high CC: intel-gfx-bugs
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
One possible idea none

Description Chris Wilson 2013-09-23 13:36:22 UTC
Bisected to

commit 18442d08786472c63a0a80c27f92b033dffc26de
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Sep 13 16:00:08 2013 +0300

    drm/i915: Fix port_clock and adjusted_mode.clock readout all over
    
    Now that adjusted_mode.clock no longer contains the pixel_multiplier, we
    can kill the get_clock() callback and instead do the clock readout
    in get_pipe_config().
    
    Also i9xx_crtc_clock_get() can now extract the frequency of the PCH
    DPLL, so use it to populate port_clock accurately for PCH encoders.
    For DP in port A the encoder is still responsible for filling in
    port_clock. The FDI adjusted_mode.clock extraction is kept in place
    for some extra sanity checking, but we no longer need to pretend it's
    also the port_clock.
    
    In the encoder get_config() functions fill out adjusted_mode.clock
    based on port_clock and other details such as the DP M/N values,
    HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then
    do an extra sanity check to make sure the dotclock we derived from
    the FDI configuratiuon matches the one we derive from port_clock.
    
    DVO doesn't exist on PCH platforms, so it doesn't need to anything
    but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so
    none of the changes apply there.
    
    v2: Use hdmi_reg color format to detect 12bpc HDMI case
    v3: Set adjusted_mode.clock for LVDS too
    v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get,
        eliminate the useless link_freq variable.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 1 Ville Syrjala 2013-09-23 14:02:40 UTC
Created attachment 86374 [details] [review]
One possible idea

The bisect result is a bit odd since the patch in question doesn't change the places where we touch the hardware.

The only real new bug I can immediately spot is the mode->clock in intel_crtc_mode_get(). Not sure if that's even relevant to this machine, but here's a patch to try anyway.
Comment 2 Chris Wilson 2013-09-23 14:33:17 UTC
That allow the machines to boot, I don't have a display yet, but that regression is already well known.
Comment 3 Chris Wilson 2013-09-23 14:36:56 UTC
Sigh. Looks like I compiled out fbcon a while back... So far it looks like it is working. Time to check suspend again.
Comment 4 Daniel Vetter 2013-09-24 11:06:16 UTC
Fix merged:

commit 1b44b14fc9504de74ab9ac5359a087d1377bb87e
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Sep 23 17:48:20 2013 +0300

    drm/i915: Fix intel_crtc_mode_get() mode clock

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.