[alsa-devel] [PATCH 1/2] spitz: MONO -> MONO1
Signed-off-by: Dmitry Baryshkov dbaryshkov@gmail.com Cc: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/pxa/spitz.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/pxa/spitz.c b/sound/soc/pxa/spitz.c index 8f5c2ac..dff0f0e 100644 --- a/sound/soc/pxa/spitz.c +++ b/sound/soc/pxa/spitz.c @@ -303,7 +303,7 @@ static int spitz_wm8750_init(struct snd_soc_codec *codec) snd_soc_dapm_disable_pin(codec, "LINPUT3"); snd_soc_dapm_disable_pin(codec, "RINPUT3"); snd_soc_dapm_disable_pin(codec, "OUT3"); - snd_soc_dapm_disable_pin(codec, "MONO"); + snd_soc_dapm_disable_pin(codec, "MONO1");
/* Add spitz specific controls */ for (i = 0; i < ARRAY_SIZE(wm8750_spitz_controls); i++) {
Signed-off-by: Dmitry Baryshkov dbaryshkov@gmail.com Cc: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/codecs/wm8750.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/wm8750.c b/sound/soc/codecs/wm8750.c index 2e71394..c6a8edf 100644 --- a/sound/soc/codecs/wm8750.c +++ b/sound/soc/codecs/wm8750.c @@ -350,6 +350,7 @@ static const struct snd_soc_dapm_widget wm8750_dapm_widgets[] = { SND_SOC_DAPM_OUTPUT("ROUT2"), SND_SOC_DAPM_OUTPUT("MONO1"), SND_SOC_DAPM_OUTPUT("OUT3"), + SND_SOC_DAPM_OUTPUT("VREF"),
SND_SOC_DAPM_INPUT("LINPUT1"), SND_SOC_DAPM_INPUT("LINPUT2"),
On Mon, Aug 11, 2008 at 12:45:46PM +0400, Dmitry Baryshkov wrote:
Signed-off-by: Dmitry Baryshkov dbaryshkov@gmail.com Cc: Mark Brown broonie@opensource.wolfsonmicro.com
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
Not that we normally bother with these but it doesn't do any harm.
Mark Brown wrote:
On Mon, Aug 11, 2008 at 12:45:46PM +0400, Dmitry Baryshkov wrote:
Signed-off-by: Dmitry Baryshkov dbaryshkov@gmail.com Cc: Mark Brown broonie@opensource.wolfsonmicro.com
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
Not that we normally bother with these but it doesn't do any harm.
It does harm, because it's used in route tables. And as using it as a route dest fails, all further routing mapping aren't ever called.
On Mon, Aug 11, 2008 at 01:11:56PM +0400, Dmitry Baryshkov wrote:
It does harm, because it's used in route tables. And as using it as a route dest fails, all further routing mapping aren't ever called.
Hrm, so it is - fairly unusual.
Takashi, this is for stable too.
At Mon, 11 Aug 2008 11:19:40 +0100, Mark Brown wrote:
On Mon, Aug 11, 2008 at 01:11:56PM +0400, Dmitry Baryshkov wrote:
It does harm, because it's used in route tables. And as using it as a route dest fails, all further routing mapping aren't ever called.
Hrm, so it is - fairly unusual.
Takashi, this is for stable too.
You mean both patches (spitz: MONO -> MONO1 and wm8750: add missing VREF)? Anyway, a bit more detailed changelog is needed - what's broken in the real use and how fixed.
Dmitry, could you add more text and repost?
thanks,
Takashi
On Mon, Aug 11, 2008 at 12:37:45PM +0200, Takashi Iwai wrote:
You mean both patches (spitz: MONO -> MONO1 and wm8750: add missing VREF)? Anyway, a bit more detailed changelog is needed - what's broken in the real use and how fixed.
The long description is exactly what's broken - the names are wrong or undeclared and since DAPM works based on the control names this causes the drivers to fail to initialise DAPM for the device concerned. It's pretty much equivalent to C code referencing an undeclared variable.
At Mon, 11 Aug 2008 11:42:14 +0100, Mark Brown wrote:
On Mon, Aug 11, 2008 at 12:37:45PM +0200, Takashi Iwai wrote:
You mean both patches (spitz: MONO -> MONO1 and wm8750: add missing VREF)? Anyway, a bit more detailed changelog is needed - what's broken in the real use and how fixed.
The long description is exactly what's broken - the names are wrong or undeclared and since DAPM works based on the control names this causes the drivers to fail to initialise DAPM for the device concerned.
Exactly such a text should appear in the changelog.
It's pretty much equivalent to C code referencing an undeclared variable.
Everyone knows C syntax but not ASoC implementation details. If the patch is pushed to stable tree, it should be described well so that other reviewers can understand it well.
thanks,
Takashi
On Mon, Aug 11, 2008 at 12:45:32PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
The long description is exactly what's broken - the names are wrong or undeclared and since DAPM works based on the control names this causes the drivers to fail to initialise DAPM for the device concerned.
Exactly such a text should appear in the changelog.
Sure, my intention was to provide some appropriate text.
It's pretty much equivalent to C code referencing an undeclared variable.
Everyone knows C syntax but not ASoC implementation details. If the patch is pushed to stable tree, it should be described well so that other reviewers can understand it well.
Sorry, there may have been a miscommunication here - this should only *need* to go to 2.6.27 since the bulk registration functions are more careful about checking error values than the hand rolled loops tended to be. For earlier kernels people will either not notice or have already have local patches so the bugs are not quite so serious.
Obviously, it'd be good to fix for the earlier kernels but it's not clear it is critical enough for them.
At Mon, 11 Aug 2008 12:01:00 +0100, Mark Brown wrote:
On Mon, Aug 11, 2008 at 12:45:32PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
The long description is exactly what's broken - the names are wrong or undeclared and since DAPM works based on the control names this causes the drivers to fail to initialise DAPM for the device concerned.
Exactly such a text should appear in the changelog.
Sure, my intention was to provide some appropriate text.
It's pretty much equivalent to C code referencing an undeclared variable.
Everyone knows C syntax but not ASoC implementation details. If the patch is pushed to stable tree, it should be described well so that other reviewers can understand it well.
Sorry, there may have been a miscommunication here - this should only *need* to go to 2.6.27 since the bulk registration functions are more careful about checking error values than the hand rolled loops tended to be. For earlier kernels people will either not notice or have already have local patches so the bugs are not quite so serious.
Ah, OK. So it's not for stable. (A detailed changelog would be still better, though :)
Obviously, it'd be good to fix for the earlier kernels but it's not clear it is critical enough for them.
I see. Thanks for clarification.
thanks,
Takashi
On Mon, Aug 11, 2008 at 01:36:46PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
Sorry, there may have been a miscommunication here - this should only *need* to go to 2.6.27 since the bulk registration functions are more
Ah, OK. So it's not for stable. (A detailed changelog would be still better, though :)
Yeah, definitely.
It's one of these things that gets mildly confusing in the -rc cycle - from a development point of view there are bug fixes that should be cherry picked down into the next stable release (so bug fixes targetted at stable) but which don't go into the -stable process (which is a different thing again).
Hi,
Mark Brown wrote:
On Mon, Aug 11, 2008 at 12:37:45PM +0200, Takashi Iwai wrote:
You mean both patches (spitz: MONO -> MONO1 and wm8750: add missing VREF)? Anyway, a bit more detailed changelog is needed - what's broken in the real use and how fixed.
The long description is exactly what's broken - the names are wrong or undeclared and since DAPM works based on the control names this causes the drivers to fail to initialise DAPM for the device concerned. It's pretty much equivalent to C code referencing an undeclared variable.
I saw these patches got merged into asoc/dev tree. Should I repost them with more descriptive changelog, or are them suitable as is?
At Mon, 11 Aug 2008 18:16:28 +0400, Dmitry Baryshkov wrote:
Hi,
Mark Brown wrote:
On Mon, Aug 11, 2008 at 12:37:45PM +0200, Takashi Iwai wrote:
You mean both patches (spitz: MONO -> MONO1 and wm8750: add missing VREF)? Anyway, a bit more detailed changelog is needed - what's broken in the real use and how fixed.
The long description is exactly what's broken - the names are wrong or undeclared and since DAPM works based on the control names this causes the drivers to fail to initialise DAPM for the device concerned. It's pretty much equivalent to C code referencing an undeclared variable.
I saw these patches got merged into asoc/dev tree. Should I repost them with more descriptive changelog, or are them suitable as is?
I already merged the patch "wm8750: it's MONO1, not MONO", but other two are still pending. Please give some descriptions in the changelog to each of these two patches and repost.
thanks,
Takashi
On Mon, Aug 11, 2008 at 12:45:45PM +0400, Dmitry Baryshkov wrote:
Signed-off-by: Dmitry Baryshkov dbaryshkov@gmail.com Cc: Mark Brown broonie@opensource.wolfsonmicro.com
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
Could push this to stable but audio on the zaurus devices is broken anyway by the I2C controller registration which is blocked on rmk and not likely to go anywhere.
participants (4)
-
Dmitry Baryshkov -
Mark Brown -
Mark Brown -
Takashi Iwai