1. 04 Oct, 2012 6 commits
  2. 03 Oct, 2012 1 commit
  3. 02 Oct, 2012 7 commits
  4. 27 Sep, 2012 2 commits
  5. 26 Sep, 2012 3 commits
  6. 24 Sep, 2012 1 commit
  7. 20 Sep, 2012 20 commits
    • Ben Widawsky's avatar
      drm/i915: Fix !CONFIG_PM sysfs for real this time · 853c70e8
      Ben Widawsky authored
      
      
      Somehow this hunk got dropped from my last patch. We do not have the
      rc6_attrs when there is no CONFIG_PM so this causes a compilation error.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      853c70e8
    • Chris Wilson's avatar
      drm/i915: Assert that the exec object lookup table is a power-of-two · 41783eea
      Chris Wilson authored
      
      
      As we make the simplification of using a power-of-two size for the
      execbuffer handle-to-object TLB, we should validate that this is actually
      true and so clarify that premise.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      41783eea
    • Wang Xingchao's avatar
      drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally · 3cce574f
      Wang Xingchao authored
      
      
      Clear Audio Enable bit to trigger unsolicated event to notify Audio
      Driver part the HDMI hot plug change. The patch fixed the bug when
      remove HDMI cable the bit was not cleared correctly.
      
      In intel_enable_hdmi(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
      be set to trigger unsolicated event to notify Alsa driver the change.
      
      intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
      remove the hdmi cable, here's debug log:
      
      [  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
      [  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0
      
      so when comes back to intel_disable_hdmi(), the "Audio enable bit" will not be cleared. And this
      cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.
      
      This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:
      
      [  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
      [  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
      Signed-off-by: default avatarWang Xingchao <xingchao.wang@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3cce574f
    • Chris Wilson's avatar
      drm/i915: Convert the dmabuf object to use the new i915_gem_object_ops · 2f745ad3
      Chris Wilson authored
      
      
      By providing a callback for when we need to bind the pages, and then
      release them again later, we can shorten the amount of time we hold the
      foreign pages mapped and pinned, and importantly the dmabuf objects then
      behave as any other normal object with respect to the shrinker and
      memory management.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2f745ad3
    • Daniel Vetter's avatar
      drm/i915: update dpms property in set_mode · 68d34720
      Daniel Vetter authored
      
      
      Hopefully this makes userspace slightly less confused about us
      frobbing the dpms state behind its back. Yeah, it would be better
      to be more careful with not changing the dpms state, but that is
      quite more invasive.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      68d34720
    • Daniel Vetter's avatar
      drm/i915: don't call dpms funcs after set_mode · 172a1ae1
      Daniel Vetter authored
      
      
      ... because our current set_mode implementation doesn't bother to adjust
      for the dpms state, we just forcefully update it. So stop pretending that
      we're better than we are and rip out this extranous call.
      
      Note that this totally confuses userspace, because the exposed connector
      property isn't actually updated ...
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      172a1ae1
    • Daniel Vetter's avatar
      drm/i915: don't disable fdi links harder in ilk_crtc_enable · 46b6f814
      Daniel Vetter authored
      
      
      Because they should have been disabled when shutting down the display
      pipe previously. To ensure that this is the case, add a few assserts
      instead of unconditionally disabling the fdi link.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      46b6f814
    • Daniel Vetter's avatar
      drm/i915: rip out intel_disable_pch_ports · a14d3359
      Daniel Vetter authored
      Even with the old crtc helper code we should have disabled all
      encoders on that pipe by now, and with the new code this would
      definitely paper over a bug. We already have the necessary checks
      in place in intel_disable_transcoder, so if we accidentally leave
      a pch port on, this will be caught.
      
      Hence just rip this all out.
      
      Note that up to the patch in this giant modeset series that removes
      the LVDS special case to avoid disabling LVDS in the encoder->prepare
      callback ("drm/i915/lvds: ditch ->prepare special case"), this was not
      the case for all outputs.
      
      Also note that in
      
      commit 1b3c7a47
      
      
      Author: Zhenyu Wang <zhenyuw@linux.intel.com>
      Date:   Wed Nov 25 13:09:38 2009 +0800
      
          drm/i915: Fix LVDS stability issue on Ironlake
      
      this was already discovered independently and worked around. How I
      bloody hate this entire mess of cludges piled on top of other cludges.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a14d3359
    • Chris Wilson's avatar
      drm/i915: Limit the ioremap of the PCI bar to the registers · 934d6086
      Chris Wilson authored
      
      
      In the future we may like to experiment with using a WC map of the GTT
      portion. However, that will conflict with i915.ko mapping the entire bar
      as UC in order to access the GPU registers. Instead we can shrink the
      register ioremap to only map the register block.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by (IVB): Ben Widawsky <ben@bwidawsk.net>
      Acked-by: default avatarBen Widawsky <ben@bwidawsk.net>
      [danvet: Squashed-in follow-up fix for gen2/3 registers file size from
      Chris Wilson.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      934d6086
    • Ben Widawsky's avatar
      drm/i915: Show render P state thresholds in sysfs · ac6ae347
      Ben Widawsky authored
      
      
      This is useful for userspace utilities which wish to use the previous
      interface, specifically for micromanaging the increase/decrease steps by
      setting min == max.
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ac6ae347
    • Ben Widawsky's avatar
      drm/i915: Add setters for min/max frequency · 46ddf194
      Ben Widawsky authored
      
      
      Provide a standardized sysfs interface for setting min, and max
      frequencies.  The code which reads the limits were lifted from the
      debugfs files. As a brief explanation, the limits are similar to the CPU
      p-states. We have 3 states:
      
      RP0 - ie. max frequency
      RP1 - ie. "preferred min" frequency
      RPn - seriously lowest frequency
      
      Initially Daniel asked me to clamp the writes to supported values, but
      in conforming to the way the cpufreq drivers seem to work, instead
      return -EINVAL (noticed by Jesse in discussion).
      The values can be used by userspace wishing to control the limits of the
      GPU (see the CC list for people who care).
      
      v4: Make exceeding the soft limits return -EINVAL as well (Daniel)
      
      v3: bug fix (Ben) -  was passing the MHz value to gen6_set_rps instead of
      the step value. To fix, deal only with step values by doing the divide
      at the top.
      
      v2: add the dropped mutex_unlock in error cases (Chris)
      EINVAL on both too min, or too max (Daniel)
      
      v2 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      46ddf194
    • Daniel Vetter's avatar
      drm/i915: rip out edp special case from dp_link_down · b6f69c9a
      Daniel Vetter authored
      This has been tons of fun to figure out with git blame. The first
      notion of this code block goes back to the original cpu edp enabling
      for ilk in
      
      commit 32f9d658
      Author: Zhenyu Wang <zhenyuw@linux.intel.com>
      Date:   Fri Jul 24 01:00:32 2009 +0800
      
          drm/i915: Add eDP support on IGDNG mobile chip
      
      Two things are notable in this commit wrt to the this edp special
      case:
      - The IS_eDP check _only_ fires for DP A, i.e. cpu edp ports.
      - The cpu edp port is disabled at the top of the dp_link_down function.
      
      My theory is that these hacks was added to work around the completely
      different modeset sequence for cpu edp ports compared to pch edp
      ports. With the cpu edp confusion on ilk (and snb/ivb) now fixed up,
      this shouldn't be required any more.
      
      The really interesting question is how this special cases survived
      this long in the code. The first step is declaring the pch port D as
      eDP if it's used for an internal panel:
      
      commit b329530c
      Author: Adam Jackson <ajax@redhat.com>
      Date:   Fri Jul 16 14:46:28 2010 -0400
      
          drm/i915/dp: Correctly report eDP in the core connector type
      
      This commit unfortunately failed to notice that not all edp ports are
      created equal. Then follow a flurry of refactorings, culminating in a
      patch from Keith Packard which resulted in the current logic (by
      making it "correct" for all platforms that have edp):
      
      commit 417e822d
      
      
      Author: Keith Packard <keithp@keithp.com>
      Date:   Tue Nov 1 19:54:11 2011 -0700
      
          drm/i915: Treat PCH eDP like DP in most places
      
      None of these cleanups or refactorings supply any reason why we need
      this code, they've simply carried it on as-is.
      
      Hence presume it might be harmful with the current code and rip it
      out. We do rewrite the link training bits completely anyway when
      re-training the link.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b6f69c9a
    • Chris Wilson's avatar
      drm/i915: Drop the misleading cast to the wrong user pointer type · ba7a6458
      Chris Wilson authored
      
      
      The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
      a drm_i915_gem_relocation_entry is very confusing!
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ba7a6458
    • Lekensteyn's avatar
      i915: initialize CADL in opregion · d627b62f
      Lekensteyn authored
      This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not
      used anywhere in the driver code at the moment, but it could be used in BIOS as
      is the case with the Clevo laptop.
      
      The Clevo B7130 requires the CADL field to contain at least the ID of
      the LCD device. If this field is empty, the ACPI methods that are called
      on pressing brightness / display switching hotkeys will not trigger a
      notification. As a result, it appears as no hotkey has been pressed.
      
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452
      
      Tested-by: default avatarPeter Wu <lekensteyn@gmail.com>
      Signed-off-by: default avatarPeter Wu <lekensteyn@gmail.com>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d627b62f
    • Daniel Vetter's avatar
      drm/i915: disable the cpu edp port after the cpu pipe · 3739850b
      Daniel Vetter authored
      
      
      See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This
      applies to all platforms where we currently support eDP on, i.e. ilk,
      snb & ivb.
      
      Without this change we fail to light up the eDP port on previously
      unused crtcs (likely because something is stuck on the old pipe), and
      we also fail to properly disable the old pipe (i.e. bit 30 in the
      PIPECONF register is stuck as set until the next reboot).
      
      v2: Rebased on top of the edp panel off sequence changes in 3.6-rc2.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44001
      
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3739850b
    • Daniel Vetter's avatar
      drm/i915: rip out dp port enabling cludges^Wchecks · 0c33d8d7
      Daniel Vetter authored
      
      
      These have been added because dp links are fiddle things and don't
      like it when we try to re-train an enabled output (or disable a
      disabled output harder). And because the crtc helper code is
      ridiculously bad add tracking the modeset state.
      
      But with the new code in place it is simply a bug to disable a disabled
      encoder or to enable an enabled encoder again. Hence convert these to
      WARNs (and bail out for safety), but flatten all conditionals in the
      code itself.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0c33d8d7
    • Daniel Vetter's avatar
      drm/i915: robustify edp_pll_on/off · 0767935e
      Daniel Vetter authored
      
      
      With the previous patch to clean up where exactly these two functions
      are getting called, this patch can tackle the enable/disable code
      itself:
      
      - WARN if the port enable bit is in the wrong state or if the edp pll
        bit is in the wrong state, just for paranoia's sake.
      - Don't disable the edp pll harder in the modeset functions just for
        fun.
      - Don't set the edp pll enable flag in intel_dp->DP in modeset, do
        that while changing the actual hw state. We do the same with the
        actual port enable bit, so this is a bit more consistent.
      - Track the current DP register value when setting things up and add
        some comments how intel_dp->DP is used in the disable code.
      
      v2: Be more careful with resetting intel_dp->DP - otherwise dpms
      off->on will fail spectacularly, becuase we enable the eDP port when
      we should only enable the eDP pll.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0767935e
    • Daniel Vetter's avatar
      drm/i915: clean up the cpu edp pll special case · 2bd2ad64
      Daniel Vetter authored
      
      
      By using the new pre_enable/post_disable functions.
      
      To ensure that we only frob the cpu edp pll while the pipe is off add
      the relevant asserts. Thanks to the new output state staging, this is
      now really easy.
      
      With this fixed we can now finally rip out the special-case handling
      in the dp dpms code and replace it by the common intel_connector_dpms.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2bd2ad64
    • Daniel Vetter's avatar
      drm/i915: add encoder->pre_enable/post_disable · bf49ec8c
      Daniel Vetter authored
      
      
      The cpu eDP encoder has some horrible hacks to set up the DP pll at
      the right time. To be able to move them to the right place, add some
      more encoder callbacks so that this can happen at the right time.
      
      LVDS has some similar funky hacks, but that would require more work
      (we need to move around the pll setup a bit). Hence for now only
      wire these new callbacks up for ilk+ - we only have cpu eDP on these
      platforms.
      
      v2: Bikeshed the vtable ordering, requested by Chris Wilson.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      bf49ec8c
    • Daniel Vetter's avatar
      drm/i915: rip out early dp port write for gm45/ilk · fba92150
      Daniel Vetter authored
      It's bogus.
      
      If I've followed the history of this piece of code correctly, i.e. the
      initial register write with the following vblank wait, this goes all
      the way back to the original enabling of DP support in
      
      commit a4fc5ed6
      Author: Keith Packard <keithp@keithp.com>
      Date:   Tue Apr 7 16:16:42 2009 -0700
      
          drm/i915: Add Display Port support
      
      Unfortunately it seems to be nothing more than glorified duct-tape and
      sometimes actively harmful. Adam Jackson noticed this for CPT
      platforms with
      
      commit e8519464
      
      
      Author: Adam Jackson <ajax@redhat.com>
      Date:   Thu Jul 21 17:48:38 2011 -0400
      
          drm/i915/dp: Don't turn CPT DP ports on too early
      
      Unfortunately this kept the code around for ilk and gm45.
      
      The specific failure case I'm seeing here is that after a dpms off/on
      cycle we have the bits from the last link training (hopefully
      successful link training) set in intel_dp->DP. This is requiered so
      that complete_link_train can enable the port with the right tuning
      values.
      
      Unfortunately writing these again to the disabled port at dpms on time
      kills the port somehow until it's disabled - dp link training fails in
      an endless loop without this patch on my mobile ilk and gm45.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51493
      
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fba92150