On Tue, Feb 1, 2022 at 10:56 AM Mark Brown <broonie@xxxxxxxxxx> wrote: > > 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. Yes that is correct, this is the quick fix that will alleviate the gpio contention issue. But I think there is a better solution here. According to the sheet I have, the pin for the alc1019 is the same as the max98357a and its a shutdown pin for the amp.