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

[Ughreja, Rakesh A]

>-----Original Message-----
>From: Takashi Iwai [mailto:tiwai at suse.de]
>Sent: Friday, December 1, 2017 8:26 PM
>To: Ughreja, Rakesh A <rakesh.a.ughreja at intel.com>
>Cc: alsa-devel at alsa-project.org; broonie at kernel.org;
>liam.r.girdwood at linux.intel.com; pierre-louis.bossart at linux.intel.com; Koul,
>Vinod <vinod.koul at intel.com>; Patches Audio <patches.audio at intel.com>
>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