>-----Original Message----- >From: Takashi Iwai [mailto:tiwai@xxxxxxx] >Sent: Friday, December 1, 2017 8:26 PM >To: Ughreja, Rakesh A <rakesh.a.ughreja@xxxxxxxxx> >Cc: alsa-devel@xxxxxxxxxxxxxxxx; broonie@xxxxxxxxxx; >liam.r.girdwood@xxxxxxxxxxxxxxx; pierre-louis.bossart@xxxxxxxxxxxxxxx; Koul, >Vinod <vinod.koul@xxxxxxxxx>; Patches Audio <patches.audio@xxxxxxxxx> >Subject: Re: [RFC 00/10] Enable HDA Codec support on Intel Platforms >(Series2) > >On Fri, 01 Dec 2017 10:13:58 +0100, >Rakesh Ughreja wrote: >> >> Many Intel platforms (SKL,KBL) etc. in the market supports enahanced >> audio capabilities which also includes DSP processing. This patch carry >> forwads the works that is done in the previous series to enable HD Audio >> codecs on such platforms. >> >> This patch series adds ASoC HDA codec driver for Intel platforms. It is >> written by reusing the legacy HDA ALSA codec driver. Intention is to >> maximize the reuse and minimize the changes in the legacy HDA codec >driver. >> >> I would like to receive feedback before proceeding further on this >> direction. > >First of all, I appreciate this kind of work finally happening, so >that ASoC HD-audio can go forward to a wider usage. However... Thank you for encouragement and prompt feedback. > > >> TODO: >> >> - This series is tested on KBL based product (Dell XPS 13). >> - Basic playback is working with headset and speakers. >> - Capture operation is not tested. >> - More platforms and use cases coverage can be added once we have basic >> agreement in terms of the overall approach. > >One big thing that is unclear to me is what about the complex I/O >configuration although we provide only a single machine driver, and >what happens if the (legacy) codec driver allows the jack retasking. >I know that nowadays the number of jacks are reduced than before, but >still there will be desktop boxes with individual front and rear I/O >jacks. At this point of time, I was thinking that we should have a single machine Driver with machine specific changes, possibly with quicks or DMIs or anything which works. Single machine driver is for a case when we have one HDA codec and one iDisp (HDMI/DP) codec. When we have other peripherals e.g. SoC DMICs or I2S codecs in addition to HDA codec, we should have another machine driver. > > >> FIXME: >> - KConfig changes does not look right, but I could not think of any proper >> way without making changes into legacy HDA codec driver. So need some >> help on this topic. > >And this is another big issue. As long as you don't allow build both, >it never flies with distros, and it means no dramatic improvement of >the situation, either. Yes, I agree. At the moment I didn't want to do any changes in the codec driver. Now I got your attention and so we will have a better solution. > >IOW, we have to make the codec driver working on both controller/bus >implementations, and it essentially means to rewrite the HD-audio >codec plumbing code. Currently, it's a kind of half-baked state, and >we need to cast to unified form. Yes, exactly, if we make some changes in the legacy codec driver we can solve this problem. But I didn't want to do it without understanding your thinking process. That's why I just kept it as open in the current series. Regards, Rakesh _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
