Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Egbert Eich <eich@suse.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 12:09:59 +0100	[thread overview]
Message-ID: <21620.25479.784241.113086@linux-qknr.fritz.box> (raw)
In-Reply-To: daniel@ffwll.ch wrote on Monday, 24 November 2014 at 20:46:22 +0100

Daniel Vetter writes:
 > 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.
 
No. edp_panel_vdd_off() calls edp_panel_vdd_schedule_off() when not called
with sync == true. edp_panel_vdd_schedule_off() calls schedule_delayed_work()
which doesn't reschedule pending work.

 > 
 > 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, I came across this when I was looking for the problem in fdo#86201.
And I agree, it is not strictly needed, however if you follow
fdo#86201 you will see a list of calls to edp_panel_vdd_off_sync()
soon to be followed by calls to edp_panel_vdd_on(). Many of them are 
unnecessary and can be gotten rid of the uneeded ones by canelling the work 
queue. (When you follow fdo#86201 you will see why there was an abnormal
situation and what caused it). 
Of course due to the locking we already have serialization and canelling 
pending workers did not resolve the issue but it at least got rid of some
unneeded overhead.

Cheers,
	Egbert.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      parent reply	other threads:[~2014-11-25 11:10 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ä
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   ` Egbert Eich [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=21620.25479.784241.113086@linux-qknr.fritz.box \
    --to=eich@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox