1. 21 Oct, 2013 20 commits
  2. 18 Oct, 2013 14 commits
  3. 16 Oct, 2013 6 commits
    • Daniel Vetter's avatar
      drm/i915: Use unsigned long for obj->user_pin_count · aa5f8021
      Daniel Vetter authored
      At least on linux sizeof(long) == sizeof(void*) and the thinking
      is that you can grab about as many references as there's memory.
      
      Doesn't really matter, just a bit of OCD since the fixed size data
      type in a pure in-kernel datastructure look off.
      
      v2: Ville asked for an overflow check since no one prevents userspace
      from incrementing the pin count forever.
      
      v3: s/INT/LONG/, noticed by Chris.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      aa5f8021
    • Daniel Vetter's avatar
      drm/i915: prevent tiling changes on framebuffer backing storage · 80075d49
      Daniel Vetter authored
      Assuming that all framebuffer related metadata is invariant simplifies
      our userspace input data checking. And current userspace always first
      updates the tiling of an object before creating a framebuffer with it.
      
      This allows us to upconvert a check in pin_and_fence to a WARN.
      
      In the future it should also be helpful to know which buffer objects
      are potential scanout targets for e.g. frontbuffer rendering tracking
      and similar things.
      
      Note that SNA shipped for one prerelease with code which will be
      broken through this patch. But users shouldn't notice since it's
      purely an optimization and will transparently fall back to allocating
      a new fb. i-g-t also had offending code (now fixed), but we don't
      really care about breaking the test-suite.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Grumpily-reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      80075d49
    • Daniel Vetter's avatar
      drm/i915: grab dev->struct_mutex around framebuffer_init · dd4916c5
      Daniel Vetter authored
      We look at gem state (like obj->tiling/obj->stride), we better have
      the relevant locks.
      
      Right now this doesn't matter much since most of these checks are
      a curtesy to safe buggy userspace, but I'd like to freeze the tiling
      once we have framebuffer objects attached. And then locking matters.
      
      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>
      dd4916c5
    • Imre Deak's avatar
      drm/i915: vlv: fix VGA hotplug after modeset · 533df0fe
      Imre Deak authored
      Since
      
      commit 912d812e
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Oct 11 20:08:23 2012 +0200
      
          drm/i915/crt: don't set HOTPLUG bits on !PCH
      
      on VLV we don't detect any VGA unplug event after a modeset, since there we
      reset the ADPA hotplug bits. Fix it by preserving the hotplug bits on VLV as
      well.
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      [danvet: For consistency use gen >= 5 like in Chris' exact same fix
      in intel_crt_reset.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      533df0fe
    • Thomas Wood's avatar
      drm: add support for additional stereo 3D modes · fbf46025
      Thomas Wood authored
      Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
      Specific Data Block to expose more stereo 3D modes.
      
      v2: Use (1 << 0) for consistency. (Ville Syrjälä)
          Skip adding any modes if 3D_MASK is indicated as being present but
          the length only includes 3D_Structure_ALL. (Ville Syrjälä)
          Check that the value of HDMI_3D_LEN is large enough to include
          3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä)
      v3: Increment offset before the length checks. (Ville Syrjälä)
      Signed-off-by: default avatarThomas Wood <thomas.wood@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fbf46025
    • Artem Bityutskiy's avatar
      drm/i915: preserve dispaly init order on ByT · 585a94b8
      Artem Bityutskiy authored
      This patch changes HDMI port registration order for the BayTrail platform.
      
      The story is that in kernel version 3.11 i915 supported only one HDMI port -
      the HDMIB port. So this port ended up being HDMI-1 in user-space.
      
      But commit '6f6005a5 drm/i915: expose HDMI connectors on port C on BYT'
      introduced HDMIC port support. And added HDMIC  registration prior to HDMIB,
      so HDMIB became HDMI-2 and HDMIC became HDMI-1.
      
      Well, this is fine as far as the kernel is concerned. i915 does not give any
      guarantees to the numbering, and has never given them.
      
      However, this breaks wayland setup in Tizen IVI. We have only one single HDMI
      port on our hardware, and it is connected to HDMIB. Our configuration relies on
      the fact that it is HDMI-1.
      
      Well, certainly this is user-space problem which was exposed with Jesse's
      patch. However, there is a reason why we have to do this assumption - we use
      touchscreen monitors and we have to associate event devices with the monitors,
      and this is not easy to do dynamically, so we just have a static setup.
      
      Anyway, while the user-space setup will have to be fixed regardless, let's
      chane the HDMI port registration order so that HDMIB stays HDMI-1, just like it
      was in 3.11. Simply because there is no strong reason for changing the order in
      the kernel, and it'll help setups like ours in sense that we'll have more time
      for fixing the issue properly.
      
      Also amend the commentary which looks a bit out-of-date.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      [danvet: Drop the commment, SDVOC is gone and we have a proper HDMIC
      define now.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      585a94b8