Re: [Intel-gfx] [PATCH] drm/fb-helper: Support deferred setup
On Thu, Jun 29, 2017 at 12:59 PM, Maarten Lankhorst
wrote:
>> @@ -2538,6 +2563,12 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
>> *fb_helper)
>> return 0;
>>
>> mutex_lock(&fb_helper->lock);
>> + if (fb_helper->deferred_setup) {
>> + err = __drm_fb_helper_initial_config(fb_helper,
>> + fb_helper->preferred_bpp);
> Maybe rename this function to *_and_unlock? I had to read this code twice to
> make sure it works as intended. :)
If this is the official suffix for trickery like this I can do - I
already asked on irc what it should be called :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/fb-helper: Support deferred setup
Op 28-06-17 om 13:32 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).
>
> Cc: Liviu Dudau
> Cc: John Stultz
> Cc: Thierry Reding (v1)
> Tested-by: John Stultz
> Signed-off-by: Thierry Reding (v1)
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 101
> ++--
> include/drm/drm_fb_helper.h | 23 +
> 2 files changed, 89 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index bbd4c6d0378d..e49bae10f0ee 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -521,6 +521,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
> drm_fb_helper *fb_helper)
> if (!drm_fbdev_emulation)
> return -ENODEV;
>
> + if (READ_ONCE(fb_helper->deferred_setup))
> + return 0;
> +
> mutex_lock(&fb_helper->lock);
> ret = restore_fbdev_mode(fb_helper);
>
> @@ -1695,8 +1698,7 @@ EXPORT_SYMBOL(drm_fb_helper_pan_display);
>
> /*
> * Allocates the backing storage and sets up the fbdev info structure through
> - * the ->fb_probe callback and then registers the fbdev and sets up the panic
> - * notifier.
> + * the ->fb_probe callback.
> */
> static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
>int preferred_bpp)
> @@ -1794,13 +1796,8 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> }
>
> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
> - /*
> - * hmm everyone went away - assume VGA cable just fell out
> - * and will come back later.
> - */
> - DRM_INFO("Cannot find any crtc or sizes - going 1024x768\n");
> - sizes.fb_width = sizes.surface_width = 1024;
> - sizes.fb_height = sizes.surface_height = 768;
> + DRM_INFO("Cannot find any crtc or sizes\n");
> + return -EAGAIN;
> }
>
> /* Handle our overallocation */
> @@ -2429,6 +2426,58 @@ static void drm_setup_crtcs(struct drm_fb_helper
> *fb_helper,
> kfree(enabled);
> }
>
> +/* Note: Drops fb_helper->lock before returning. */
> +static int __drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper,
> + int bpp_sel)
> +{
> + struct drm_device *dev = fb_helper->dev;
> + struct fb_info *info;
> + unsigned int width, height;
> + int ret;
> +
> + width = dev->mode_config.max_width;
> + height = dev->mode_config.max_height;
> +
> + drm_setup_crtcs(fb_helper, width, height);
> + ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
> + if (ret < 0) {
> + if (ret == -EAGAIN) {
> + fb_helper->preferred_bpp = bpp_sel;
> + fb_hel
Re: [Intel-gfx] [PATCH] drm/fb-helper: Support deferred setup
On Wed, Jun 28, 2017 at 01:32:01PM +0200, Daniel Vetter wrote:
> 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).
>
> Cc: Liviu Dudau
> Cc: John Stultz
> Cc: Thierry Reding (v1)
> Tested-by: John Stultz
> Signed-off-by: Thierry Reding (v1)
> Signed-off-by: Daniel Vetter
Tested-by: Liviu Dudau
I'm going through the debugging on the deferred setup on first monitor connect,
as that seems to not do a full modeset, but that might turn out a bug in my
driver.
> ---
> drivers/gpu/drm/drm_fb_helper.c | 101
> ++--
> include/drm/drm_fb_helper.h | 23 +
> 2 files changed, 89 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index bbd4c6d0378d..e49bae10f0ee 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -521,6 +521,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
> drm_fb_helper *fb_helper)
> if (!drm_fbdev_emulation)
> return -ENODEV;
>
> + if (READ_ONCE(fb_helper->deferred_setup))
> + return 0;
> +
> mutex_lock(&fb_helper->lock);
> ret = restore_fbdev_mode(fb_helper);
>
> @@ -1695,8 +1698,7 @@ EXPORT_SYMBOL(drm_fb_helper_pan_display);
>
> /*
> * Allocates the backing storage and sets up the fbdev info structure through
> - * the ->fb_probe callback and then registers the fbdev and sets up the panic
> - * notifier.
> + * the ->fb_probe callback.
> */
> static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
>int preferred_bpp)
> @@ -1794,13 +1796,8 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> }
>
> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
> - /*
> - * hmm everyone went away - assume VGA cable just fell out
> - * and will come back later.
> - */
> - DRM_INFO("Cannot find any crtc or sizes - going 1024x768\n");
> - sizes.fb_width = sizes.surface_width = 1024;
> - sizes.fb_height = sizes.surface_height = 768;
> + DRM_INFO("Cannot find any crtc or sizes\n");
> + return -EAGAIN;
> }
>
> /* Handle our overallocation */
> @@ -2429,6 +2426,58 @@ static void drm_setup_crtcs(struct drm_fb_helper
> *fb_helper,
> kfree(enabled);
> }
>
> +/* Note: Drops fb_helper->lock before returning. */
> +static int __drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper,
> + int bpp_sel)
> +{
> + struct drm_device *dev = fb_helper->dev;
> + struct fb_info *info;
> + unsigned int width, height;
> + int ret;
> +
> + width = dev->mode_config.max_width;
> + height = dev->mode_config.max_height;
> +
> + drm_setup_crtcs(fb_helper, width, heigh
