• Matt Roper's avatar
    drm/i915: Sanitize watermarks after hardware state readout (v4) · d93c0372
    Matt Roper authored
    Although we can do a good job of reading out hardware state, the
    graphics firmware may have programmed the watermarks in a creative way
    that doesn't match how i915 would have chosen to program them.  We
    shouldn't trust the firmware's watermark programming, but should rather
    re-calculate how we think WM's should be programmed and then shove those
    values into the hardware.
    
    We can do this pretty easily by creating a dummy top-level state,
    running it through the check process to calculate all the values, and
    then just programming the watermarks for each CRTC.
    
    v2:  Move watermark sanitization after our BIOS fb reconstruction; the
         watermark calculations that we do here need to look at pstate->fb,
         which isn't setup yet in intel_modeset_setup_hw_state(), even
         though we have an enabled & visible plane.
    
    v3:
     - Don't move 'active = optimal' watermark assignment; we just undo
       that change in the next patch anyway.  (Ville)
     - Move atomic helper locking fix to separate patch.  (Maarten)
    
    v4:
     - Grab connection_mutex before calling atomic helper to duplicate
       state.  The connector loop inside the helper will throw a WARN
       if we don't hold something to protect the connector list (and the
       helper itself doesn't try to lock the list).
     - Make failure to calculate watermarks for inherited state a WARN()
       since it probably indicates a serious problem in either our state
       readout code or our watermark code for this platform.
    
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
    Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
    d93c0372
i915_drv.h 108 KB