Re: [alsa-devel] No sound since 5.4 on skl_n88l25_s4567

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

>> a) remove the error handling after soc_dapm_add_routes() to be
>> backwards compatible with Intel problematic machine drivers. Not
>> really nice for everyone else.
>>
>> b) remove this error conditionally so that legacy Intel solutions
>> still work but new ones deal with errors upfront.
>>
>> I am not sure if there's a 'clean' way to implement b), maybe with a
>> Kconfig selected by some machine drivers? Morimito-san, any
>> suggestions now that we've root caused the problem (copied again below
>> for reference)?
> 
> Is it possible to *real* fixup in the future, some day ?

Quite unlikely I am afraid. This is a mismatch between topology and 
machine driver, and there are no planned updates of those topologies 
(which were never released for upstream use).

In this case I guess the topology file was taken from a ChromeOS 
distribution (based on v4.4 IIRC), so there's really no guarantee that a 
fix would ever reach the user without a convoluted set of manual updates.

> We need correct code, but backward compatibility is also needed.
> Not only Intel but some machine might have similar issue,
> so, how about to indicate WARNING, and comment ?
> 
> Like this
> 
>           ret = snd_soc_dapm_add_routes(dapm,
>                                         component->driver->dapm_routes,
>                                         component->driver->num_dapm_routes);
>          if (ret < 0)
>   -               goto err_probe;
>   +               /*
>   +                * This is error, but legacy Intel want
>   +                * compatibility until xxxx.
>   +                * call "goto err_probe" after that
>   +                */
>   +               dev_warn(dev, "DAPM route add failed.")

we already had a warning before:

[   22.364318] skl_n88l25_s4567 skl_n88l25_s4567: ASoC: Failed to add 
route iDisp3_out -> direct -> iDisp3 Tx

and it was ignored since there was no functional impact....

Maybe we could have some sort of boolean flag in the component->driver 
definition and explicitly request a backwards-compatible behavior (e.g. 
for all SKL/KBL machine drivers) when that driver is known to be flaky. 
There's already things like 'fully_routed', maybe we can add something 
such as 'disable_route_check'?
		
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel