[PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support nvidia, headset property
From: Dmitry Osipenko digetx@gmail.com
[ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
The microphone-jack state needs to be masked in a case of a 4-pin jack when microphone and ground pins are shorted. Presence of nvidia,headset tells that WM8903 CODEC driver should mask microphone's status if short circuit is detected, i.e headphones are inserted.
Signed-off-by: Dmitry Osipenko digetx@gmail.com Link: https://lore.kernel.org/r/20200330204011.18465-3-digetx@gmail.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/tegra/tegra_wm8903.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/soc/tegra/tegra_wm8903.c b/sound/soc/tegra/tegra_wm8903.c index 9b5651502f12..3aca354f9e08 100644 --- a/sound/soc/tegra/tegra_wm8903.c +++ b/sound/soc/tegra/tegra_wm8903.c @@ -177,6 +177,7 @@ static int tegra_wm8903_init(struct snd_soc_pcm_runtime *rtd) struct snd_soc_component *component = codec_dai->component; struct snd_soc_card *card = rtd->card; struct tegra_wm8903 *machine = snd_soc_card_get_drvdata(card); + int shrt = 0;
if (gpio_is_valid(machine->gpio_hp_det)) { tegra_wm8903_hp_jack_gpio.gpio = machine->gpio_hp_det; @@ -189,12 +190,15 @@ static int tegra_wm8903_init(struct snd_soc_pcm_runtime *rtd) &tegra_wm8903_hp_jack_gpio); }
+ if (of_property_read_bool(card->dev->of_node, "nvidia,headset")) + shrt = SND_JACK_MICROPHONE; + snd_soc_card_jack_new(rtd->card, "Mic Jack", SND_JACK_MICROPHONE, &tegra_wm8903_mic_jack, tegra_wm8903_mic_jack_pins, ARRAY_SIZE(tegra_wm8903_mic_jack_pins)); wm8903_mic_detect(component, &tegra_wm8903_mic_jack, SND_JACK_MICROPHONE, - 0); + shrt);
snd_soc_dapm_force_enable_pin(&card->dapm, "MICBIAS");
On Wed, Jun 17, 2020 at 09:01:41PM -0400, Sasha Levin wrote:
From: Dmitry Osipenko digetx@gmail.com
[ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
The microphone-jack state needs to be masked in a case of a 4-pin jack when microphone and ground pins are shorted. Presence of nvidia,headset tells that WM8903 CODEC driver should mask microphone's status if short circuit is detected, i.e headphones are inserted.
This is a new feature not a bugfix.
On Thu, Jun 18, 2020 at 12:00:23PM +0100, Mark Brown wrote:
On Wed, Jun 17, 2020 at 09:01:41PM -0400, Sasha Levin wrote:
From: Dmitry Osipenko digetx@gmail.com
[ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
The microphone-jack state needs to be masked in a case of a 4-pin jack when microphone and ground pins are shorted. Presence of nvidia,headset tells that WM8903 CODEC driver should mask microphone's status if short circuit is detected, i.e headphones are inserted.
This is a new feature not a bugfix.
I saw this patch more as a hardware quirk.
On Thu, Jun 18, 2020 at 10:30:46AM -0400, Sasha Levin wrote:
On Thu, Jun 18, 2020 at 12:00:23PM +0100, Mark Brown wrote:
On Wed, Jun 17, 2020 at 09:01:41PM -0400, Sasha Levin wrote:
From: Dmitry Osipenko digetx@gmail.com
[ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
The microphone-jack state needs to be masked in a case of a 4-pin jack when microphone and ground pins are shorted. Presence of nvidia,headset tells that WM8903 CODEC driver should mask microphone's status if short circuit is detected, i.e headphones are inserted.
This is a new feature not a bugfix.
I saw this patch more as a hardware quirk.
Pretty much any DT property is a hardware quirk :(
On Thu, Jun 18, 2020 at 03:39:30PM +0100, Mark Brown wrote:
On Thu, Jun 18, 2020 at 10:30:46AM -0400, Sasha Levin wrote:
On Thu, Jun 18, 2020 at 12:00:23PM +0100, Mark Brown wrote:
On Wed, Jun 17, 2020 at 09:01:41PM -0400, Sasha Levin wrote:
From: Dmitry Osipenko digetx@gmail.com
[ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
The microphone-jack state needs to be masked in a case of a 4-pin jack when microphone and ground pins are shorted. Presence of nvidia,headset tells that WM8903 CODEC driver should mask microphone's status if short circuit is detected, i.e headphones are inserted.
This is a new feature not a bugfix.
I saw this patch more as a hardware quirk.
Pretty much any DT property is a hardware quirk :(
Which is why we're taking most of them :)
On Sun, Jun 21, 2020 at 07:33:52PM -0400, Sasha Levin wrote:
On Thu, Jun 18, 2020 at 03:39:30PM +0100, Mark Brown wrote:
On Thu, Jun 18, 2020 at 10:30:46AM -0400, Sasha Levin wrote:
On Thu, Jun 18, 2020 at 12:00:23PM +0100, Mark Brown wrote:
This is a new feature not a bugfix.
I saw this patch more as a hardware quirk.
Pretty much any DT property is a hardware quirk :(
Which is why we're taking most of them :)
That's concerning - please don't do this. It's not what stable is expected to be and there's no guarantee that you're getting all the changes required to actually make things work.
On Mon, Jun 22, 2020 at 12:23:21PM +0100, Mark Brown wrote:
On Sun, Jun 21, 2020 at 07:33:52PM -0400, Sasha Levin wrote:
On Thu, Jun 18, 2020 at 03:39:30PM +0100, Mark Brown wrote:
On Thu, Jun 18, 2020 at 10:30:46AM -0400, Sasha Levin wrote:
On Thu, Jun 18, 2020 at 12:00:23PM +0100, Mark Brown wrote:
This is a new feature not a bugfix.
I saw this patch more as a hardware quirk.
Pretty much any DT property is a hardware quirk :(
Which is why we're taking most of them :)
That's concerning - please don't do this. It's not what stable is expected to be and there's no guarantee that you're getting all the changes required to actually make things work.
How come? This is one of the things stable rules explicitly call for: "New device IDs and quirks are also accepted".
If we're missing anything, the solution is to make sure we stop missing it rather than not take anything to begin with :)
On Mon, Jun 22, 2020 at 08:31:18AM -0400, Sasha Levin wrote:
On Mon, Jun 22, 2020 at 12:23:21PM +0100, Mark Brown wrote:
That's concerning - please don't do this. It's not what stable is expected to be and there's no guarantee that you're getting all the changes required to actually make things work.
How come? This is one of the things stable rules explicitly call for: "New device IDs and quirks are also accepted".
I would expect that to be data only additions, I would not expect that to be adding new code.
If we're missing anything, the solution is to make sure we stop missing it rather than not take anything to begin with :)
It would be much better to not have to watch stable constantly like we currently do - we're seeing people report breakage often enough to be a concern as things are, we don't need to be trying to pile extra stuff in there because there's some keywords in a changelog or whatever. The testing coverage for drivers is weak, increasing the change rate puts more stress on that.
On Mon, Jun 22, 2020 at 02:27:57PM +0100, Mark Brown wrote:
On Mon, Jun 22, 2020 at 08:31:18AM -0400, Sasha Levin wrote:
On Mon, Jun 22, 2020 at 12:23:21PM +0100, Mark Brown wrote:
That's concerning - please don't do this. It's not what stable is expected to be and there's no guarantee that you're getting all the changes required to actually make things work.
How come? This is one of the things stable rules explicitly call for: "New device IDs and quirks are also accepted".
I would expect that to be data only additions, I would not expect that to be adding new code.
These come hand in hand. Take a look at the more complex cases such as sound/pci/hda/patch_*
If we're missing anything, the solution is to make sure we stop missing it rather than not take anything to begin with :)
It would be much better to not have to watch stable constantly like we currently do - we're seeing people report breakage often enough to be a concern as things are, we don't need to be trying to pile extra stuff in there because there's some keywords in a changelog or whatever. The testing coverage for drivers is weak, increasing the change rate puts more stress on that.
Shouldn't we instead improve testing here? nvidia for example already provides Tegra testing for stable releases, if the coverage isn't sufficient then let's work on making it better.
On Mon, Jun 22, 2020 at 10:44:02AM -0400, Sasha Levin wrote:
On Mon, Jun 22, 2020 at 02:27:57PM +0100, Mark Brown wrote:
On Mon, Jun 22, 2020 at 08:31:18AM -0400, Sasha Levin wrote:
How come? This is one of the things stable rules explicitly call for: "New device IDs and quirks are also accepted".
I would expect that to be data only additions, I would not expect that to be adding new code.
These come hand in hand. Take a look at the more complex cases such as sound/pci/hda/patch_*
There are more complex cases, I'm just not sure how good an idea backporting them.
It would be much better to not have to watch stable constantly like we currently do - we're seeing people report breakage often enough to be a concern as things are, we don't need to be trying to pile extra stuff in there because there's some keywords in a changelog or whatever. The testing coverage for drivers is weak, increasing the change rate puts more stress on that.
Shouldn't we instead improve testing here? nvidia for example already provides Tegra testing for stable releases, if the coverage isn't sufficient then let's work on making it better.
Obviously it'd be good to improve the test coverage, but I think that's something that needs doing before backporting loads of stuff rather than after. For this automated stuff I'd much rather see positive confirmation that the change had been tested on relevant systems (not just something with a similar SoC), especially on the edges where we're getting to board specific things.
participants (2)
-
Mark Brown -
Sasha Levin