Dne 15. 12. 20 v 17:00 Pierre-Louis Bossart napsal(a):
My suggestions are (pick one):
- create one multichannel control and remove the stereo controls when the
hardware is detected (no functionality dup)
we can't remove controls that existed before, this might break userspace
It's not widely used, so it would be better to break things now than later. But I see that others are a bit conservative.
with older UCM files that touch those ADC07 and ADC27. That's why we
The upstream UCM files don't refer to those controls.
added a new one, to be backwards compatible with a user updates their kernel.
Even if you don't remove the duplicate controls, the right abstraction is more appropriate in my eyes (better than vmaster extension). The double stereo -> 4 channel array mapping is not fully correct (vmaster, proposed patch).
- create proper vmaster control like for HDA playback
That might be the better option. What was suggested in this patch is essentially to introduce a layer that drives the actual controls, but it was done 'manually' and may not follow the proper rules.
That said I know absolutely nothing about 'vmaster controls', pointers to a typical example would be greatly appreciated.
sound/core/vmaster.c ; The ASoC core will probably require another layer to support this?
- wait until UCM can describe this hardware and set the DAC values manually
to a sensible value via sequences (the specific hardware levels can be set using the conditions in UCM)
Not an option, there are products that need to ship soon.
It's the easiest method for now. It's just about to change the UCM files without any other changes in the kernel / user space. It's heavily used for SST drivers, isn't?
The current UCM upstream modifies only SOF volume levels (PGA Master Capture).
Jaroslav