Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 12 8月, 2016 1 次提交
  3. 24 6月, 2016 1 次提交
  5. 02 6月, 2016 1 次提交
  7. 20 5月, 2016 1 次提交
  9. 20 4月, 2016 1 次提交
  11. 12 10月, 2015 1 次提交
    • B
      drm/nouveau/fbcon: take runpm reference when userspace has an open fd · f231976c
      由 Ben Skeggs 提交于 
      We need to do this in order to prevent accesses to the device while it's
powered down.  Userspace may have an mmap of the fb, and there's no good
way (that I know of) to prevent it from touching the device otherwise.

This fixes some nasty races between runpm and plymouth on some systems,
which result in the GPU getting very upset and hanging the boot.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
      f231976c
  13. 06 8月, 2015 1 次提交
  15. 05 3月, 2015 1 次提交
  17. 22 1月, 2015 1 次提交
  19. 21 1月, 2015 1 次提交
  21. 02 12月, 2014 2 次提交
  23. 02 10月, 2014 1 次提交
    • B
      drm/nouveau: punt fbcon resume out to a workqueue · 634ffccc
      由 Ben Skeggs 提交于 
      Preparation for some runtime pm fixes.  Currently we skip over fbcon
suspend/resume in the runtime path, which causes issues on resume if
fbcon tries to write to the framebuffer before the BAR subdev has
been resumed to restore the BAR1 VM setup.

As we might be woken up via a sysfs connector, we are unable to call
fb_set_suspend() in the resume path as it could make its way down to
a modeset and cause all sorts of locking hilarity.

To solve this, we'll just delay the fbcon resume to a workqueue.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      634ffccc
  25. 24 9月, 2014 1 次提交
  27. 15 9月, 2014 1 次提交
  29. 15 8月, 2014 1 次提交
  31. 10 8月, 2014 6 次提交
  33. 08 7月, 2014 3 次提交
  35. 26 3月, 2014 1 次提交
  37. 08 11月, 2013 1 次提交
  39. 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
  41. 17 9月, 2013 1 次提交
  43. 30 7月, 2013 1 次提交
  45. 10 7月, 2013 1 次提交
  47. 01 7月, 2013 1 次提交
  49. 28 6月, 2013 1 次提交
  51. 14 2月, 2013 2 次提交
  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. 03 10月, 2012 4 次提交
    • B
      drm/nouveau: port remainder of drm code, and rip out compat layer · 77145f1c
      由 Ben Skeggs 提交于 
      v2: Ben Skeggs <bskeggs@redhat.com>
- fill in nouveau_pm.dev to prevent oops
- fix ppc issues (build + OF shadow)
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      77145f1c
    • B
      drm/nouveau: port all engines to new engine module format · ebb945a9
      由 Ben Skeggs 提交于 
      This is a HUGE commit, but it's not nearly as bad as it looks - any problems
can be isolated to a particular chipset and engine combination.  It was
simply too difficult to port each one at a time, the compat layers are
*already* ridiculous.

Most of the changes here are simply to the glue, the process for each of the
engine modules was to start with a standard skeleton and copy+paste the old
code into the appropriate places, fixing up variable names etc as needed.

v2: Marcin Slusarz <marcin.slusarz@gmail.com>
- fix find/replace bug in license header

v3: Ben Skeggs <bskeggs@redhat.com>
- bump indirect pushbuf size to 8KiB, 4KiB barely enough for userspace and
  left no space for kernel's requirements during GEM pushbuf submission.
- fix duplicate assignments noticed by clang

v4: Marcin Slusarz <marcin.slusarz@gmail.com>
- add sparse annotations to nv04_fifo_pause/nv04_fifo_start
- use ioread32_native/iowrite32_native for fifo control registers

v5: Ben Skeggs <bskeggs@redhat.com>
- rebase on v3.6-rc4, modified to keep copy engine fix intact
- nv10/fence: unmap fence bo before destroying
- fixed fermi regression when using nvidia gr fuc
- fixed typo in supported dma_mask checking
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      ebb945a9
    • B
      drm/nouveau/fb: merge fb/vram and port to subdev interfaces · 861d2107
      由 Ben Skeggs 提交于 
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      861d2107
    • B
      drm/nouveau: implement module init functions in nouveau_drm.c · 94580299
      由 Ben Skeggs 提交于 
      These currently just call the existing ones in nouveau_drv.c, but will be
extended in upcoming commits.  This needed to be separated from the current
code as there will be some header clashes until things are ported.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      94580299