Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 18 11月, 2017 1 次提交
  3. 14 9月, 2017 1 次提交
  5. 16 8月, 2017 1 次提交
  7. 04 8月, 2017 1 次提交
  9. 26 7月, 2017 2 次提交
  11. 30 3月, 2017 1 次提交
  13. 08 2月, 2017 1 次提交
  15. 03 2月, 2017 1 次提交
    • G
      drm: Rely on mode_config data for fb_helper initialization · e4563f6b
      由 Gabriel Krisman Bertazi 提交于 
      Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure.  I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.

I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates.  The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.

// <smpl>
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)

@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)

@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
// </smpl>

Changes since v1:
 - Rebased on top of the tip of drm-misc-next.
 - Remove mention to sti since a proper fix got merged.
Suggested-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk
      e4563f6b
  17. 15 12月, 2016 1 次提交
  19. 14 11月, 2016 1 次提交
  21. 18 10月, 2016 1 次提交
  23. 15 9月, 2016 1 次提交
  25. 12 8月, 2016 2 次提交
  27. 17 3月, 2016 1 次提交
  29. 15 3月, 2016 1 次提交
  31. 03 12月, 2015 1 次提交
  33. 24 11月, 2015 1 次提交
    • L
      drm: Remove unused fbdev_list members · cb119717
      由 Lukas Wunner 提交于 
      I noticed that intel_fbdev->our_mode is unused. Introduced by
79e53945 ("DRM: i915: add mode setting support").

Then I noticed that intel_fbdev->fbdev_list is unused as well.
Introduced by 38651674 ("drm/fb: fix fbdev object model +
cleanup properly.") in i915, nouveau and radeon.

Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl,
virtio and mgag200.

Already removed from the latter with cc59487a ("drm/mgag200:
'fbdev_list' in 'struct mga_fbdev' is not used").

Remove it from the others.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cb119717
  35. 05 10月, 2015 1 次提交
  37. 02 10月, 2015 1 次提交
  39. 06 8月, 2015 1 次提交
  41. 09 7月, 2015 1 次提交
  43. 30 6月, 2015 1 次提交
  45. 20 3月, 2015 2 次提交
  47. 22 1月, 2015 1 次提交
  49. 21 1月, 2015 1 次提交
  51. 04 12月, 2014 1 次提交
  53. 24 9月, 2014 1 次提交
  55. 05 8月, 2014 2 次提交
  57. 08 7月, 2014 2 次提交
  59. 28 5月, 2013 1 次提交
  61. 14 2月, 2013 2 次提交
  63. 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
  65. 03 10月, 2012 2 次提交