1. 16 Apr, 2013 1 commit
  2. 15 Apr, 2013 2 commits
  3. 11 Apr, 2013 3 commits
  4. 09 Apr, 2013 18 commits
  5. 08 Apr, 2013 1 commit
  6. 01 Apr, 2013 2 commits
  7. 25 Mar, 2013 2 commits
  8. 24 Mar, 2013 3 commits
    • Daniel Vetter's avatar
      Revert "drm/i915: write backlight harder" · b1289371
      Daniel Vetter authored
      This reverts commit cf0a6584.
      
      Turns out that cargo-culting breaks systems. Note that we can't revert
      further, since
      
      commit 770c1231
      Author: Takashi Iwai <tiwai@suse.de>
      Date:   Sat Aug 11 08:56:42 2012 +0200
      
          drm/i915: Fix blank panel at reopening lid
      
      fixed a regression in 3.6-rc kernels for which we've never figured out
      the exact root cause. But some further inspection of the backlight
      code reveals that it's seriously lacking locking. And especially the
      asle backlight update is know to get fired (through some smm magic)
      when writing specific backlight control registers. So the possibility
      of suffering from races is rather real.
      
      Until those races are fixed I don't think it makes sense to try
      further hacks. Which sucks a bit, but sometimes that's how it is :(
      
      References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941Tested-by: default avatarTakashi Iwai <tiwai@suse.de>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: stable@vger.kernel.org (the reverted commit was cc: stable, too)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b1289371
    • Paulo Zanoni's avatar
      drm/i915: don't disable the power well yet · 2124b72e
      Paulo Zanoni authored
      We're still not 100% ready to disable the power well, so don't disable
      it for now. When we disable it we break the audio driver (because some
      of the audio registers are on the power well) and machines with eDP on
      port D (because it doesn't use TRANSCODER_EDP).
      
      Also, instead of just reverting the code, add a Kernel option to let
      us disable it if we want. This will allow us to keep developing and
      testing the feature while it's not enabled.
      
      This fixes problems caused by the following commit:
        commit d6dd9eb1
        Author: Daniel Vetter <daniel.vetter@ffwll.ch>
        Date:   Tue Jan 29 16:35:20 2013 -0200
             drm/i915: dynamic Haswell display power well support
      
      References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Mengdong Lin <mengdong.lin@intel.com>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2124b72e
    • Daniel Vetter's avatar
      Revert "drm/i915: set TRANSCODER_EDP even earlier" · bba2181c
      Daniel Vetter authored
      This reverts commit cc464b2a.
      
      The reason is that Takashi Iwai reported a regression bisected to this
      commit:
      
      http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
      
      His machine has eDP on port D (usual desktop all-in-on setup), which
      intel_dp.c identifies as an eDP panel, but the hsw ddi code
      mishandles.
      
      Closer inspection of the code reveals that haswell_crtc_mode_set also
      checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell
      that doesn't make much sense (since there's no edp on the pch), but
      what this function _really_ checks is whether that edp connector is on
      port A or port D. It's just that on ilk-ivb port D was on the pch ...
      
      So that explains why this seemingly innocent change killed eDP on port
      D. Furthermore it looks like everything else accidentally works, since
      we've never enabled eDP on port D support for hsw intentionally (e.g.
      we still register the HDMI output for port D in that case).
      
      But in retrospective I also don't like that this leaks highly platform
      specific details into common code, and the reason is that the drm
      vblank layer sucks. So instead I think we should:
      - move the cpu_transcoder into the dynamic pipe_config tracking (once
        that's merged).
      - fix up the drm vblank layer to finally deal with kms crtc objects
        instead of int pipes.
      
      v2: Pimp commit message with the better diagnosis as discussed with
      Paulo on irc.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      bba2181c
  9. 23 Mar, 2013 8 commits