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

[Takashi Iwai]

On Wed, 03 May 2017 15:39:06 +0200,
Ville Syrjälä wrote:
> 
> On Fri, Apr 28, 2017 at 10:41:37AM +0200, Takashi Iwai wrote:
> > On Thu, 27 Apr 2017 18:02:19 +0200,
> > ville.syrjala at linux.intel.com wrote:
> > > 
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > Okay, here's the second attempt at getting multiple pipes playing back
> > > audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
> > > that now the PCM devices are associated with ports instead of pipes,
> > > so the audio from one device always gets output on the same display.
> > > 
> > > I've also tacked on the alsa-lib conf update. No clue whether it's
> > > really correct or not (the config language isn't a close friend
> > > of mine).
> > > 
> > > BTW I did notice that with LPE audio all the controls say iface=PCM,
> > > whereas on HDA a bunch of them say iface=MIXER. No idea if that's
> > > OK or not, just something I spotted when I was comparing the results
> > > with HDA.
> > 
> > We generally accept both iface types for IEC958 stuff, since
> > historically many drivers have already mixed them up.  So it's no
> > problem :)
> > 
> > 
> > > Entire series available here:
> > > git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2
> > > 
> > > Cc: Takashi Iwai <tiwai at suse.de>
> > > Cc: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>
> > 
> > All look good, and feel free to take my reviewed-by tag
> >   Reviewed-by: Takashi Iwai <tiwai at suse.de>
> 
> Thanks.
> 
> > 
> > As said previously, my only slight concern is the compatibility.
> > But, in the current situation with PulseAudio, only few people would
> > use this driver, so it shouldn't be so big impact, I suppose.
> 
> What will break? Or you mean the alsa-lib vs. kernel difference
> until they sync up? I don't use pulse myself so I don't know really
> what it wants.

Yes, the alsa-lib stuff is one thing.  Another thing is that it'll
change the behavior, for example, when you used to invoke a command
without PA.  It might not work any longer as is because now you'll
have multiple PCM devices and the attached device might be not the
first one.

PA would be possible to choose the rightly connected PCM stream, so
it's fine for PA.  But the "current situation" I mentioned above is
about PA getting killed at startup when LPE-audio and other drivers
are running.  So, for most people, LPE-audio will be blacklisted until
PA gets fixed, or it's worked around by changing PA config.  In
anyway, the driver should be still minor at this moment, so we may
give some excuse for changing.


> > BTW, which port is used in general on BYT/CHT?
> 
> There's no clear rule I think. But I suppose most manufacturers
> follow some reference design, so there could be some layouts
> that are more common than other. Having HDMI on port D on CHV
> is a fairly common design I've seen. And I think all the
> pre-production RVP boards had eDP on port C, so that could also
> be how production boards tend to be wired up.
> 
> > Oh, also, I suppose you want to carry these over i915 tree?
> > I don't mind either way, I can take them through sound tree if
> > preferred, too.
> 
> Cool. I just pushed the lot to drm-intel-next-queued. I'm
> thinking going via dinq might avoid some conflicts later on
> if we end up churning the code some more. And we do like to
> churn ;)

Have fun :)


thanks,

Takashi