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. 3 would be separate drivers for different PCI IDs so no conflict. Thanks -- ~Vinod _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
