On Mon, Jan 06, 2025 at 10:09:19AM -0600, Pierre-Louis Bossart wrote:
>
> >>>> This laptop ships with a different DMI identifier to what was expected,
> >>>> and also has the DMICs connected to the host rather than the cs42l43
> >>>> codec.
> >>>
> >>> If the DMICs are connected to the host, isn't there NHLT information
> >>> telling the OS how many dmics are connected? If yes, then the
> >>> machine-level DMI quirk isn't really needed, all you would need is a
> >>> rule that sets it unconditionally when mach->mach_params.dmic_num is
> >>> non-zero
> >>
> >> That is a good idea. However, we also test the case where the PCH DMIC
> >> and SoundWire DMIC coexist in the developing stage. Maybe use a quirk
> >> for the different DMIC coexist case?
> >
> > On second thought, we will eventually create the dai links by reading
> > the SDCA functions and remove those DMI quirks. Not sure is it worth
> > to change it or even add a new quirk just for temporary used?
>
> If you have any NHLT information, that's a very strong sign that
> the platform does rely on PCH-connected DMICS. If you don't then
> quirks are indeed needed to select PCH or codec-based solutions. I
> think it's fine to add such quirks for now, it'd be up to Cirrus
> to remove them later on when all the SDCA parsing is available,
> which could take a while.
>
Yeah I would suggest going with the quirk for now, then switching
to the DisCo information once we have that available. I think
that is likely to be more reliable than inferring from if the host
includes NHLT. Undoubtedly someone will make a system that has
some host DMICs and some CODEC DMICs or something like that.
Thanks,
Charles
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]