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

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

 



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.

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



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

  Powered by Linux