On Fri, Apr 28, 2017 at 10:41:37AM +0200, Takashi Iwai wrote:
On Thu, 27 Apr 2017 18:02:19 +0200, ville.syrjala@linux.intel.com wrote:
From: Ville Syrjälä ville.syrjala@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@suse.de Cc: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
All look good, and feel free to take my reviewed-by tag Reviewed-by: Takashi Iwai tiwai@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.
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 ;)