Re: [RFC 00/10] Enable HDA Codec support on Intel Platforms (Series2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux