1. 17 1月, 2014 13 次提交
  2. 08 1月, 2014 4 次提交
    • R
      drivers: gpu: Mark functions as static in vmwgfx_fence.c · 94844cf0
      Rashika Kheria 提交于
      Mark functions as static because they are not used outside the file
      drm/vmwgfx/vmwgfx_fence.c.
      
      This eliminates the following warnings in drm/vmwgfx/vmwgfx_fence.c:
      drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:274:6: warning: no previous prototype for ‘vmw_fences_perform_actions’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:900:6: warning: no previous prototype for ‘vmw_fence_obj_add_action’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:996:5: warning: no previous prototype for ‘vmw_event_fence_action_create’ [-Wmissing-prototypes]
      Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
      94844cf0
    • R
      drivers: gpu: Mark functions as static in vmwgfx_buffer.c · 8227622f
      Rashika Kheria 提交于
      Mark functions as static because they are not used outside the file
      drm/vmwgfx/vmwgfx_buffer.c.
      
      This eliminates the following warnings in drm/vmwgfx/vmwgfx_buffer.c:
      drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:520:16: warning: no previous prototype for ‘vmw_ttm_tt_create’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:549:5: warning: no previous prototype for ‘vmw_invalidate_caches’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:554:5: warning: no previous prototype for ‘vmw_init_mem_type’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:592:6: warning: no previous prototype for ‘vmw_evict_flags’ [-Wmissing-prototypes]
      Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
      8227622f
    • R
      drivers: gpu: Mark functions as static in vmwgfx_kms.c · 847c5964
      Rashika Kheria 提交于
      Mark functions as static because they are not used outside the file
      drm/vmwgfx/vmwgfx_kms.c.
      
      This eliminates the following warnings in drm/vmwgfx/vmwgfx_kms.c:
      drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:43:6: warning: no previous prototype for ‘vmw_clip_cliprects’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:426:6: warning: no previous prototype for ‘vmw_framebuffer_surface_destroy’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:592:5: warning: no previous prototype for ‘vmw_framebuffer_surface_dirty’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:757:6: warning: no previous prototype for ‘vmw_framebuffer_dmabuf_destroy’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:943:5: warning: no previous prototype for ‘vmw_framebuffer_dmabuf_dirty’ [-Wmissing-prototypes]
      drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:1666:5: warning: no previous prototype for ‘vmw_du_update_layout’ [-Wmissing-prototypes]
      Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
      847c5964
    • T
      drm/ttm: ttm object security fixes for render nodes · 05efb1ab
      Thomas Hellstrom 提交于
      When a client looks up a ttm object, don't look it up through the device hash
      table, but rather from the file hash table. That makes sure that the client
      has indeed put a reference on the object, or in gem terms, has opened
      the object; either using prime or using the global "name".
      
      To avoid a performance loss, make sure the file hash table entries can be
      looked up from under an RCU lock, and as a consequence, replace the rwlock
      with a spinlock, since we never need to take it in read mode only anymore.
      
      Finally add a ttm object lookup function for the device hash table, that is
      intended to be used when we put a ref object on a base object or, in  gem terms,
      when we open the object.
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NBrian Paul <brianp@vmware.com>
      05efb1ab
  3. 18 12月, 2013 2 次提交
  4. 05 12月, 2013 4 次提交
  5. 18 11月, 2013 4 次提交
  6. 13 11月, 2013 2 次提交
  7. 08 11月, 2013 1 次提交
  8. 06 11月, 2013 3 次提交
  9. 16 10月, 2013 2 次提交
  10. 30 8月, 2013 3 次提交
  11. 19 8月, 2013 2 次提交
    • D
      drm/vmwgfx: remove ->firstopen callback · 0faa4a87
      Daniel Vetter 提交于
      So if we survey kms drivers there's a bunch of things they commonly do
      in ->lastclose
      - delayed processing of vga switcheroo requests (i915, nouveau,
        radeon)
      - force-restoring the fbcon (most)
      - resetting a bunch properties to make fbcon work better (omap)
      - disabling all outputs (vmwgfx)
      
      In short besides the semantically important vga switcheroo stuff they
      all try very hard to keep fbcon working in case X dies.
      
      But none of them try to not do this at driver unload time safe for
      vmwgfx, and digging through logs I couldn't find any reason for why
      vmwgfx is special.
      
      Since ->firstopen has lots of potential for abuse with kms drivers
      (like delaying driver setup to pamper over races in the load sequence)
      it's imo very much worth it to remove this logic so that we can
      stop using the ->firstopen callback for kms drivers.
      
      Also module unloading is rather a debug feature and developers should
      know how to restore the display to a sane configuration.
      
      Cc: Jakob Bornecrantz <jakob@vmware.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      0faa4a87
    • D
      drm: remove FASYNC support · b0e898ac
      Daniel Vetter 提交于
      So I've stumbled over drm_fasync and wondered what it does. Digging
      that up is quite a story.
      
      First I've had to read up on what this does and ended up being rather
      bewildered why peopled loved signals so much back in the days that
      they've created SIGIO just for that ...
      
      Then I wondered how this ever works, and what that strange "No-op."
      comment right above it should mean. After all calling the core fasync
      helper is pretty obviously not a noop. After reading through the
      kernels FASYNC implementation I've noticed that signals are only sent
      out to the processes attached with FASYNC by calling kill_fasync.
      
      No merged drm driver has ever done that.
      
      After more digging I've found out that the only driver that ever used
      this is the so called GAMMA driver. I've frankly never heard of such a
      gpu brand ever before. Now FASYNC seems to not have been the only bad
      thing with that driver, since Dave Airlie removed it from the drm
      driver with prejudice:
      
      commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
      Author: Dave Airlie <airlied@linux.ie>
      Date:   Sun Aug 29 12:04:35 2004 +0000
      
          Drop GAMMA DRM from a great height ...
      
      Long story short, the drm fasync support seems to be doing absolutely
      nothing. And the only user of it was never merged into the upstream
      kernel. And we don't need any fops->fasync callback since the fcntl
      implementation in the kernel already implements the noop case
      correctly.
      
      So stop this particular cargo-cult and rip it all out.
      
      v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
      (somehow I've missed that one in staging). Also drop the reference in
      the drm DocBook. ARM compile-fail reported by Rob Clark.
      
      v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
      patch here.
      
      v4: Actually git add ... tsk.
      
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b0e898ac