On Fri, Apr 28, 2017 at 10:41:37AM +0200, Takashi Iwai wrote: > On Thu, 27 Apr 2017 18:02:19 +0200, > ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > 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@xxxxxxx> > > Cc: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > > All look good, and feel free to take my reviewed-by tag > Reviewed-by: Takashi Iwai <tiwai@xxxxxxx> 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 ;) -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
