On Wed, 28 Jun 2017 23:07:01 +0200,
Pierre-Louis Bossart wrote:
>
> On 6/28/17 7:49 AM, Takashi Iwai wrote:
> > GPD Win requires jd_mode=3 and the inverted flag for making the jack
> > detection working. Unfortunately, the BIOS doesn't give a nice way to
> > match with DMI strings, and the only working way so far is to match
> > with the board vendor/name/version/date to some known patterns.
> >
> > Hopefully other vendors won't do such a stupid setup, too...
> >
> > Thanks to Hans de Goede for the DMI matching suggestion.
> >
> > Suggested-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> > Tested-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> > Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
> > ---
> > sound/soc/codecs/rt5645.c | 29 +++++++++++++++++++++++++++++
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
> > index 162044d82632..308c22f5909a 100644
> > --- a/sound/soc/codecs/rt5645.c
> > +++ b/sound/soc/codecs/rt5645.c
> > @@ -3599,6 +3599,33 @@ static struct dmi_system_id dmi_platform_intel_broadwell[] = {
> > { }
> > };
> >
> > +static struct rt5645_platform_data gpd_win_platform_data = {
> > + .jd_mode = 3,
> > + .inv_jd1_1 = true,
> > +};
> > +
> > +static const struct dmi_system_id dmi_platform_gpd_win[] = {
> > + {
> > + /*
> > + * Match for the GPDwin which unfortunately uses somewhat
> > + * generic dmi strings, which is why we test for 4 strings.
> > + * Comparing against 23 other byt/cht boards, board_vendor
> > + * and board_name are unique to the GPDwin, where as only one
> > + * other board has the same board_serial and 3 others have
> > + * the same default product_name. Also the GPDwin is the
> > + * only device to have both board_ and product_name not set.
> > + */
> > + .ident = "GPD Win",
> > + .matches = {
> > + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> > + DMI_MATCH(DMI_BOARD_NAME, "Default string"),
> > + DMI_MATCH(DMI_BOARD_SERIAL, "Default string"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
> > + },
> > + },
> > + {}
>
> it feels like it's time to add a quirk parameter for this codec module
> to avoid chasing all possible DMI/BIOS issues?
Yes, my very first version was such one, but we ended up with this
version as the weird-looking DMI matching was confirmed to work
uniquely.
If Realtek guys agree, I can submit the patch to add module options in
addition.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
