Dne 15. 04. 21 v 23:35 Pierre-Louis Bossart napsal(a): > > > On 3/30/21 2:26 PM, Pierre-Louis Bossart wrote: >> >> >>>>> Using new kcontrols "Capture Switch" and "Capture Volume" instead, >>>>> remove kcontrols which no longer be used. >>>> >>>> Is this going to disrupt any UCM profiles? >>> >>> Yes (the rt715 prefix is from the SOF driver): >>> >>> # RT715 specific volume control settings >>> >>> BootSequence [ >>> cset "name='rt715 DMIC3 Boost' 2" >>> cset "name='rt715 DMIC4 Boost' 2" >>> cset "name='rt715 ADC 24 Mux' 3" >>> cset "name='rt715 ADC 25 Mux' 4" >>> cset "name='rt715 ADC 27 Capture Switch' 1" >>> cset "name='rt715 ADC 07 Capture Switch' 1" >>> cset "name='rt715 ADC 07 Capture Volume' 58" >>> ] >> >> To be clearer, we wanted to change the UCM files to only try to >> configure the 'old' controls when they are present. The 'new' controls >> are aligned between RT715 and RT715-sdca. >> >> There will be a minor inconvenience if an existing platform updates the >> kernel without updating UCM files, but it's the only solution we found >> in earlier discussions. >> >> Distributions are typically faster with alsa-ucmconf updates than kernel >> changes so that inconvenience is likely very limited (we support 4-5 >> Dell CML/TGL platforms w/ SoundWire) > > Was there any sustained objection to this change? Mark and Jaroslav? > > I would really like to fix the UCM files so that the mute and volume are > handled at the codec driver level, and not at the SOF level as it's > currently the case. > > The existing solution really makes no sense, it was 'inspired' (in the > copy-paste sense) by the PCH-DMIC handling for HDaudio platforms. In > that case, it made sense to use SOF-level mute/volume because such > controls don't exist in microphones. > > With RT715 we need to use the controls in the codec driver, not the > firmware. I'm basically ok to do any change which simplifies things. The user-space downgrade is possible but less used. The only my concern is that RT715 as an universal codec can handle the multiple stereo streams (current controls mapping) or the multichannel stream (new proposed controls mapping). The ASoC codec code should be universal, so it's a question, how to model the controls and how to detect and set the model. I think that we're missing a communication way between the DMA / machine driver and the codec driver. Yes, we can add DMI checks to RT715, but usually, the specific machines are already detected in the higher layer (soundwire bus, pci bus). It would be really nice, if the SOF driver can do a query: "If present, I need RT715 codec in the multichannel mode.". So my opinion is that both mappings may exist and the correct one should be selected at runtime. So I won't delete the old mapping, it may be usable. Mark? BTW: I already implemented the control remap plugin to alsa-lib, so you can split / merge controls with similar parameters as you like now. I need to do more test with the UCM integration, but it's here. https://github.com/alsa-project/alsa-lib/blob/master/src/control/control_remap.c#L1197 Jaroslav -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
