On Fri, 01 Dec 2017 20:45:54 +0100, Pierre-Louis Bossart wrote: > > On 12/1/17 8:56 AM, Takashi Iwai wrote: > > 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... > > > > > >> 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. > > > > > >> 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. > > > > 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. > > Before going into codec support, should we first deal with the > selection of the ASoC/Legacy mode for the controller side of things? > Even with basic HDMI/iDisp cases, we don't have a clean solution > today. When I worked on the late Joule platform, there was no fallback > mode which forced a recompilation depending on BIOS settings. > My understanding is that there is no support for multiple drivers > registering for the same PCI ID, I believe we'll have to define a > top-level wrapper which arbitrates internally based on BIOS settings > and user/distro preferences which mode is selected. True, we need to sort out that. But the selection of the card-level driver can be relatively easily done in a manual way, either via blacklisting or by common module options. Currently AMDGPU and radeon drivers are in such situation, for example. A common single switch, or at best the automatic arbitration would be preferred, of course, though. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
