[Intel-gfx] [PATCH 00/12] fbdev helper locking rework and deferred setup
John Stultz
john.stultz at linaro.org
Wed Jun 21 23:01:02 UTC 2017
On Wed, Jun 21, 2017 at 11:28 AM, Daniel Vetter <daniel.vetter at ffwll.ch> 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 at linaro.org>
thanks
-john
More information about the Intel-gfx
mailing list