1. 02 11月, 2016 1 次提交
  2. 22 7月, 2016 1 次提交
  3. 21 5月, 2016 1 次提交
    • D
      drm: Nuke ->vblank_disable_allowed · fcee5906
      Daniel Vetter 提交于
      This was added in
      
      commit 0a3e67a4
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Tue Sep 30 12:14:26 2008 -0700
      
          drm: Rework vblank-wait handling to allow interrupt reduction.
      
      to stay backwards-compatible with old UMS code that didn't even tell
      the kernel when it did a modeset, so that the kernel could
      save/restore vblank counters. At worst this means vblanks will be
      somewhat funky on a setup that very likely no one still runs.
      
      So let's just nuke it.
      
      Plan B would be to set it unconditionally in drm_vblank_init for kms
      drivers, instead of in each driver separately. So if this patch breaks
      anything please only restore the hunks in drmP.h and drm_irq.c, plus
      add a check for DRIVER_MODESET in drm_vblank_init.
      
      Stumbled over this in a discussion on irc with Chris.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Mark Yao <mark.yao@rock-chips.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Philipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      fcee5906
  4. 26 1月, 2016 1 次提交
  5. 02 12月, 2014 1 次提交
  6. 10 9月, 2014 1 次提交
  7. 13 8月, 2014 1 次提交
  8. 10 6月, 2014 1 次提交
  9. 05 6月, 2014 1 次提交
  10. 23 4月, 2014 1 次提交
  11. 18 3月, 2014 8 次提交
  12. 08 11月, 2013 1 次提交
  13. 06 11月, 2013 1 次提交
  14. 09 10月, 2013 2 次提交
  15. 19 8月, 2013 2 次提交
    • D
      drm: rip out a few unused DRIVER flags · 74867e3d
      Daniel Vetter 提交于
      The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
      there's no code at all to check for this we can kill it. The other two
      are completely unused.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      74867e3d
    • 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
  16. 07 8月, 2013 2 次提交
  17. 24 7月, 2013 4 次提交
  18. 07 4月, 2013 1 次提交
  19. 21 1月, 2013 1 次提交
    • D
      drm/gma500: use drm_modeset_lock_all · 0a819515
      Daniel Vetter 提交于
      Only two places:
      - suspend/resume
      - Some really strange mode validation tool with too much funny-lucking
        hand-rolled conversion code.
      - The recently-added lastclose fbdev restore code.
      
      Better safe than sorry, so convert both places to keep the locking
      semantics as much as possible.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0a819515
  20. 20 1月, 2013 1 次提交
    • D
      drm/gma500: move fbcon restore to lastclose · 7147573a
      Daniel Vetter 提交于
      Doing this within the fb->destroy callback leads to a locking
      nightmare. And all other drm drivers that restore the fbcon do
      it in lastclose, too.
      
      With this adjustments all fb->destroy callbacks optionally drop
      references to any gem objects used as backing storage, call
      drm_framebuffer_cleanup and then kfree the struct. Which nicely
      simplifies the locking for framebuffer unreferencing and freeing,
      since this doesn't require that we hold the mode_config lock. A
      slight exception is the vmwgfx surface backed framebuffer, it also
      calls drm_master_put and removes the object from a device-private
      framebuffer list. Both seem to have solid locking in place already.
      
      Conclusion is that now it is no longer required to hold the
      mode_config lock while freeing a framebuffer.
      
      v2: Drop the corresponding mutex_lock WARN check from
      drm_framebuffer_unreference.
      
      v3: Use just the mode_config lock not modeset_lock_all, due to patch
      reordering.
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7147573a
  21. 03 10月, 2012 1 次提交
  22. 20 7月, 2012 1 次提交
  23. 17 7月, 2012 1 次提交
  24. 02 6月, 2012 1 次提交
  25. 22 5月, 2012 1 次提交
  26. 17 5月, 2012 2 次提交