+ Intel Libin
Hi Jaroslav and Intel team,
> >
> >>>> My suggestions are (pick one):
> >>>>
> >>>> 1) 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
> >>
"create one multichannel control and remove the stereo controls"
This might be the easiest way for implementation on driver, but it might affect current ucm structure.
Besides, per previous discussion (on DEC 15,2020) ,
remove "Main" from "Main Capture Switch/Volume" and keep the rest controls is also an option, is it?
For me, both above suggestions are doable, what's intel team's opinion?
> >> It's not widely used, so it would be better to break things now than later.
> >
> > rt715 has been used on CometLake-based devices for a while (1.5 years?).
>
> But SDW is supported recently in the upstream Linux kernel. So there are no
> users.
>
> >> 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.
> >
> > they do, unfortunately, see ucm2/codecs/rt715/init.conf
> >
> > cset "name='rt715 ADC 27 Capture Switch' 1"
> > cset "name='rt715 ADC 07 Capture Switch' 1"
> > cset "name='rt715 ADC 07 Capture Volume' 58"
> >
> >>> 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).
> >
> > The hardware exposes registers to deal with two inputs separately,
> > they are not duplicates. The point here is that we need a mapping to a
> > simpler view where those two inputs are merged logically.
>
> Yes, but why to force stereo grouping when you need to control 4 independent
> channels from the user space POV? I'm speaking about the forced 'stereo -> 4
> channels volume / switch' mapping.
>
> >>>> 3) 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).
> >
> > that's not right, see above.
> >
> > I may have misunderstood your point for 3). I assumed you'd need a
> > description coming from the kernel, as we did before for the
> > components (cfg-mics, etc). How would UCM know which of the controls
> > to use without any change to the kernel?
>
> Ideally, yes - it will help to reduce the configuration and the driver already
> knows more about the hardware. But we can do DMI matching in UCM for now,
> too.
>
@Libin Is this modification workable for you? I'd like to know your opinion about it. Thanks.
> Example of the sysfs substitution:
>
> ${sys:class/dmi/id/sys_vendor}
> ${sys:class/dmi/id/product_version}
>
> Jaroslav
>
> --
> Jaroslav Kysela <perex@xxxxxxxx>
> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
>
> ------Please consider the environment before printing this e-mail.
