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
- DSP-based ASoC driver for SKL+ w/ DSP
- coupled-mode ASoC driver for SKL+ w/o DSP
- 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