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

[Pierre-Louis Bossart]

On 12/3/17 10:21 PM, Vinod Koul wrote:
> On Sun, Dec 03, 2017 at 09:44:56PM -0600, Pierre-Louis Bossart wrote:
>> On 12/3/17 9:22 PM, Vinod Koul wrote:
>>> On Sun, Dec 03, 2017 at 09:15:21PM -0600, Pierre-Louis Bossart wrote:
>>>> On 12/3/17 11:20 AM, Vinod Koul wrote:
>>>>> On Fri, Dec 01, 2017 at 09:03:25PM +0100, Takashi Iwai wrote:
>>>>>>>>> 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.
>>>>>
>>>>> The switch is again short term as we should progress and move towards one
>>>>> solution whilst deprecating the other, so that way this makes a simple
>>>>> solution and helps in transition, change flag defaults and deprecate.
>>>>
>>>> Sorry, I don't get your point. Are you saying the legacy would be
>>>> deprecated? that was never my understanding, Rakesh's patches only make it
>>>> easier to use the DSP in combination with an HDaudio codec, but if the DSP
>>>> is not present the legacy is the fallback, no?
>>>
>>> for now yes, but what prevents us from supporting coupled mode when DSP is
>>> disabled :)
>>
>> That gets complicated. you'd have
>> 1. DSP-based ASoC driver for SKL+ w/ DSP
>> 2. coupled-mode ASoC driver for SKL+ w/o DSP
>> 3. legacy for pre-SKL platforms.
>>
>> I don't see what simplification this brings, it's complicated enough with 1.
>> and 3, and legacy is not going away.
> 
> in long term we _need_ to converge. 1 and 2 should be same driver detecting
> presence of DSP dynamically and doing DSP based or coupled mode.

Did we ever enable the coupled mode? if not then it's an hypothetical 
direction...

> 
> 3 would be separate drivers for different PCI IDs so no conflict.
> 
> Thanks
>