On 10/11/2016 10:30 AM, Charles Keepax wrote:
On Mon, Oct 10, 2016 at 11:26:00AM +0200, Arnaud Pouliquen wrote:
On 10/09/2016 05:05 AM, Takashi Sakamoto wrote:
Sorry to be late. I've review your driver in for-next branch of maintainer's tree.
On Oct 8 2016 01:41, Arnaud Pouliquen wrote: But I still oppose this idea. This idea allows drivers to add control element sets of different types (int/int64/bytes etc...) with the same name and different index number. This certainly brings confusions to applications.
Today is already possible using the device or subdevice field instead of index.
In a framework of ALSA SoC part, several drivers are associated to one sound card instance can add their own control element sets. There's no mechanism to prevent my concern. This idea is bad.
Please tell me if i misunderstand. So for you, there is no real solution to do it in a generic way. Drivers has to implement it, if they want to support.
Another solution is to declare a card per instance of control. This should work for my use case and for use cases with several codecs that declare same controls. But this should not work for DPCM... The drawback for my use case, would be that i need to declare one card per PCM device.
Apologies if I am missing the mark here, I haven't been following this thread in great detail. But if your main concern here is multiple instances of the same CODEC creating the same controls the normal way to handle that in ASoC is using a snd_soc_codec_conf struct which lets you add a prefix to all the controls from a specific instance of a CODEC. See sound/soc/samsung/bells.c for an example using it.
Codec multi instance is one of the use cases. CPU_DAI multi instance is another one (and my main concern). But use of a prefix_name is a good point that i have not prospected yet, thanks. Today it is not implemented neither for CPU_DAIs nor for simple card. But my main drawback of the prefix name, is that this breaks the naming of generic controls like IEC. So i can't use it.
Regards Arnaud