Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 10月, 2017 1 次提交
  3. 04 8月, 2017 1 次提交
  5. 17 2月, 2017 2 次提交
  7. 08 2月, 2017 1 次提交
  9. 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
  11. 27 1月, 2017 1 次提交
    • L
      drm/nouveau: Handle fbcon suspend/resume in seperate worker · 15266ae3
      由 Lyude Paul 提交于 
      Resuming from RPM can happen while already holding
dev->mode_config.mutex. This means we can't actually handle fbcon in
any RPM resume workers, since restoring fbcon requires grabbing
dev->mode_config.mutex again. So move the fbcon suspend/resume code into
it's own worker, and rely on that instead to avoid deadlocking.

This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
W541. Reproduction recipe:

 - Get a machine with both optimus and a nvidia card with connectors
   attached to it
 - Wait for the nvidia GPU to suspend
 - Attempt to manually reprobe any of the connectors on the nvidia GPU
   using sysfs
 - *deadlock*

[airlied: use READ_ONCE to address Hans's comment]
Signed-off-by: NLyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      15266ae3
  13. 27 12月, 2016 1 次提交
  15. 15 12月, 2016 1 次提交
  17. 14 11月, 2016 1 次提交
  19. 07 11月, 2016 4 次提交
  21. 12 8月, 2016 1 次提交
  23. 24 6月, 2016 1 次提交
  25. 02 6月, 2016 1 次提交
  27. 20 5月, 2016 1 次提交
  29. 20 4月, 2016 1 次提交
  31. 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
  33. 06 8月, 2015 1 次提交
  35. 05 3月, 2015 1 次提交
  37. 22 1月, 2015 1 次提交
  39. 21 1月, 2015 1 次提交
  41. 02 12月, 2014 2 次提交
  43. 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
  45. 24 9月, 2014 1 次提交
  47. 15 9月, 2014 1 次提交
  49. 15 8月, 2014 1 次提交
  51. 10 8月, 2014 6 次提交
  53. 08 7月, 2014 3 次提交
  55. 26 3月, 2014 1 次提交