1. 04 Nov, 2013 1 commit
  2. 30 Oct, 2013 1 commit
  3. 25 Oct, 2013 1 commit
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-2013-10-18' of... · be51e4a7
      Dave Airlie authored
      Merge tag 'drm-intel-next-2013-10-18' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
      
      - CRC support from Damien and He Shuang. Long term this should allow us to
        test an awful lot modesetting corner cases automatically. So for me as
        the maintainer this is really big.
      - HDMI audio fix from Jani.
      - VLV dpll computation code refactoring from Ville.
      - Fixups for the gpu booster from last time around (Chris).
      - Some cleanups in the context code from Ben.
      - More watermark work from Ville (we'll be getting there ...).
      - vblank timestamp improvements from Ville.
      - CONFIG_FB=n support, including drm core changes to make the fbdev
        helpers optional.
      - DP link training improvements (Jani).
      - mmio vtable from Ben, prep work for future hw.
      
      * tag 'drm-intel-next-2013-10-18' of git://people.freedesktop.org/~danvet/drm-intel: (132 commits)
        drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp
        drm/i915: remove dead code in ironlake_crtc_mode_set
        drm/i915: crc support for hsw
        drm/i915: fix CRC debugfs setup
        drm/i915: wait one vblank when disabling CRCs
        drm/i915: use ->get_vblank_counter for the crc frame counter
        drm/i915: wire up CRC interrupt for ilk/snb
        drm/i915: add CRC #defines for ilk/snb
        drm/i915: extract display_pipe_crc_update
        drm/i915: don't Oops in debugfs for I915_FBDEV=n
        drm/i915: set HDMI pixel clock in audio configuration
        drm/i915: pass mode to ELD write vfuncs
        cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n
        drm/i915: check gem bo size when creating framebuffers
        drm/i915: Use unsigned long for obj->user_pin_count
        drm/i915: prevent tiling changes on framebuffer backing storage
        drm/i915: grab dev->struct_mutex around framebuffer_init
        drm/i915: vlv: fix VGA hotplug after modeset
        drm: add support for additional stereo 3D modes
        drm/i915: preserve dispaly init order on ByT
        ...
      be51e4a7
  4. 23 Oct, 2013 8 commits
  5. 22 Oct, 2013 3 commits
    • Russell King's avatar
      DRM: Armada: depend on ARM · 796c8e1c
      Russell King authored
      Armada DRM uses relaxed accessors which are not available on other
      platforms.  Limit it to just ARM.
      Acked-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      796c8e1c
    • Dave Airlie's avatar
      Merge branch 'drm-tda998x-3.12' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next · 5e4e3ba9
      Dave Airlie authored
      This adds support for the Armada 510 display subsystem found on the
      Marvell Dove devices.  This IP is re-used across several different Marvell
      SoCs with various tweaks, and this driver has been structured to allow
      the other IPs to re-use the bulk of this code; further work in this area
      is expected from interested parties.
      
      This has been extensively tested on the SolidRun Cubox platform and
      appears to work well there.
      
      [airlied: update for api changes merged previous to this]
      5e4e3ba9
    • Dave Airlie's avatar
      drm/sysfs: sort out minor and connector device object lifetimes. · 5bdebb18
      Dave Airlie authored
      So drm was abusing device lifetimes, by having embedded device structures
      in the minor and connector it meant that the lifetime of the internal drm
      objects (drm_minor and drm_connector) were tied to the lifetime of the device
      files in sysfs, so if something kept those files opened the current code
      would kfree the objects and things would go downhill from there.
      
      Now in reality there is no need for these lifetimes to be so intertwined,
      especailly with hotplugging of devices where we wish to remove the sysfs
      and userspace facing pieces before we can unwind the internal objects due
      to open userspace files or mmaps, so split the objects out so the struct
      device is no longer embedded and do what fbdev does and just allocate
      and remove the sysfs inodes separately.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      5bdebb18
  6. 18 Oct, 2013 18 commits
  7. 16 Oct, 2013 8 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
    • Damien Lespiau's avatar
      drm/i915: Use pipe_name() instead of the pipe number · 6f2bcceb
      Damien Lespiau authored
      Yet other direct usages of the pipe number instead of pipe_name().
      We've been tracking them lately but managed to miss these last ones.
      
      v2: Catch them all! (Ville)
      
      Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6f2bcceb
    • Chris Wilson's avatar
      drm/i915: Disable all GEM timers and work on unload · 45c5f202
      Chris Wilson authored
      We have two once very similar functions, i915_gpu_idle() and
      i915_gem_idle(). The former is used as the lower level operation to
      flush work on the GPU, whereas the latter is the high level interface to
      flush the GEM bookkeeping in addition to flushing the GPU. As such
      i915_gem_idle() also clears out the request and activity lists and
      cancels the delayed work. This is what we need for unloading the driver,
      unfortunately we called i915_gpu_idle() instead.
      
      In the process, make sure that when cancelling the delayed work and
      timer, which is synchronous, that we do not hold any locks to prevent a
      deadlock if the work item is already waiting upon the mutex. This
      requires us to push the mutex down from the caller to i915_gem_idle().
      
      v2: s/i915_gem_idle/i915_gem_suspend/
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: xunx.fang@intel.com
      [danvet: Only set ums.suspended for !kms as discussed earlier. Chris
      noticed that this slipped through.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      45c5f202