All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: intel-gfx@lists.freedesktop.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe
Date: Wed, 26 Apr 2017 16:38:53 +0300	[thread overview]
Message-ID: <20170426133853.GT30290@intel.com> (raw)
In-Reply-To: <s5hpofzfwz5.wl-tiwai@suse.de>

On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> On Tue, 25 Apr 2017 22:27:19 +0200,
> ville.syrjala@linux.intel.com wrote:
> > 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > I was wondering why my VLV no longer runtime suspended, and after some
> > thinking I decided it had to be the LPE audio preventing it. Turns out
> > I was right, so here's my attempt at fixing it.
> > 
> > And while looking at the code I couldn't help but notice that it
> > couldn't actually handle multiple pipes playing back audio at the
> > same time. And even having multiple displays active even if only
> > one was playing audio was probably a recipe for failure. So I
> > tried to fix that by registering a separate PCM device for each
> > pipe.
> > 
> > Note that the patch subjects may not reflect the subsystem
> > very well since most of these straddle the border between drm
> > and alsa. I think I just slapped on drm/i915 to most where
> > there was no clear winner.
> 
> A nice patchset, thanks for working on it!
> 
> One slight concern (other than the jack issue Pierre reported) is the
> incompatible behavior from the current version.  With the pipe-based
> multiple streams, user would need to choose another one even if the
> device has a single HDMI output, which is pretty common on BYT/CHV
> tablets.
> 
> Maybe it's no big problem as the users are still limited at the
> moment.  Or, we may need to handle a bit differently, e.g. assigning
> the PCM stream dynamically per hotplug.

Yeah, I tied the PCM device to the pipe to match the hardware. But we
could certainly register the PCM device per port, and then do a 
pipe<->port mapping somewhere to make it all work out. One slight
complication is that not all ports are necessarily present so we
might have eg. just port B and port D, but no port C. Not sure if
it would be a bad thing to register a PCM device even for the
missing ports anyway?

I don't recall which way HDA works. Device per port I guess? Well,
for DP SST/HDMI. But for DP MST I presume it's device per stream
(ie. pipe) even with HDA.

> In anyway, with the support of multi streams, alsa-lib config needs to
> be updated.

Hmm. I suppose I'll have to take a gander at what's there.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-04-26 13:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-25 20:27 [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe ville.syrjala
2017-04-25 20:27 ` [PATCH 01/11] drm/i915: Fix runtime PM for LPE audio ville.syrjala
2017-04-25 20:27 ` [PATCH 02/11] ALSA: x86: Clear the pdata.notify_lpe_audio pointer before teardown ville.syrjala
2017-04-25 20:27 ` [PATCH 03/11] drm/i915: Stop pretending to mask/unmask LPE audio interrupts ville.syrjala
2017-04-26  0:27   ` Pierre-Louis Bossart
2017-04-26 13:27     ` Ville Syrjälä
2017-04-25 20:27 ` [PATCH 04/11] drm/i915: Remove the unsued pending_notify from LPE platform data ville.syrjala
2017-04-25 20:27 ` [PATCH 05/11] drm/i915: Replace tmds_clock_speed and link_rate with just ls_clock ville.syrjala
2017-04-26  1:09   ` [alsa-devel] " Pierre-Louis Bossart
2017-04-26 13:28     ` Ville Syrjälä
2017-04-25 20:27 ` [PATCH 06/11] drm/i915: Remove hdmi_connected from LPE audio pdata ville.syrjala
2017-04-25 20:27 ` [PATCH 07/11] drm/i915: Reorganize intel_lpe_audio_notify() arguments ville.syrjala
2017-04-25 20:27 ` [PATCH 08/11] drm/i915: Clean up the LPE audio platform data ville.syrjala
2017-04-25 20:27 ` [PATCH 09/11] ALSA: x86: Prepare LPE audio ctls for multiple PCMs ville.syrjala
2017-04-25 20:27 ` [PATCH 10/11] ALSA: x86: Split snd_intelhad into card and PCM specific structures ville.syrjala
2017-04-25 20:27 ` [PATCH 11/11] ALSA: x86: Register multiple PCM devices for the LPE audio card ville.syrjala
2017-04-26  1:58   ` Pierre-Louis Bossart
2017-04-26  7:04     ` [alsa-devel] " Takashi Iwai
2017-04-26  7:19       ` Takashi Iwai
2017-04-26 13:49         ` Ville Syrjälä
2017-04-26 14:04           ` Takashi Iwai
2017-04-25 20:46 ` ✓ Fi.CI.BAT: success for drm/i915: LPE audio runtime PM and multipipe Patchwork
2017-04-26  7:29 ` [PATCH 00/11] " Takashi Iwai
2017-04-26 13:38   ` Ville Syrjälä [this message]
2017-04-26 13:47     ` Takashi Iwai
2017-04-26 13:56       ` Ville Syrjälä
2017-04-26 19:59       ` Ville Syrjälä

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=20170426133853.GT30290@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tiwai@suse.de \
    /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.