1. 02 Jun, 2014 7 commits
    • Vincent Stehlé's avatar
      imx-drm: imx-tve: remove unused variable · 46340642
      Vincent Stehlé authored
      Commit f9b0e251 'drm: make mode_valid callback optional' left variable ret
      unused; remove it.
      
      This fixes the following compilation warning:
      
        drivers/staging/imx-drm/imx-tve.c: In function ‘imx_tve_connector_mode_valid’:
        drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’ [-Wunused-variable]
      Signed-off-by: default avatarVincent Stehlé <vincent.stehle@laposte.net>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      46340642
    • Ross Zwisler's avatar
      drm: Missed clflushopt in drm_clflush_virt_range · 79270968
      Ross Zwisler authored
      With this commit:
      
      2a0788dc x86: Use clflushopt in drm_clflush_virt_range
      
      If clflushopt is available on the system, we use it instead of clflush
      in drm_clflush_virt_range.  There were two calls to clflush in this
      function, but only one was changed to clflushopt.  This patch changes
      the other clflush call to clflushopt.
      Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Reported-by: default avatarMatthew Wilcox <matthew.r.wilcox@intel.com>
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: dri-devel@lists.freedesktop.org
      Cc: H Peter Anvin <h.peter.anvin@intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      79270968
    • Thierry Reding's avatar
      drm/plane: Fix a couple of checkpatch warnings · 233fd4ec
      Thierry Reding authored
      Code should be indented using tabs rather than spaces (see CodingStyle)
      and the canonical form to declare a constant static variable is using
      "static const" rather than "const static". Fixes the following warnings
      from checkpatch:
      
      	$ scripts/checkpatch.pl -f drivers/gpu/drm/drm_plane_helper.c
      	WARNING: storage class should be at the beginning of the declaration
      	#40: FILE: drivers/gpu/drm/drm_plane_helper.c:40:
      	+const static uint32_t safe_modeset_formats[] = {
      
      	WARNING: please, no spaces at the start of a line
      	#41: FILE: drivers/gpu/drm/drm_plane_helper.c:41:
      	+       DRM_FORMAT_XRGB8888,$
      
      	WARNING: please, no spaces at the start of a line
      	#42: FILE: drivers/gpu/drm/drm_plane_helper.c:42:
      	+       DRM_FORMAT_ARGB8888,$
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      233fd4ec
    • Thierry Reding's avatar
      drm/plane: Fix sparse warnings · f220e626
      Thierry Reding authored
      Include the drm_plane_helper.h header file to fix the following sparse
      warnings:
      
      	  CHECK   drivers/gpu/drm/drm_plane_helper.c
      	drivers/gpu/drm/drm_plane_helper.c:102:5: warning: symbol 'drm_primary_helper_update' was not declared. Should it be static?
      	drivers/gpu/drm/drm_plane_helper.c:219:5: warning: symbol 'drm_primary_helper_disable' was not declared. Should it be static?
      	drivers/gpu/drm/drm_plane_helper.c:233:6: warning: symbol 'drm_primary_helper_destroy' was not declared. Should it be static?
      	drivers/gpu/drm/drm_plane_helper.c:241:30: warning: symbol 'drm_primary_helper_funcs' was not declared. Should it be static?
      	drivers/gpu/drm/drm_plane_helper.c:259:18: warning: symbol 'drm_primary_helper_create_plane' was not declared. Should it be static?
      
      Doing that makes gcc complain as follows:
      
      	  CC      drivers/gpu/drm/drm_plane_helper.o
      	drivers/gpu/drm/drm_plane_helper.c:260:19: error: conflicting types for 'drm_primary_helper_create_plane'
      	 struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
      	                   ^
      	In file included from drivers/gpu/drm/drm_plane_helper.c:29:0:
      	include/drm/drm_plane_helper.h:42:19: note: previous declaration of 'drm_primary_helper_create_plane' was here
      	 struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
      	                   ^
      	drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_create_plane':
      	drivers/gpu/drm/drm_plane_helper.c:274:11: warning: assignment discards 'const' qualifier from pointer target type
      	   formats = safe_modeset_formats;
      	           ^
      	In file included from include/linux/linkage.h:6:0,
      	                 from include/linux/kernel.h:6,
      	                 from include/drm/drmP.h:45,
      	                 from drivers/gpu/drm/drm_plane_helper.c:27:
      	drivers/gpu/drm/drm_plane_helper.c: At top level:
      	drivers/gpu/drm/drm_plane_helper.c:289:15: error: conflicting types for 'drm_primary_helper_create_plane'
      	 EXPORT_SYMBOL(drm_primary_helper_create_plane);
      	               ^
      	include/linux/export.h:57:21: note: in definition of macro '__EXPORT_SYMBOL'
      	  extern typeof(sym) sym;     \
      	                     ^
      	drivers/gpu/drm/drm_plane_helper.c:289:1: note: in expansion of macro 'EXPORT_SYMBOL'
      	 EXPORT_SYMBOL(drm_primary_helper_create_plane);
      	 ^
      	In file included from drivers/gpu/drm/drm_plane_helper.c:29:0:
      	include/drm/drm_plane_helper.h:42:19: note: previous declaration of 'drm_primary_helper_create_plane' was here
      	 struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
      	                   ^
      
      Which can easily be fixed by making the signatures of the implementation
      and the prototype match.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f220e626
    • Takashi Iwai's avatar
      drm/exynos: Fix double locks at PM resume · e4f0fd8c
      Takashi Iwai authored
      The recent commit [3ea87855: drm/helper: lock all around force mode
      restore] introduced drm_modeset_lock_all() in
      drm_helper_resume_force_mode() itself, while exynos driver takes this
      lock before calling it.  Move the function call outside the lock for
      avoiding a deadlock.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e4f0fd8c
    • Takashi Iwai's avatar
      drm/ast: Fix double lock at PM resume · d3dbd9b2
      Takashi Iwai authored
      The recent commit [3ea87855: drm/helper: lock all around force mode
      restore] introduced drm_modeset_lock_all() in
      drm_helper_resume_force_mode() itself, while ast driver still takes
      this lock before calling it.  Remove the caller side lock for avoid a
      fatal deadlock.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d3dbd9b2
    • Daniel Vetter's avatar
      drm/dp-helper: Deprecate old i2c-over-dp_aux heleprs · 2a8dc638
      Daniel Vetter authored
      Only gma500 is still using this, once that's converted we can kill all
      this code. If that conversion doesn't happen soonish I think we should
      just move this helper code into the gma500 driver itself to avoid
      abuse from new drivers.
      
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2a8dc638
  2. 30 May, 2014 3 commits
  3. 27 May, 2014 8 commits
  4. 26 May, 2014 4 commits
  5. 23 May, 2014 1 commit
  6. 19 May, 2014 6 commits
  7. 18 May, 2014 1 commit
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-2014-05-06' of git://anongit.freedesktop.org/drm-intel into drm-next · e5daa1dd
      Dave Airlie authored
      - ring init improvements (Chris)
      - vebox2 support (Zhao Yakui)
      - more prep work for runtime pm on Baytrail (Imre)
      - eDram support for BDW (Ben)
      - prep work for userptr support (Chris)
      - first parts of the encoder->mode_set callback removal (Daniel)
      - 64b reloc fixes (Ben)
      - first part of atomic plane updates (Ville)
      
      * tag 'drm-intel-next-2014-05-06' of git://anongit.freedesktop.org/drm-intel: (75 commits)
        drm/i915: Remove useless checks from primary enable/disable
        drm/i915: Merge LP1+ watermarks in safer way
        drm/i915: Make sure computed watermarks never overflow the registers
        drm/i915: Add pipe update trace points
        drm/i915: Perform primary enable/disable atomically with sprite updates
        drm/i915: Make sprite updates atomic
        drm/i915: Support 64b relocations
        drm/i915: Support 64b execbuf
        drm/i915/sdvo: Remove ->mode_set callback
        drm/i915/crt: Remove ->mode_set callback
        drm/i915/tv: Remove ->mode_set callback
        drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_set
        drm/i915/tv: De-magic device check
        drm/i915/tv: extract set_color_conversion
        drm/i915/tv: extract set_tv_mode_timings
        drm/i915/dvo: Remove ->mode_set callback
        drm/i915: Make encoder->mode_set callbacks optional
        drm/i915: Make primary_enabled match the actual hardware state
        drm/i915: Move ring_begin to signal()
        drm/i915: Virtualize the ringbuffer signal func
        ...
      e5daa1dd
  8. 16 May, 2014 2 commits
    • Dave Airlie's avatar
      Merge tag 'topic/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel into drm-next · 425a9a3a
      Dave Airlie authored
      Update pull request with drm core patches. Mostly some polish for the
      primary plane stuff and a pile of patches all over from Thierry. Has
      survived a few days in drm-intel-nightly without causing ill.
      
      I've frobbed my scripts a bit to also tag my topic branches so that you
      have something stable to pull - I've accidentally pushed a bunch more
      patches onto this branch before you've taken the old pull request.
      
      * tag 'topic/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel:
        drm: Make drm_crtc_helper_disable() return void
        drm: Fix indentation of closing brace
        drm/dp: Fix typo in comment
        drm: Fixup flip-work kerneldoc
        drm/fb: Fix typos
        drm/edid: Cleanup kerneldoc
        drm/edid: Drop revision argument for drm_mode_std()
        drm: Try to acquire modeset lock on panic or sysrq
        drm: remove unused argument from drm_open_helper
        drm: Handle ->disable_plane failures correctly
        drm: Simplify fb refcounting rules around ->update_plane
        drm/crtc-helper: gc usless connector loop in disable_unused_functions
        drm/plane_helper: don't disable plane in destroy function
        drm/plane-helper: Fix primary plane scaling check
        drm: make mode_valid callback optional
        drm/edid: Fill PAR in AVI infoframe based on CEA mode list
      425a9a3a
    • Dave Airlie's avatar
      drm: fix memory leak around mode_group (v2) · ad222799
      Dave Airlie authored
      This mode group id_list was never being freed.
      
      v2: take David's suggestion to free in minor_free.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      ad222799
  9. 06 May, 2014 6 commits
  10. 05 May, 2014 2 commits
    • Ben Widawsky's avatar
      drm/i915: Support 64b relocations · d9ceb957
      Ben Widawsky authored
      All the rest of the code to enable this is in my branch. Without my
      branch, hitting > 32b offsets is impossible. The code has always
      "supported" 64b, but it's never actually been run of tested. This change
      doesn't actually fix anything. [1] I am not sure why X won't work yet. I
      do not get hangs or obvious errors.
      
      There are 3 fixes grouped together here. First is to remove the
      hardcoded 0 for the upper dword of the relocation. The next fix is to
      use a 64b value for target_offset. The final fix is to not directly
      apply target_offset to reloc->delta. reloc->delta is part of ABI, and so
      we cannot change it. As it stands, 32b is enough to represent everything
      we're interested in representing anyway. The main problem is, we cannot
      add greater than 32b values to it directly.
      
      [1] Almost all of intel-gpu-tools is not yet ready to test 64b
      relocations. There are a few places that expect 32b values for offsets
      and these all won't work.
      
      Cc: Rafael Barbalho <rafael.barbalho@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d9ceb957
    • Ben Widawsky's avatar
      drm/i915: Support 64b execbuf · 9bcb144c
      Ben Widawsky authored
      Previously, our code only had a 32b offset value for where the
      batchbuffer starts. With full PPGTT, and 64b canonical GPU address
      space, that is an insufficient value. The code to expand is pretty
      straight forward, and only one platform needs to do anything with the
      extra bits.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarRafael Barbalho <rafael.barbalho@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9bcb144c