Hi,
On 11/09/2016 01:33 PM, Takashi Sakamoto wrote:
Hi,
On Nov 8 2016 17:11, Arnaud Pouliquen wrote:
- Patches proposed:
Based on these observations, here are some patches that i tested in my environment. There are complementary, and could answer to some limitations mentioned above.
3-1) Alsa-utils patch
- iecset: allow to select control with device and sub-device numbers This patch allows to access to 2 iec controls differentiated by device/sub-devices numbers
=> For me, this patch is mandatory to be able to address the ASoC IEC controls, in case of no fix is implemented to allows index field update in ASoC.
3-2) Alsa driver patches
- ASoC: core: allow PCM control binding to PCM device
Add relationship between DAIs PCM controls and PCM device.
ALSA: control: increment index field for duplicated control. Generic implementation of the patch proposed in HDA driver (http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ea9b4...)
ASoC: sti: use bind_pcm_ctl
implementation of bind_pcm_ctl for sti driver.
In my view, this patchset includes two attempts: 1.to add a framework into ALSA SoC part to relate some control element sets to PCM devices 2.to allow drivers in ALSA SoC part to add some control element sets from the same codes according to entries of dtb
To achieve above 2nd attempt, it changes ALSA control core to accept several control element sets with the same name by assigning proper indexes to the sets.
Well, since your former messages, you continue using the word, 'general' or 'generic'. If it were somewhat general, it should satisfy requirements in whole this subsystem. Actually, there's none of such requirements outside of ALSA SoC part. For the drivers outside of ALSA SoC part, design of target sound card is fixed in advance, therefore programmers can assign control element sets to PCM devices in usual ways. At least, current infrastructure in ALSA control core can satisfy the programmers.
Therefore, I think that your attempts includes over-generalization. In theory, it can bring over-specification easily and it causes code complication or unmaintained codes.
I based my RFC on the fact that i was facing same kind of problem than HDA driver (last time i mention it). In this context, i don't think that it was senseless to have a global approach. If not the good approach, let's refocus on ASoC, that's fine by me.
Focusing on ALSA SoC part, there's a requirement to register control element sets from the same code, in fact. So I wonder why you don't start your explanation in an aspect of it. In short, I can't understand the reason that you adhere to such an inappropriate generalization for this subsystem.
In this patchset, you adhere to usage of 'index' field. But there's another way; assigning different identification information to the control element sets. Let us to start discussion from this point? At least, Iwai-san said, former driver for Intel High Definition Audio is necessarily not a good example for a model to c onsider about this issue and the usage of 'index' is not well-generalized[1].
Finally, it's better to clear main points of your issue, for practical and meaningful discussion for better approaches, before starting this discussion, I think. At least, there's over-generalization, misunderstandings of design and interfaces, driver-specific historical reasons and so on.
[1] [alsa-devel] [RFC 0/4] ALSA controls management using index/device/sub-devices fields http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/114430.ht...
So I propose to continue discussion on a simple and concrete use case: The 'IEC958 Playback Default' control.
In my ASoC driver i have one HDMI and one SPDIF outputs. so I have 2'IEC958 Playback Default' PCM controls. => Each control can be set independently.
Regarding control identification field (struct snd_ctl_elem_i): .numid; => set by ALSA framework .iface; => must be SNDRV_CTL_ELEM_IFACE_PCM .device; => must be linked to PCM device , but not possible for ASoC DAI... .subdevice => not used in ASoC implementation .name => 'IEC958 Playback Default' .index => not used in ASoC, forced to 0 by snd_soc_cnew
Other solution: use control "prefix"? not possible as control has a pre-defined name.
=> Only solution to differentiate the control: "device" field. (that seems coherent as it a PCM device).
Issues: - use "device" in ASOC DAI driver means that driver needs to define a "virtual" PCM device value, not the PCM device. => this break the rule that mention that PCM control should be linked to a PCM device. Furthermore, this "virtual" value has to be aligned with the one defined in alsa-lib conf file(s). - iecset uses only index to differentiate IEC controls. But in ASoC implementation this is not possible as index is forced to 0.
Regards Arnaud