From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/i915: move power domain init earlier during system resume
Date: Tue, 01 Apr 2014 21:50:43 +0300 [thread overview]
Message-ID: <1396378243.2488.10.camel@ideak-mobl> (raw)
In-Reply-To: <20140401174827.GO22327@phenom.ffwll.local>
On Tue, 2014-04-01 at 19:48 +0200, Daniel Vetter wrote:
> On Tue, Apr 01, 2014 at 07:55:22PM +0300, Imre Deak wrote:
> > During resume the intel hda audio driver depends on the i915 driver
> > reinitializing the audio power domain. Since the order of calling the
> > i915 resume handler wrt. that of the audio driver is not guaranteed,
> > move the power domain reinitialization step to the resume_early
> > handler. This is guaranteed to run before the resume handler of any
> > other driver.
> >
> > The power domain initialization in turn requires us to enable the i915
> > pci device first, so move that part earlier too.
> >
> > Accordingly disabling of the i915 pci device should happen after the
> > audio suspend handler ran. So move the disabling later from the i915
> > resume handler to the resume_late handler.
> >
> > v2:
> > - move intel_uncore_sanitize/early_sanitize earlier too, so they don't
> > get reordered wrt. intel_power_domains_init_hw()
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
>
> So this is kinda why we should have gone with something proper, like a new
> hdmi sink platform device created by i915 and registered as a driver by
> snd-hda. Then the power domains stuff in the device core should take care
> of these kinds of ordering issues. Or at least snd-hda can tell it that it
> needs to wait for the hdmi-sink power domain to go on first before it can
> resume, I'm not really fluent on the details here.
>
> And having a hdmi sink bus would allow us to throw all kinds of crap into
> a clearly-defined interface, e.g. eld handling, hdcp synchronization, hpd
> forwarding and all the other fun stuff.
>
> So not sure what I should do with this here now.
Right, I'm not too happy about this solution either, so if anything it
could be considered only a stop-gap fix. What you suggest seems to be a
cleaner way but it'd require more time to investigate/implement at least
on my part (but I'm ok to put it on my TODO list).
--Imre
next prev parent reply other threads:[~2014-04-01 19:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 10:10 [PATCH] drm/i915: move power domain init earlier during system resume Imre Deak
2014-04-01 16:55 ` [PATCH v2] " Imre Deak
2014-04-01 17:48 ` Daniel Vetter
2014-04-01 18:50 ` Imre Deak [this message]
2014-04-01 20:26 ` Daniel Vetter
2014-04-02 12:59 ` [Intel-gfx] " Takashi Iwai
2014-04-03 15:23 ` Daniel Vetter
2014-04-03 15:31 ` Takashi Iwai
2014-04-03 21:06 ` Daniel Vetter
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=1396378243.2488.10.camel@ideak-mobl \
--to=imre.deak@intel.com \
--cc=daniel@ffwll.ch \
--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