On Fri, 21 Apr 2017 22:28:05 +0200,
Pierre-Louis Bossart wrote:
>
>
>
> On 04/21/2017 03:15 PM, Takashi Iwai wrote:
> > The bytcr-rt5640 driver has a few quirk setups depending on the board,
> > where the quirk value is set by DMI matching. When you have a new
> > device to add the support, you often experience to try the different
> > quirk by trial-and-error. Or, you may have a development model that
> > still has no proper DMI string. In either case, you'd need to compile
> > the driver at each time.
> >
> > This patch introduces a module option to override the quirk value on
> > the fly. User can boot like snd-soc-sst-bytcr-rt5640.quirk=0x4004 to
> > override the default value without recompilation. It's a raw value,
> > so user needs to check the source code for the meaning of each bit.
> I am doing similar things at the moment, I folded IN1 and IN3 quirks
> together and was about to add a control to force
> single-ended/differential mics. The use of a parameter is not bad, we
> could stick it in a modprobe file and avoid writing more code.
>
> That said, unless I am missing something, the problem with this
> parameter is that it will be overwritten by
> DMI quirks or the settings detected by the driver, see e.g. this code.
>
> /* change defaults for Baytrail-CR capture */
> byt_rt5640_quirk |= BYT_RT5640_IN1_MAP;
> byt_rt5640_quirk |= BYT_RT5640_DIFF_MIC;
> } else {
> byt_rt5640_quirk |= (BYT_RT5640_DMIC1_MAP |
> BYT_RT5640_DMIC_EN);
> }
>
> /* check quirks before creating card */
> dmi_check_system(byt_rt5640_quirk_table);
> log_quirks(&pdev->dev);
>
> We may need a second variable to force the .quirk parameter to be used
> as is and avoid applying changes done at run-time.
Well, I somehow hesitated a complete override, but yeah, it'd be
sometimes more helpful. OK, let me respin the patch quickly...
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
