On Tue, Feb 01, 2022 at 02:02:15AM +0530, V sujith kumar Reddy wrote:

> Maxim codec driver already enabling/disabling spk_en_gpio in form of sd_mode gpio
> hence remove such gpio access control from machine driver to avoid conflict


> -	.gpio_spkr_en = EN_SPKR_GPIO_NK,
> +	.gpio_spkr_en = EN_SPKR_GPIO_NONE,
>  };
>  
>  static struct acp_card_drvdata sof_rt5682s_rt1019_data = {
> @@ -56,7 +56,7 @@ static struct acp_card_drvdata sof_rt5682s_max_data = {
>  	.hs_codec_id = RT5682S,
>  	.amp_codec_id = MAX98360A,
>  	.dmic_codec_id = DMIC,
> -	.gpio_spkr_en = EN_SPKR_GPIO_NK,
> +	.gpio_spkr_en = EN_SPKR_GPIO_NONE,
>  };

This looks like a good fix for the immediate issue which fixes the
MAX9360A systems without breaking the RT1019 ones, however as I said in
the thread about Curtis' revert it's not clear what the ideal thing is
here.  There's no documentation about the RT1019 that I can find so it's
not clear to me what exactly the GPIO is controlling, if it's part of
the RT1019 or something else.  That influences where the most tasteful
place to control this GPIO is.  Curtis noted that the RT1019 driver
includes gpiolib headers but that could just as easily be cut'n'paste as
intentional.  What's the story here?

I do also note that the current code just turns the GPIO on and leaves
it on which presumably isn't great from a power management point of
view.