[alsa-devel] [PATCH 1/2][RFC] ASoC: soc-core: allow no Platform on dai_link

[Pierre-Louis Bossart]

On 1/30/19 7:46 PM, Kuninori Morimoto wrote:
> Hi Pierre-Louis
>
>>> If sound card dirver is using "modern style", both codec/platform
>>> are using it. So this patch judges it as "modern style" if
>>> there is no settings for
>>> 	codec_name
>>> 	codec_of_node
>>> 	codec_dai_name
>>> 	platform_name
>>> 	platform_of_node
>> Doesn't this prevent a gradual dailink transition where e.g. the
>> platform_name is removed first and then the codec_name/codec_dai_name
>> is removed second?
> I'm thinking transition to modern from legacy for "normal drivers"
> will be like this
>
> 	1) will happen after multi-CPU was supported
> 	2) Transit everything (= CPU/Codec/Platform) by 1 patch for each drivers,
> 	   not gradual transition (= Mark / Lars doesn't like this style).
> 	3) If you need/want to gradual transition (= like simple-card, audio-graph),
> 	   unfortunately, it will be full responsibility for your action.
>
> Yes, it is selfish, but is very difficult to prevent all cases in this case.
> So I think we need to have some rule for transition.
> Or, other idea is that transit all drivers first without this patch,
> and add support "no Platform" 2nd.
> In this case, it will be easier, but will needs many patches.
> I'm not sure which one is best.
>
>> I started doing the transition in steps changing all dailinks with
>> platform and codec/codec_dai names at once is quite invasive and
>> possibly error prone. Specifically for Intel machine drivers, the
>> codec names are heavily tweaked to align with the actual ACPI name,
>> not the hard-coded one, and that should be tested independently if
>> possible. Same for codec_dai_names, they depend on quirks.
> Yeah agree.
> I think transit to modern style on magical (= non hard-coded) platform
> will be trouble...
> I'm thinking that transition patch need to be tested/confirmed
> before removing legacy style for its safety
>
> 	1) transit "hard-coded" platform first, and confirm
> 	   modern style behavior.
> 	2) if no problem happen on 1) step, transit "magical" platform 2nd step.
> 	   will have few/some problem, fixup step-by-step.
>
> These are my opinion, but I want to know your and Mark's idea.
> I can adjust/follow to it.

The problem is that it's not just a renaming, there are multiple cases 
where the codec_name, codec_dai_name fields are explicitly handled. See 
my initial (compile-tested only) changes at [1]

[1] https://github.com/plbossart/sound/commits/fix/codec-legacy-dai