[alsa-devel] [RFC 00/10] Enable HDA Codec support on Intel Platforms (Series2)

[Takashi Iwai]

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