Re: [PATCH 56/56] ASoC: simple-card-utils: Move snd_soc_component_is_codec to be local

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

 



On Fri, May 20, 2022 at 01:02:33AM +0000, Kuninori Morimoto wrote:
> 
> Hi
> 
> This is not related to this patch, but...
> 
> > -static inline int snd_soc_component_is_codec(struct snd_soc_component *component)
> > -{
> > -	return component->driver->non_legacy_dai_naming;
> > -}
> (snip)
> > +static inline int asoc_simple_component_is_codec(struct snd_soc_component *component)
> > +{
> > +	return component->driver->endianness;
> > +}
> 
> I have added "endianness" "non_legacy_dai_naming" to component
> when convert old "Codec style" into current "Component style".
> All codec needs to have these 2.
> 
> 	69941bab7c7aeaa7bf7e84397e294c17f0b7c6df
> 	("ASoC: snd_soc_component_driver has non_legacy_dai_naming")
> 
> 	273d778ef38a8861f880e9df5799029dc82bd55d
> 	("ASoC: snd_soc_component_driver has endianness")
> 
> The reason why I didn't use "codec" was that try to keep
> original style as much as possible.
> But it seems this is good time to use "codec" for it ?
> I think the code will be more understandable.
> 
> -	.endianness
> -	.non_legacy_dai_naming
> +	.is_codec

Yeah I considered this but it didn't really feel like the right
way to go to me. Firstly, at this stage we almost certainly need
to keep the endianness and non_legacy_dai_naming flags, there are
corner cases when endianness probably shouldn't be applied to CODECs
(as noted in my endianness series), and there are platform drivers
that use non_legacy_dai_naming.

We could add an is_codec flag along side the other two. But it
means a whole extra flag and means the the core is still requiring
a concept of what is a CODEC driver, which really we want to get
rid of as part of componentisation.

My thinking was that, whilst making this function local to the
driver isn't perfect, simple card will be used with simple CODECs
that are likely to exist on a standard audio bus, and thus have
endianness and the newer graph cards don't require specific
identification of what is a CODEC driver. So it probably works as
a solution for now.

> 
> Thank you for your help !!

Absolutely no problem, thank you for all the work you have done
on this over the years.

Thanks,
Charles



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux