1. 02 Apr, 2013 6 commits
  2. 28 Mar, 2013 10 commits
    • Daniel Vetter's avatar
      drm/i915: fixup fb bpp computation in pipe_config_set_bpp · d42264b1
      Daniel Vetter authored
      Ville pointed out that my assumption that no unsupported pixel format
      can get past the pipe config computation stage to the platform
      update_plane callbacks is wrong. The reason is that this function
      still checks the old fb->depth value instead of the new pixel_format.
      
      While checking with all the other places that use this I've noticed
      that intel_framebuffer_init already has all the platform checks we
      need, so replace those checks with a WARN_ON.
      
      Since fb->depth isn't set for YUV pixel formats and since we already
      can't create an fb with an rgb layout not support on the running
      platform I /think/ this patch doesn't fix any bug.
      
      But it surely looks better!
      
      v2: BGR formats are also only gen4+, so add the corresponding WARN_ON,
      too (Ville).
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d42264b1
    • Daniel Vetter's avatar
      drm/i915: check fb->pixel_format instead of bits_per_pixel · 72f4901e
      Daniel Vetter authored
      We've mostly switched over to the new more flexible schema, but
      there's one check left in the modeset code.
      
      Motivated by a question from Ville whether there's really no way an
      unsupported pixel_format can escape into our platform update_plane
      callbacks.
      
      v2: Ville noticed that the fb->depth check is redudant when we already
      check fb->pixel_format.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      72f4901e
    • Daniel Vetter's avatar
      drm/i915: fix up _wait_for macro · 1d5bfac9
      Daniel Vetter authored
      As Thomas Gleixner spotted, it's rather horrible racy:
      - We can miss almost a full tick, so need to compensate by 1 jiffy.
      - We need to re-check the condition when having timed-out, since a
        the last check could have been before the timeout expired. E.g. when
        we've been preempted or a long irq happened.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Reported-by: default avatarJack Winter <jbh@alchemy.lu>
      Cc: Jack Winter <jbh@alchemy.lu>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1d5bfac9
    • Daniel Vetter's avatar
      drm/i915: fold wait_for_atomic_us into wait_for_atomic · 6effa33b
      Daniel Vetter authored
      Since
      
      commit bcf9dcc1
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Sun Jul 15 09:42:38 2012 +0100
      
          drm/i915: Workaround hang with BSD and forcewake on SandyBridge
      
      and
      
      commit 0cc2764c
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Sat Sep 1 22:59:48 2012 -0700
      
          drm/i915: use cpu_relax() in wait_for_atomic
      
      these two macros are essentially the same, so unify them. We keep the
      _us version since it's a nice documentation for smaller timeouts.
      
      v2: Fixup time unit conversion, _wait_for takes ms (Ville).
      
      Cc: Jack Winter <jbh@alchemy.lu>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6effa33b
    • Paulo Zanoni's avatar
      drm/i915: remove "inline" keyword from ironlake_disable_display_irq · 0ff9800a
      Paulo Zanoni authored
       - It's a static function
       - I just added a few more users to it
       - Its sister ironlake_enable_display_irq is not marked as inline
       - The compiler will still inline if it thinks it should do
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0ff9800a
    • Daniel Vetter's avatar
      drm/i915: clean up pipe bpp confusion · 5d2d38dd
      Daniel Vetter authored
      - gen4 and earlier (save for g4x) only really have a 8bpc pipe, with
        the possibility to dither to 6bpc using the panel fitter
      - g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly.
      - TV/SDVO out are the only connectors available on platforms with
        a pipe bpp != 8, add code to force the pipe to 8bpc unconditionally.
      
      <rant>
      The dither handling on gmch platforms is one giant disaster. I'm hoping
      somewhat that vlv enabling will fix this up, but given that the 6bpc
      handling for edp was simply added with another quick hack, I don't have
      high hopes ...
      </rant>
      
      v2: Neither vlv nor g4x have 12bpc pipes. Still set pipe_bpp to 12*3,
      but let the crtc code clamp things down to 10bpc on these platforms.
      
      v3: Fix a bpc vs. bpp mixup in the gen4 and earlier pipe_bpp limiter
      code.
      
      v4: Drop the hunk in intel_hdmi.c about g4x/vlv 12bpc, it was wrong.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5d2d38dd
    • Daniel Vetter's avatar
      drm/i915: clean up plane bpp confusion · baba133a
      Daniel Vetter authored
      - There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc
        float layout, but we don't really support it.
      - 10bpc is a gen4+ feature, fix up the support for it.
      - Update_plane should never see a wrong fb bpp value, BUG in the
        corresponding cases.
      
      v2: Rebase on top of Ville's plane pixel layout changes.
      
      v3: Actually drop the old gen4 check for 10bpc planes, spotted
      by Ville Syrjälä.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      baba133a
    • Daniel Vetter's avatar
      drm/i915: convert DP autodither code to new infrastructure · 36008365
      Daniel Vetter authored
      The old code only handled either 6bpc or 8bpc. Since it's easy to do,
      reorganize the code to be a bit more generic so that it can also handle
      10bpc and 12bpc. Note that we still start with 8bpc, so there's no
      functional change.
      
      Also, since we no don't need to compute the 6BPC flag in the mode_valid
      callback, we can consolidate things a bit. That requires though that
      the link bw computation is moved up in the compute_config callback.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      36008365
    • Daniel Vetter's avatar
      drm/i915: precompute pipe bpp before touching the hw · 4e53c2e0
      Daniel Vetter authored
      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: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4e53c2e0
    • Daniel Vetter's avatar
      drm/i915: introduce pipe_config->dither|pipe_bpp · 965e0c48
      Daniel Vetter authored
      We want to compute this earlier. To avoid a big complicated patch,
      this patch here just does the big search&replace and still calls the
      old functions at the same places.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      965e0c48
  3. 27 Mar, 2013 18 commits
  4. 26 Mar, 2013 6 commits