[Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe

[Takashi Iwai]

On Wed, 26 Apr 2017 15:38:53 +0200,
Ville Syrjälä wrote:
> 
> On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > On Tue, 25 Apr 2017 22:27:19 +0200,
> > ville.syrjala at linux.intel.com wrote:
> > > 
> > > From: Ville Syrjälä <ville.syrjala at 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.

HD-audio creates the PCM device per HD-audio widget representation,
and they correspond to ports, as it seems.  For MST, the situation is
more complex, and we assign the PCM stream dynamically.  It's for
keeping the behavior (more or less) consistent with non-MST.

> > 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.

The HDMI PCM definition itself is easy, just just adding more (hdmi.1,
hdmi.2, etc).  The difficult part would be the front and the default
PCM definition, and I have no good idea about it, so far.


Takashi