[alsa-devel] [PATCH] ASoC: rt5670: Fix GPIO headset detection regression
RT5670 codec driver and its machine driver for Intel CHT assume the implicit GPIO mapping on the index 0 while BIOS on most devices don't provide it. The recent commit f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") restricts such cases and it resulted in a regression where the headset jack setup fails like:
rt5670 i2c-10EC5672:00: ASoC: Cannot get gpio at index 0: -2 rt5670 i2c-10EC5672:00: Adding jack GPIO failed
For fixing this, we need to provide the GPIO mapping explicitly in the machine driver. Also this patch corrects the string to be passed to gpiolib to match with the pre-given mapping, too.
Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115531 Reported-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Tested-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/soc/codecs/rt5670.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5672.c | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/rt5670.c b/sound/soc/codecs/rt5670.c index 0ec7985ed306..054b613cb0d0 100644 --- a/sound/soc/codecs/rt5670.c +++ b/sound/soc/codecs/rt5670.c @@ -567,7 +567,7 @@ int rt5670_set_jack_detect(struct snd_soc_codec *codec,
rt5670->jack = jack; rt5670->hp_gpio.gpiod_dev = codec->dev; - rt5670->hp_gpio.name = "headphone detect"; + rt5670->hp_gpio.name = "headset"; rt5670->hp_gpio.report = SND_JACK_HEADSET | SND_JACK_BTN_0 | SND_JACK_BTN_1 | SND_JACK_BTN_2; rt5670->hp_gpio.debounce_time = 150; diff --git a/sound/soc/intel/boards/cht_bsw_rt5672.c b/sound/soc/intel/boards/cht_bsw_rt5672.c index bc2a52de06a3..f597d5582223 100644 --- a/sound/soc/intel/boards/cht_bsw_rt5672.c +++ b/sound/soc/intel/boards/cht_bsw_rt5672.c @@ -184,6 +184,13 @@ static int cht_aif1_hw_params(struct snd_pcm_substream *substream, return 0; }
+static const struct acpi_gpio_params headset_gpios = { 0, 0, false }; + +static const struct acpi_gpio_mapping cht_rt5672_gpios[] = { + { "headset-gpios", &headset_gpios, 1 }, + {}, +}; + static int cht_codec_init(struct snd_soc_pcm_runtime *runtime) { int ret; @@ -191,6 +198,9 @@ static int cht_codec_init(struct snd_soc_pcm_runtime *runtime) struct snd_soc_codec *codec = codec_dai->codec; struct cht_mc_private *ctx = snd_soc_card_get_drvdata(runtime->card);
+ if (devm_acpi_dev_add_driver_gpios(codec->dev, cht_rt5672_gpios)) + dev_warn(runtime->dev, "Unable to add GPIO mapping table\n"); + /* TDM 4 slots 24 bit, set Rx & Tx bitmask to 4 active slots */ ret = snd_soc_dai_set_tdm_slot(codec_dai, 0xF, 0xF, 4, 24); if (ret < 0) {
On Tue, 2017-08-22 at 07:44 +0200, Takashi Iwai wrote:
RT5670 codec driver and its machine driver for Intel CHT assume the implicit GPIO mapping on the index 0 while BIOS on most devices don't provide it. The recent commit f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") restricts such cases and it resulted in a regression where the headset jack setup fails like:
rt5670 i2c-10EC5672:00: ASoC: Cannot get gpio at index 0: -2 rt5670 i2c-10EC5672:00: Adding jack GPIO failed
For fixing this, we need to provide the GPIO mapping explicitly in the machine driver. Also this patch corrects the string to be passed to gpiolib to match with the pre-given mapping, too.
Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
I don't think it fixes that exact commit. with this mapping the driver will work pretty much well for previous versions of kernel (that do not have mentioned commit).
So, for my opinion it should have referred to the initial commit of that board file which brings GPIO request in the first place.
After addressing that, Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115531 Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.co m> Tested-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai tiwai@suse.de
sound/soc/codecs/rt5670.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5672.c | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/rt5670.c b/sound/soc/codecs/rt5670.c index 0ec7985ed306..054b613cb0d0 100644 --- a/sound/soc/codecs/rt5670.c +++ b/sound/soc/codecs/rt5670.c @@ -567,7 +567,7 @@ int rt5670_set_jack_detect(struct snd_soc_codec *codec, rt5670->jack = jack; rt5670->hp_gpio.gpiod_dev = codec->dev;
- rt5670->hp_gpio.name = "headphone detect";
- rt5670->hp_gpio.name = "headset";
rt5670->hp_gpio.report = SND_JACK_HEADSET | SND_JACK_BTN_0 | SND_JACK_BTN_1 | SND_JACK_BTN_2; rt5670->hp_gpio.debounce_time = 150; diff --git a/sound/soc/intel/boards/cht_bsw_rt5672.c b/sound/soc/intel/boards/cht_bsw_rt5672.c index bc2a52de06a3..f597d5582223 100644 --- a/sound/soc/intel/boards/cht_bsw_rt5672.c +++ b/sound/soc/intel/boards/cht_bsw_rt5672.c @@ -184,6 +184,13 @@ static int cht_aif1_hw_params(struct snd_pcm_substream *substream, return 0; } +static const struct acpi_gpio_params headset_gpios = { 0, 0, false };
+static const struct acpi_gpio_mapping cht_rt5672_gpios[] = {
- { "headset-gpios", &headset_gpios, 1 },
- {},
+};
static int cht_codec_init(struct snd_soc_pcm_runtime *runtime) { int ret; @@ -191,6 +198,9 @@ static int cht_codec_init(struct snd_soc_pcm_runtime *runtime) struct snd_soc_codec *codec = codec_dai->codec; struct cht_mc_private *ctx = snd_soc_card_get_drvdata(runtime->card);
- if (devm_acpi_dev_add_driver_gpios(codec->dev,
cht_rt5672_gpios))
dev_warn(runtime->dev, "Unable to add GPIO mappingtable\n");
/* TDM 4 slots 24 bit, set Rx & Tx bitmask to 4 active slots */ ret = snd_soc_dai_set_tdm_slot(codec_dai, 0xF, 0xF, 4, 24); if (ret < 0) {
On Tue, 22 Aug 2017 10:33:22 +0200, Andy Shevchenko wrote:
On Tue, 2017-08-22 at 07:44 +0200, Takashi Iwai wrote:
RT5670 codec driver and its machine driver for Intel CHT assume the implicit GPIO mapping on the index 0 while BIOS on most devices don't provide it. The recent commit f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") restricts such cases and it resulted in a regression where the headset jack setup fails like:
rt5670 i2c-10EC5672:00: ASoC: Cannot get gpio at index 0: -2 rt5670 i2c-10EC5672:00: Adding jack GPIO failed
For fixing this, we need to provide the GPIO mapping explicitly in the machine driver. Also this patch corrects the string to be passed to gpiolib to match with the pre-given mapping, too.
Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
I don't think it fixes that exact commit. with this mapping the driver will work pretty much well for previous versions of kernel (that do not have mentioned commit).
So, for my opinion it should have referred to the initial commit of that board file which brings GPIO request in the first place.
Yeah, it's a bit unclear which commit should be pointed as "fixes" in such a case. Clearly, the regression came by the mentioned commit, so I picked it up for fixes-tag as the indicator to which kernel it should be backported -- in the case when it slipped from 4.13 cycle. We don't have to apply the fix for patches older than 4.12, it just works. The original GPIO code had some implicit assumption and it worked somehow -- no matter whether it's the right thing or not.
So, while I'm fine to change the fixes tag to point another commit, it becomes slightly apart from the "regression fix" that the commit was intended for.
That said, this comes from the multiple usages of fixes tag: it can point to a regression point that the patch fixes, and it can point to the original commit the (potential) issue was introduced.
thanks,
Takashi
After addressing that, Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115531 Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.co m> Tested-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai tiwai@suse.de
sound/soc/codecs/rt5670.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5672.c | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/rt5670.c b/sound/soc/codecs/rt5670.c index 0ec7985ed306..054b613cb0d0 100644 --- a/sound/soc/codecs/rt5670.c +++ b/sound/soc/codecs/rt5670.c @@ -567,7 +567,7 @@ int rt5670_set_jack_detect(struct snd_soc_codec *codec, rt5670->jack = jack; rt5670->hp_gpio.gpiod_dev = codec->dev;
- rt5670->hp_gpio.name = "headphone detect";
- rt5670->hp_gpio.name = "headset";
rt5670->hp_gpio.report = SND_JACK_HEADSET | SND_JACK_BTN_0 | SND_JACK_BTN_1 | SND_JACK_BTN_2; rt5670->hp_gpio.debounce_time = 150; diff --git a/sound/soc/intel/boards/cht_bsw_rt5672.c b/sound/soc/intel/boards/cht_bsw_rt5672.c index bc2a52de06a3..f597d5582223 100644 --- a/sound/soc/intel/boards/cht_bsw_rt5672.c +++ b/sound/soc/intel/boards/cht_bsw_rt5672.c @@ -184,6 +184,13 @@ static int cht_aif1_hw_params(struct snd_pcm_substream *substream, return 0; } +static const struct acpi_gpio_params headset_gpios = { 0, 0, false };
+static const struct acpi_gpio_mapping cht_rt5672_gpios[] = {
- { "headset-gpios", &headset_gpios, 1 },
- {},
+};
static int cht_codec_init(struct snd_soc_pcm_runtime *runtime) { int ret; @@ -191,6 +198,9 @@ static int cht_codec_init(struct snd_soc_pcm_runtime *runtime) struct snd_soc_codec *codec = codec_dai->codec; struct cht_mc_private *ctx = snd_soc_card_get_drvdata(runtime->card);
- if (devm_acpi_dev_add_driver_gpios(codec->dev,
cht_rt5672_gpios))
dev_warn(runtime->dev, "Unable to add GPIO mappingtable\n");
/* TDM 4 slots 24 bit, set Rx & Tx bitmask to 4 active slots */ ret = snd_soc_dai_set_tdm_slot(codec_dai, 0xF, 0xF, 4, 24); if (ret < 0) {
-- Andy Shevchenko andriy.shevchenko@linux.intel.com Intel Finland Oy
On Tue, 2017-08-22 at 10:48 +0200, Takashi Iwai wrote:
On Tue, 22 Aug 2017 10:33:22 +0200, Andy Shevchenko wrote:
On Tue, 2017-08-22 at 07:44 +0200, Takashi Iwai wrote:
RT5670 codec driver and its machine driver for Intel CHT assume the implicit GPIO mapping on the index 0 while BIOS on most devices don't provide it. The recent commit f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") restricts such cases and it resulted in a regression where the headset jack setup fails like:
rt5670 i2c-10EC5672:00: ASoC: Cannot get gpio at index 0: -2 rt5670 i2c-10EC5672:00: Adding jack GPIO failed
For fixing this, we need to provide the GPIO mapping explicitly in the machine driver. Also this patch corrects the string to be passed to gpiolib to match with the pre-given mapping, too.
Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
I don't think it fixes that exact commit. with this mapping the driver will work pretty much well for previous versions of kernel (that do not have mentioned commit).
So, for my opinion it should have referred to the initial commit of that board file which brings GPIO request in the first place.
Yeah, it's a bit unclear which commit should be pointed as "fixes" in such a case. Clearly, the regression came by the mentioned commit, so I picked it up for fixes-tag as the indicator to which kernel it should be backported -- in the case when it slipped from 4.13 cycle. We don't have to apply the fix for patches older than 4.12, it just works. The original GPIO code had some implicit assumption and it worked somehow -- no matter whether it's the right thing or not.
So, while I'm fine to change the fixes tag to point another commit, it becomes slightly apart from the "regression fix" that the commit was intended for.
That said, this comes from the multiple usages of fixes tag: it can point to a regression point that the patch fixes, and it can point to the original commit the (potential) issue was introduced.
It depends on two things: 1) which commit was first: the mentioned one or the board file; 2) how we formulate the patch: fix a "regression" or make it robust against changes.
Okay, briefly looking seems like GPIO commit comes later, so, it's a good point to leave fixes as is now. I missed those files since I have checked a list against modules that have both ACPI ID table and one of *gpiod_get*() function. I forgot to check against specific sound GPIO helper.
So, take my tag disregarding on my comment. Thanks!
P.S. All ASoC board files that are used for ACPI enabled platforms have to be fixed accordingly.
participants (2)
-
Andy Shevchenko -
Takashi Iwai