From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Egbert Eich <eich@suse.de>, intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/eDP: When enabling panel VDD cancel pending disable worker
Date: Tue, 25 Nov 2014 10:43:17 +0200 [thread overview]
Message-ID: <20141125084317.GM10649@intel.com> (raw)
In-Reply-To: <CAKMK7uGhBcdmfTYouY3=91y8cHu8MgEp-D-oewSic3v2PeLUuA@mail.gmail.com>
On Mon, Nov 24, 2014 at 08:46:22PM +0100, Daniel Vetter wrote:
> On Mon, Nov 24, 2014 at 5:56 PM, Egbert Eich <eich@suse.de> wrote:
> > Before testing if the panel VDD is enabled on eDP cancel any pending
> > disable worker. This makes sure the worker doesn't fire when we expect
> > VDD to be enabled.
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=86201
> >
> > Signed-off-by: Egbert Eich <eich@suse.de>
>
> This shouldn't be needed at all:
> - The vdd off rechecks ->want_panel_vdd under the pps lock.
> - The off function sets that and also reschedules the work (to make
> sure it doesn't kill vdd to early) again all under the same lock.
It uses schedule_delayed_work() which does nothing if the work is
already pending. Hence the delay will be counted from the first vdd_off,
not the last one.
But doing the cancel up front instead of using mod_delayed_work() has
the extra benefit of making it a bit less likely vdd will get turned off
if the transfer of a single AUX message takes longer than the vdd off
delay.
However even with the cancel it'ss still possible the vdd off work already
started executing (but is blocked by pps_mutex) by the time we call
edp_panel_vdd_on(), in which case vdd would still be turned off as soon
as pps_mutex is released. We could track the last time vdd was used
to avoid that, but I'm not sure it's really worth the extra effort.
>
> So no one can sneak in and the work racing with us isn't an issue. Or
> shouldn't be at least. So if this helps we need to dig a bit deeper.
> -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
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-11-25 8:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 16:56 [PATCH] drm/i915/eDP: When enabling panel VDD cancel pending disable worker Egbert Eich
2014-11-24 17:32 ` Ville Syrjälä
2014-11-24 17:44 ` Ville Syrjälä
2014-11-24 19:04 ` Egbert Eich
2014-11-24 19:46 ` Daniel Vetter
2014-11-25 8:43 ` Ville Syrjälä [this message]
2014-11-25 8:52 ` Daniel Vetter
2014-11-25 11:54 ` [PATCH v2] " Egbert Eich
2014-11-25 13:07 ` Daniel Vetter
2014-11-25 11:09 ` [PATCH] " Egbert Eich
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=20141125084317.GM10649@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=eich@suse.de \
--cc=intel-gfx@lists.freedesktop.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.