Re: [PATCH 1/2] drm/i915: Fix audio power up sequence for gen10/11

From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>,
	tiwai@suse.de, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Fix audio power up sequence for gen10/11
Date: Wed, 2 Oct 2019 13:29:19 +0300 (EEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1910021315591.16459@zeliteleevi> (raw)
In-Reply-To: <157000938845.1880.14965368731746874502@skylake-alporthouse-com>

Hey,

On Wed, 2 Oct 2019, Chris Wilson wrote:

> > +               if (INTEL_GEN(dev_priv) == 11 || INTEL_GEN(dev_priv) == 10)
> > +                       I915_WRITE(AUD_PIN_BUF_CTL,
> > +                                  (I915_READ(AUD_PIN_BUF_CTL) |
> > +                                   AUD_PIN_BUF_ENABLE));
> 
> From the observation that this reduces the module reload time from 196s
> to 2s, I'd say this works.

yes indeed, the CI results look very promising. The problem does not occur 
every time, so this has been bugging us for a long time, but in 
scenarios and systems where this happens, the patch seems to help.

Upon further investigation, I believe this needs to be applied on GLK as 
well. This would explain some of the other sightings. E.g. here's one
from from audio/SOF CI from this week:
https://sof-ci.01.org/sofpr/PR1864/build3366/devicetest/GLK_BOB_DA7219/verify-pcm-list.sh/dmesg.txt

I'll update both patches to include GLK.

> Do you need to disable the bit later?

Now that is trickier. I'm still digging more info about this. Based on 
info I have, to avoid unsolicited wakes from i915 audio codec, we should 
clear the bit after we have turned off i915 audio power domain. In 
practise onsystems I have for testing, this results in frequent probe 
failures, so I left this out from the patch. I will try to search for more 
info on this (especially if we get still some failures with the patch).

But enabling it every time does seem to help and so far has not caused any 
regressions elsewhere, so at least this part seems good.

Br, Kai

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx