All of
 help / color / mirror / Atom feed
From: Maarten Lankhorst <>
To: Daniel Vetter <>,
	DRI Development <>
Cc: Intel Graphics Development <>,
	Thierry Reding <>
Subject: Re: [PATCH 10/13] drm/fb-helper: Support deferred setup
Date: Wed, 5 Jul 2017 13:20:46 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Op 04-07-17 om 17:18 schreef Daniel Vetter:
> FB helper code falls back to a 1024x768 mode if no outputs are connected
> or don't report back any modes upon initialization. This can be annoying
> because outputs that are added to FB helper later on can't be used with
> FB helper if they don't support a matching mode.
> The fallback is in place because VGA connectors can happen to report an
> unknown connection status even when they are in fact connected.
> Some drivers have custom solutions in place to defer FB helper setup
> until at least one output is connected. But the logic behind these
> solutions is always the same and there is nothing driver-specific about
> it, so a better alterative is to fix the FB helper core and add support
> for all drivers automatically.
> This patch adds support for deferred FB helper setup. It checks all the
> connectors for their connection status, and if all of them report to be
> disconnected marks the FB helper as needing deferred setup. Whet setup
> is deferred, the FB helper core will automatically retry setup after a
> hotplug event, and it will keep trying until it succeeds.
> v2: Rebase onto my entirely reworked fbdev helper locking. One big
> difference is that this version again drops&reacquires the fbdev lock
> (which is now fb_helper->lock, but before this patch series it was
> mode_config->mutex), because register_framebuffer must be able to
> recurse back into fbdev helper code for the initial screen setup.
> v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
> return, I've fumbled that in the deferred setup case (Liviu).
> v4: I was blind, redo this all. __drm_fb_helper_initial_config
> shouldn't need to reacquire fb_helper->lock, that just confuses
> callers. I myself got confused by kernel_fb_helper_lock and somehow
> thought it's the same as fb_helper->lock. Tsk.
> Also simplify the logic a bit (we don't need two functions to probe
> connectors), we can stick much closer to the existing code. And update
> some comments I've spotted that are outdated.
> v5: Don't pass -EAGAIN to drivers, it's just an internal error code
> (Liviu).
> v6: Add _and_unlock suffix to clarify locking (Maarten)
If you remove intel_fbdev_output_poll_changed's null check for ifbdev->fb,
and apply 11 before this one, then for the first 11 patches:

Reviewed-by: Maarten Lankhorst <>

It should probably be noted in this commit that this change results in no longer registering the intel fb if no output is connected,
in which case dummy fb is always used.

dri-devel mailing list

  parent reply	other threads:[~2017-07-05 11:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-04 15:18 [PATCH 00/13] fbdev locking + deferred setup take 3 Daniel Vetter
2017-07-04 15:18 ` [PATCH 01/13] drm/fb-helper: Push down modeset lock into FB helpers Daniel Vetter
2017-07-04 15:18 ` [PATCH 02/13] drm/i915: Drop FBDEV #ifdev in mst code Daniel Vetter
2017-07-04 15:18 ` [PATCH 03/13] drm/fb-helper: Add top-level lock Daniel Vetter
2017-07-04 15:18 ` [PATCH 04/13] drm/fb-helper: Push locking in fb_is_bound Daniel Vetter
2017-07-04 15:18 ` [PATCH 05/13] drm/fb-helper: Drop locking from the vsync wait ioctl code Daniel Vetter
2017-07-04 15:18 ` [PATCH 06/13] drm/fb-helper: Push locking into pan_display_atomic|legacy Daniel Vetter
2017-07-04 15:18 ` [PATCH 07/13] drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy Daniel Vetter
2017-07-04 15:18 ` [PATCH 08/13] drm/fb-helper: Stop using mode_config.mutex for internals Daniel Vetter
2017-07-04 15:40   ` Ville Syrjälä
2017-07-04 16:19     ` Daniel Vetter
2017-07-05  4:56   ` [PATCH] " Daniel Vetter
2017-07-04 15:18 ` [PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths Daniel Vetter
2017-07-04 15:18 ` [PATCH 10/13] drm/fb-helper: Support deferred setup Daniel Vetter
2017-07-04 15:29   ` Liviu Dudau
2017-07-05 11:20   ` Maarten Lankhorst [this message]
2017-07-04 15:18 ` [PATCH 11/13] drm/i915: Protect against deferred fbdev setup Daniel Vetter
2017-07-05 10:08   ` Maarten Lankhorst
2017-07-05 20:17     ` Daniel Vetter
2017-07-04 15:18 ` [PATCH 12/13] drm/exynos: Remove custom FB helper deferred setup Daniel Vetter
2017-07-06  3:16   ` Inki Dae
2017-07-04 15:18 ` [PATCH 13/13] drm/hisilicon: " Daniel Vetter
2017-07-04 16:39 ` ✓ Fi.CI.BAT: success for fbdev locking + deferred setup take 3 Patchwork
2017-07-05  5:14 ` ✓ Fi.CI.BAT: success for fbdev locking + deferred setup take 3 (rev2) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2017-06-27 14:59 [PATCH 00/13] fbdev locking rework and deferred setup, take 2 Daniel Vetter
2017-06-27 14:59 ` [PATCH 10/13] drm/fb-helper: Support deferred setup Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH 10/13] drm/fb-helper: Support deferred setup' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.