Skip to content
  • Daniel Vetter's avatar
    drm/fb-helper: Support deferred setup · ca91a275
    Daniel Vetter authored
    
    
    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)
    
    Cc: Liviu Dudau <liviu@dudau.co.uk>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Thierry Reding <treding@nvidia.com>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Tested-by: default avatarJohn Stultz <john.stultz@linaro.org>
    Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
    Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@intel.com>
    Reviewed-by: default avatarLiviu Dudau <liviu@dudau.co.uk>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-3-daniel.vetter@ffwll.ch
    
    
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    ca91a275