Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 7月, 2014 1 次提交
    • B
      drm/nouveau/kms: restore fbcon after display has been resumed · 028791bb
      由 Ben Skeggs 提交于 
      Under some complicated circumstances (boot, suspend, resume, attach
second display, suspend, resume, suspend, detach second display,
resume, suspend, attach second display, resume), the fb_set_suspend()
call can somehow result in a modeset being attempted before we're
ready for it and things blow up in fun ways.

Running display init first fixes the issue.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      028791bb
  3. 26 3月, 2014 1 次提交
  5. 08 11月, 2013 1 次提交
  7. 09 10月, 2013 1 次提交
    • D
      drm/nouveau: embed gem object in nouveau_bo · 55fb74ad
      由 David Herrmann 提交于 
      There is no reason to keep the gem object separately allocated. nouveau is
the last user of gem_obj->driver_private, so if we embed it, we can get
rid of 8bytes per gem-object.

The implementation follows the radeon driver. bo->gem is only valid, iff
the bo was created via the gem helpers _and_ iff the user holds a valid
gem reference. That is, as the gem object holds a reference to the
nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
guaranteed to also hold a gem reference. The gem object might get
destroyed after the last user drops the gem-ref via
drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
gem-reference.

For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
valid. However, this shouldn't be used for real functionality to avoid
gem-internal dependencies.

Note that the implementation follows the previous style. However, we no
longer can check for bo->gem != NULL to test for a valid gem object. This
wasn't done before, so we should be safe now.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      55fb74ad
  9. 17 9月, 2013 1 次提交
  11. 30 7月, 2013 1 次提交
  13. 10 7月, 2013 1 次提交
  15. 01 7月, 2013 1 次提交
  17. 28 6月, 2013 1 次提交
  19. 14 2月, 2013 2 次提交
  21. 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
  23. 03 10月, 2012 6 次提交
  25. 26 6月, 2012 1 次提交
    • B
      drm/nouveau/fbcon: using nv_two_heads is not a good idea · 9bd0c15f
      由 Ben Skeggs 提交于 
      nv_two_heads() was never meant to be used outside of pre-nv50 code.  The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).

The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..

This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>
      9bd0c15f
  27. 24 5月, 2012 2 次提交
  29. 09 2月, 2012 1 次提交
  31. 21 12月, 2011 1 次提交
  33. 20 12月, 2011 1 次提交
  35. 16 11月, 2011 1 次提交
  37. 10 11月, 2011 1 次提交
  39. 23 6月, 2011 2 次提交
  41. 20 4月, 2011 1 次提交
  43. 25 2月, 2011 2 次提交
  45. 17 1月, 2011 1 次提交
  47. 15 1月, 2011 1 次提交
  49. 07 1月, 2011 1 次提交
  51. 21 12月, 2010 2 次提交
  53. 08 12月, 2010 1 次提交
  55. 03 12月, 2010 3 次提交