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.