• D
    drm/i915: precompute pipe bpp before touching the hw · 4e53c2e0
    Daniel Vetter 提交于
    The procedure has now 3 steps:
    
    1. Compute the bpp that the plane will output, this is done in
       pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
       this function clamps the pipe_bpp to whatever limit the EDID of any
       connected output specifies.
    2. Adjust the pipe_bpp in the encoder and crtc functions, according to
       whatever constraints there are.
    3. Decide whether to use dither by comparing the stored plane bpp with
       computed pipe_bpp.
    
    There are a few slight functional changes in this patch:
    - LVDS connector are now also going through the EDID clamping. But in
      a 2nd change we now unconditionally force the lvds bpc value - this
      shouldn't matter in reality when the panel setup is consistent, but
      better safe than sorry.
    - HDMI now forces the pipe_bpp to the selected value - I think that's
      what we actually want, since otherwise at least the pixelclock
      computations are wrong (I'm not sure whether the port would accept
      e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
      the next higher bpc value, since otherwise there's no way to make
      use of the 12 bpc mode (since the next patch will remove the 12bpc
      plane format, it doesn't exist).
    
    Both of these changes are due to the removal of the
    
    	pipe_bpp = min(display_bpp, plane_bpp);
    
    statement.
    
    Another slight change is the reworking of the dp bpc code:
    - For the mode_valid callback it's sufficient to only check whether
      the mode would fit at the lowest bpc.
    - The bandwidth computation code is a bit restructured: It now walks
      all available bpp values in an outer loop and the codeblock that
      computes derived values (once a good configuration is found) has been
      moved out of the for loop maze. This is prep work to allow us to
      successively fall back on bpc values, and also correctly support bpc
      values != 8 or 6.
    
    v2: Rebased on top of Paulo Zanoni's little refactoring to use more
    drm dp helper functions.
    
    v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
    range work.
    
    v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.
    
    v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
    hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
    in a later patch though again.
    
    v6: Fix spelling in a comment.
    
    v7: Debug output improvements for the bpp computation.
    
    v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
    things!
    
    v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
    was lost in a rebase.
    
    v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
    that. Still unsure whether this is the way to go, but at least 6bpc
    for a 8bpc hdmi output seems to work.
    
    v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
    depth on DP. Adjust the code.
    
    v12: Rebased.
    
    v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
    requested from Jesse Barnes.
    
    v14: Split out the special 6BPC handling for DP, as requested by Jesse
    Barnes.
    Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    4e53c2e0
intel_display.c 251.6 KB