Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: "Rojewski, Cezary" <cezary.rojewski@intel.com>,
	intel-gfx@lists.freedesktop.org,
	"moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..." <alsa-devel@alsa-project.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: Timing issues between ALSA and i915 drivers
Date: Wed, 16 Jan 2019 20:17:56 +0100	[thread overview]
Message-ID: <s5hef9ce7iz.wl-tiwai@suse.de> (raw)
In-Reply-To: <045cfacd-7a8a-af3c-0f82-325b12cf65da@linux.intel.com>

On Wed, 16 Jan 2019 18:48:25 +0100,
Pierre-Louis Bossart wrote:
> 
> Hi,
> 
> I could use some feedback on HDMI audio issues exposed during the 4.21
> merge window. By accident (misleading documentation) we ended up
> enabling the Skylake driver instead of the HDaudio legacy, and broke
> audio on a number of Skylake and ApolloLake devices where the
> HDMI/iDISP codec was not detected (bit 2 not set in the
> codec_mask). Linus' Dell XPS13 9350 was the first to be impacted of
> course...
> 
> After debugging a bit, this issue can be resolved by either
> 
> a) compiling both SOUND and DRM as built-ins (y instead of m)
> 
> b) moving the calls snd_hdac_i915_init() to the probe function instead
> of the worker queue (code at
> https://github.com/plbossart/sound/commits/fix/skl-hdmi)

This isn't guaranteed to work, as request_module() might be involved,
I'm afraid.

> Both solutions point to timing issues.
> 
> During internal reviews I was alerted to the fact that the suggested
> fix essentially reverts patch ab1b732d53c18 ('ASoC: Intel: Skylake:
> Move i915 registration to worker thread') which was introduced to
> solve DRM lockup issues.
> 
> In other words, we are at a point where we either have DRM lockups or
> can't detect the HDMI audio codec, none of which are too good.
> 
> I don't have the background for the DRM lockup stuff, nor do I
> understand why snd_hdac_i915_init has to be called from a thread
> context. Is this really a requirement?
> 
> I also don't get what sort of timing issues would come from an
> initialization. What happens on the i915 side and is there some sort
> of mandatory delay between the completion of the i915_init and issuing
> a snd_hdac_chip_readw(bus, STATESTS) to get the codec masks on the
> HDaudio links?

snd_hdac_i915_init() waits for the binding with the i915 audio
component, so a possible solution would be just to delay the audio
component registration at the really last stage, like the change
below.

If this still doesn't work, it'll be more deeply inside, and I have
little clue for now...


thanks,

Takashi

---
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1577,8 +1577,6 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 	if (IS_GEN5(dev_priv))
 		intel_gpu_ips_init(dev_priv);
 
-	intel_audio_init(dev_priv);
-
 	/*
 	 * Some ports require correctly set-up hpd registers for detection to
 	 * work properly (leading to ghost connected connector status), e.g. VGA
@@ -1597,6 +1595,8 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 
 	intel_power_domains_enable(dev_priv);
 	intel_runtime_pm_enable(dev_priv);
+
+	intel_audio_init(dev_priv);
 }
 
 /**
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-01-16 19:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 17:48 Timing issues between ALSA and i915 drivers Pierre-Louis Bossart
2019-01-16 19:17 ` Takashi Iwai [this message]
2019-01-16 23:10   ` Pierre-Louis Bossart
2019-01-17  0:13     ` [alsa-devel] " Pierre-Louis Bossart
2019-01-17 19:53 ` Pierre-Louis Bossart
2019-01-17 20:31   ` Takashi Iwai
2019-01-17 20:47     ` Pierre-Louis Bossart
2019-01-18  8:08       ` Takashi Iwai

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=s5hef9ce7iz.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    /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