From: Thierry Reding <thierry.reding@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-samsung-soc@vger.kernel.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
intel-gfx@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/4] drm: Introduce drm_fb_helper_prepare()
Date: Wed, 23 Apr 2014 09:14:41 +0200 [thread overview]
Message-ID: <20140423071439.GA31226@ulmo> (raw)
In-Reply-To: <20140422155406.GU10722@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 2463 bytes --]
On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
[...]
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
[...]
> > @@ -502,6 +503,33 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper *helper)
> > }
> >
> > /**
> > + * drm_fb_helper_prepare - setup a drm_fb_helper structure
> > + * @dev: DRM device
> > + * @helper: driver-allocated fbdev helper structure to set up
> > + * @funcs: pointer to structure of functions associate with this helper
> > + *
> > + * Sets up the bare minimum to make the framebuffer helper usable. This is
> > + * useful to implement race-free initialization of the polling helpers. In
> > + * that case a typical sequence would be:
> > + *
> > + * - call drm_fb_helper_prepare()
> > + * - set dev->mode_config.funcs
>
> This step is done in drm_fb_helper_prepare already.
drm_fb_helper_prepare() sets fb_helper->funcs. dev->mode_config.funcs
needs to be set because it gets called by drm_kms_helper_hotplug_event()
which in turn is called by output_poll_execute(), which can be called at
any point after drm_kms_helper_poll_init(). It could be scheduled
immediately by drm_kms_helper_poll_enable().
I wonder if perhaps we should be wrapping that into a function as well.
Currently this is only documented in code by the drivers that call this.
But since it's only a single step it doesn't seem worth it. Perhaps if
we rolled the min/max_width/height into that function as well it would
be more worth it? That could be difficult to do since a couple of
drivers need to set those depending on the chipset generation.
> > + * - perform driver-specific setup
> > + * - call drm_kms_helper_poll_init()
>
> Maybe mention that after this you can start to handle hpd events using the
> probe helpers?
Isn't that somewhat implied already? The poll helpers call directly the
dev->mode_config.funcs->output_poll_changed() function, which has
already been set up earlier.
> > + * - call drm_fb_helper_init()
> > + * - call drm_fb_helper_single_add_all_connectors()
> > + * - call drm_fb_helper_initial_config()
>
> Does this list look sane in the generated DocBook? Afaik kerneldoc
> unfortunately lacks any form of markup, at least afaik :(
I must admit I didn't check. I'll make sure I do that before sending out
the next version.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] drm: Introduce drm_fb_helper_prepare()
Date: Wed, 23 Apr 2014 09:14:41 +0200 [thread overview]
Message-ID: <20140423071439.GA31226@ulmo> (raw)
In-Reply-To: <20140422155406.GU10722@phenom.ffwll.local>
On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
[...]
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
[...]
> > @@ -502,6 +503,33 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper *helper)
> > }
> >
> > /**
> > + * drm_fb_helper_prepare - setup a drm_fb_helper structure
> > + * @dev: DRM device
> > + * @helper: driver-allocated fbdev helper structure to set up
> > + * @funcs: pointer to structure of functions associate with this helper
> > + *
> > + * Sets up the bare minimum to make the framebuffer helper usable. This is
> > + * useful to implement race-free initialization of the polling helpers. In
> > + * that case a typical sequence would be:
> > + *
> > + * - call drm_fb_helper_prepare()
> > + * - set dev->mode_config.funcs
>
> This step is done in drm_fb_helper_prepare already.
drm_fb_helper_prepare() sets fb_helper->funcs. dev->mode_config.funcs
needs to be set because it gets called by drm_kms_helper_hotplug_event()
which in turn is called by output_poll_execute(), which can be called at
any point after drm_kms_helper_poll_init(). It could be scheduled
immediately by drm_kms_helper_poll_enable().
I wonder if perhaps we should be wrapping that into a function as well.
Currently this is only documented in code by the drivers that call this.
But since it's only a single step it doesn't seem worth it. Perhaps if
we rolled the min/max_width/height into that function as well it would
be more worth it? That could be difficult to do since a couple of
drivers need to set those depending on the chipset generation.
> > + * - perform driver-specific setup
> > + * - call drm_kms_helper_poll_init()
>
> Maybe mention that after this you can start to handle hpd events using the
> probe helpers?
Isn't that somewhat implied already? The poll helpers call directly the
dev->mode_config.funcs->output_poll_changed() function, which has
already been set up earlier.
> > + * - call drm_fb_helper_init()
> > + * - call drm_fb_helper_single_add_all_connectors()
> > + * - call drm_fb_helper_initial_config()
>
> Does this list look sane in the generated DocBook? Afaik kerneldoc
> unfortunately lacks any form of markup, at least afaik :(
I must admit I didn't check. I'll make sure I do that before sending out
the next version.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140423/dc7ba188/attachment.sig>
next prev parent reply other threads:[~2014-04-23 7:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 14:42 [PATCH 1/4] drm/fb-helper: Fix hpd vs. initial config races Thierry Reding
2014-04-22 14:42 ` Thierry Reding
[not found] ` <1398177741-28482-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-22 14:42 ` [PATCH 2/4] drm: Constify struct drm_fb_helper_funcs Thierry Reding
2014-04-22 14:42 ` Thierry Reding
2014-04-22 15:39 ` Daniel Vetter
2014-04-22 15:39 ` Daniel Vetter
2014-04-22 14:42 ` [PATCH 3/4] drm: Introduce drm_fb_helper_prepare() Thierry Reding
2014-04-22 14:42 ` Thierry Reding
2014-04-22 15:54 ` Daniel Vetter
2014-04-22 15:54 ` Daniel Vetter
2014-04-23 7:14 ` Thierry Reding [this message]
2014-04-23 7:14 ` Thierry Reding
2014-04-23 7:35 ` Daniel Vetter
2014-04-23 7:35 ` Daniel Vetter
2014-04-23 13:44 ` Thierry Reding
2014-04-23 13:44 ` Thierry Reding
2014-04-23 13:40 ` [PATCH] " Thierry Reding
2014-04-23 14:24 ` Daniel Vetter
2014-04-22 14:42 ` [PATCH 4/4] drm/tegra: Implement race-free hotplug detection Thierry Reding
2014-04-22 14:42 ` Thierry Reding
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140423071439.GA31226@ulmo \
--to=thierry.reding@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.