Re: [PATCH 00/12] fbdev helper locking rework and deferred setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 21, 2017 at 11:28 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
> Hi all,
>
> This is Thierry's deferred fbdev setup series, with the locking rework almost
> entirely redone. The much wider scope is to get rid of drm_modeset_lock_all
> calls for atomic drivers and remove users of the fairly nasty
> mode_config->acquire_ctx hack, which breaks when doing multiple atomic commits.
>
> Testing&review very much appreciated, especially from people who care about the
> various fbdev emulation things and the deferred setup stuff.
>
> Thanks, Daniel
>
> Daniel Vetter (7):
>   drm/i915: Drop FBDEV #ifdev in mst code
>   drm/fb-helper: Push locking in fb_is_bound
>   drm/fb-helper: Drop locking from the vsync wait ioctl code
>   drm/fb-helper: Push locking into pan_display_atomic|legacy
>   drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy
>   drm/fb-helper: Stop using mode_config.mutex for internals
>   drm/fb-helper: Split dpms handling into legacy and atomic paths
>
> Thierry Reding (5):
>   drm/fb-helper: Push down modeset lock into FB helpers
>   drm/fb-helper: Add top-level lock
>   drm/fb-helper: Support deferred setup
>   drm/exynos: Remove custom FB helper deferred setup
>   drm/hisilicon: Remove custom FB helper deferred setup
>
>  drivers/gpu/drm/drm_fb_helper.c                 | 361 ++++++++++++++++++------
>  drivers/gpu/drm/drm_vblank.c                    |   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c         |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c       |  26 +-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  21 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c             |  43 +--
>  drivers/gpu/drm/radeon/radeon_dp_mst.c          |   7 -
>  include/drm/drm_fb_helper.h                     |  42 ++-
>  8 files changed, 336 insertions(+), 172 deletions(-)

So in testing this patchset against 4.12-rc6, w/ HiKey (so I had a bit
of fuzz on one patch, and skipped the drm_vblank changes and the
entire exynos patch), it seems to work ok. I rebooted 10 times and
didn't see the initialization race where multiple fbs were created
that I could regularly trigger before.

Tested-by: John Stultz <john.stultz@xxxxxxxxxx>

thanks
-john
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux