From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/i915: Move the fbdev async_schedule() into intel_fbdev.c
Date: Wed, 11 Nov 2015 13:46:25 +0200 [thread overview]
Message-ID: <20151111114625.GJ4437@intel.com> (raw)
In-Reply-To: <20151110162755.GA23035@wunner.de>
On Tue, Nov 10, 2015 at 05:27:55PM +0100, Lukas Wunner wrote:
> Hi Ville,
>
> On Mon, Nov 09, 2015 at 01:00:50PM +0200, Ville Syrjälä wrote:
> > On Sun, Nov 08, 2015 at 05:44:37PM +0100, Lukas Wunner wrote:
> > > Hi Ville,
> > >
> > > On Fri, Nov 06, 2015 at 03:08:33PM +0200, ville.syrjala@linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > Reading the driver load/unload code leaves one confused as there's
> > > > an async_schedule() in the load, but not async_synchronize_full()
> > > > in sight. In fact it's hidden inside intel_fbdev.c. So let's move the
> > > > async_schedule() into intel_fbdev.c as well so that it's next to the
> > > > async_synchronize_full(), which should make the relationship easier
> > > > to see.
> > >
> > > Hm, what do you think about solving it the other way round, i.e. moving
> > > the async_synchronize_full() to i915_driver_unload()? Incidentally I was
> > > working on this same part of the code and that's how I solved it. This way
> > > it's possible to call intel_fbdev_fini() from intel_fbdev_initial_config().
> > > With your solution this would deadlock.
> > >
> > > Link: https://github.com/l1k/linux/commit/aa12badac846
> > > Message-Id: <aa12badac846f24b49d83768146b62e2ac159eb3.1446987413.git.lukas@wunner.de>
> > >
> >
> > I think I'd still like to hide it all in intel_fbdev.c. You could just
> > split the fbdev_fini() into two parts; one doing the real work, and the
> > second one just doing async_synchronize + call the first one.
>
> Looking at this with a fresh pair of eyeballs I realized I could simply
> call async_synchronize_full() conditionally if (!current_is_async()),
> thereby differentiating between fbdev_fini() being called from
> i915_driver_unload() versus intel_fbdev_initial_config().
> If your patch gets pushed, I think I'll rebase and solve it like that.
OK.
Series pushed to dinq. Thanks for the reviews.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2015-11-11 11:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-06 13:08 [PATCH 0/3] drm/i915: Module unload fixes ville.syrjala
2015-11-06 13:08 ` [PATCH 1/3] drm/i915: Kill intel_runtime_pm_disable() ville.syrjala
2015-11-10 17:20 ` Jesse Barnes
2015-11-10 23:49 ` Rafael J. Wysocki
2015-11-06 13:08 ` [PATCH 2/3] drm/i915: Do fbdev fini first during unload ville.syrjala
2015-11-06 13:33 ` Chris Wilson
2015-11-06 14:16 ` Ville Syrjälä
2015-11-06 13:08 ` [PATCH 3/3] drm/i915: Move the fbdev async_schedule() into intel_fbdev.c ville.syrjala
2015-11-06 13:30 ` Chris Wilson
2015-11-06 17:04 ` Jesse Barnes
2015-11-08 16:44 ` Lukas Wunner
2015-11-09 11:00 ` Ville Syrjälä
2015-11-10 16:27 ` Lukas Wunner
2015-11-11 11:46 ` Ville Syrjälä [this message]
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=20151111114625.GJ4437@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lukas@wunner.de \
/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.