• Daniel Vetter's avatar
    drm/i915: implement fdi auto-dithering · e29c22c0
    Daniel Vetter authored
    So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
    VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
    into this, among them the default 1080p mode.
    
    The solution is to dither down the pipe a bit so that everything fits,
    which this patch implements.
    
    But ports compute their state under the assumption that the bpp they
    pick will be the one selected, e.g. the display port bw computations
    won't work otherwise. Now we could adjust our code to again up-dither
    to the computed DP link parameters, but that's pointless.
    
    So instead when the pipe needs to adjust parameters we need to retry
    the pipe_config computation at the encoder stage. Furthermore we need
    to inform encoders that they should not increase bandwidth
    requirements if possible. This is required for the hdmi code, which
    prefers the pipe to up-dither to either of the two possible hdmi bpc
    values.
    
    LVDS has a similar requirement, although that's probably only
    theoretical in nature: It's unlikely that we'll ever see an 8bpc
    high-res lvds panel (which is required to hit the 2 fdi lane limit).
    
    eDP is the only thing which could increase the pipe_bpp setting again,
    even when in the retry-loop. This could hit the WARN. Two reasons for
    not bothering:
    - On many eDP panels we'll get a black screen if the bpp settings
      don't match vbt. So failing the modeset is the right thing to do.
      But since that also means it's the only way to light up the panel,
      it should work. So we shouldn't be able to hit this WARN.
    - There are still opens around the eDP panel handling, and maybe we
      need additional tricks. Before that happens it's imo no use trying
      to be too clever.
    Worst case we just need to kill that WARN or maybe fail the compute
    config stage if the eDP connector can't get the bpp setting it wants.
    And since this can only happen with an fdi link in between and so for
    pch eDP panels it's rather unlikely to blow up, if ever.
    
    v2: Rebased on top of a bikeshed from Paulo.
    
    v3: Improve commit message around eDP handling with the stuff
    things with Imre.
    Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    e29c22c0
intel_drv.h 26.8 KB