Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 12月, 2016 2 次提交
  3. 14 11月, 2016 2 次提交
  5. 20 10月, 2016 1 次提交
  7. 18 10月, 2016 1 次提交
  9. 19 6月, 2016 1 次提交
  11. 13 6月, 2016 1 次提交
  13. 08 6月, 2016 1 次提交
  15. 04 6月, 2016 2 次提交
  17. 01 6月, 2016 1 次提交
  19. 17 5月, 2016 3 次提交
  21. 12 5月, 2016 1 次提交
  23. 02 5月, 2016 1 次提交
  25. 20 1月, 2016 1 次提交
  27. 15 1月, 2016 1 次提交
  29. 15 12月, 2015 1 次提交
  31. 24 11月, 2015 1 次提交
  33. 06 8月, 2015 1 次提交
  35. 22 7月, 2015 2 次提交
  37. 12 3月, 2015 1 次提交
  39. 08 7月, 2014 2 次提交
  41. 05 6月, 2014 1 次提交
  43. 21 8月, 2013 1 次提交
  45. 28 5月, 2013 1 次提交
  47. 20 2月, 2013 1 次提交
  49. 18 2月, 2013 2 次提交
  51. 14 2月, 2013 3 次提交
  53. 21 1月, 2013 1 次提交
    • D
      drm: revamp framebuffer cleanup interfaces · 36206361
      由 Daniel Vetter 提交于 
      We have two classes of framebuffer
- Created by the driver (atm only for fbdev), and the driver holds
  onto the last reference count until destruction.
- Created by userspace and associated with a given fd. These
  framebuffers will be reaped when their assoiciated fb is closed.

Now these two cases are set up differently, the framebuffers are on
different lists and hence destruction needs to clean up different
things. Also, for userspace framebuffers we remove them from any
current usage, whereas for internal framebuffers it is assumed that
the driver has done this already.

Long story short, we need two different ways to cleanup such drivers.
Three functions are involved in total:
- drm_framebuffer_remove: Convenience function which removes the fb
  from all active usage and then drops the passed-in reference.
- drm_framebuffer_unregister_private: Will remove driver-private
  framebuffers from relevant lists and drop the corresponding
  references. Should be called for driver-private framebuffers before
  dropping the last reference (or like for a lot of the drivers where
  the fbdev is embedded someplace else, before doing the cleanup
  manually).
- drm_framebuffer_cleanup: Final cleanup for both classes of fbs,
  should be called by the driver's ->destroy callback once the last
  reference is gone.

This patch just rolls out the new interfaces and updates all drivers
(by adding calls to drm_framebuffer_unregister_private at all the
right places)- no functional changes yet. Follow-on patches will move
drm core code around and update the lifetime management for
framebuffers, so that we are no longer required to keep framebuffers
alive by locking mode_config.mutex.

I've also updated the kerneldoc already.

vmwgfx seems to again be a bit special, at least I haven't figured out
how the fbdev support in that driver works. It smells like it's
external though.

v2: The i915 driver creates another private framebuffer in the
load-detect code. Adjust its cleanup code, too.
Reviewed-by: NRob Clark <rob@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      36206361
  55. 20 1月, 2013 1 次提交
    • D
      drm/<drivers>: reorder framebuffer init sequence · c7d73f6a
      由 Daniel Vetter 提交于 
      With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by the time drivers
call drm_framebuffer_init.

This patch here is the drivers part of that reorg. Nothing really fancy
going on safe for three special cases.

- exynos needs to be careful to properly unref all handles.
- nouveau gets a resource leak fixed for free: one of the error
  cases didn't cleanup the framebuffer, which is now moot since
  the framebuffer is only registered once it is fully set up.
- vmwgfx requires a slight reordering of operations, I'm hoping I didn't
  break anything (but it's refcount management only, so should be safe).

v2: Split out exynos, since it's a bit more hairy than expected.

v3: Drop bogus cirrus hunk noticed by Richard Wilbur.

v4: Split out vmwgfx since there's a small change in return values.

Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c7d73f6a
  57. 23 10月, 2012 2 次提交