[alsa-devel] Merged upstream to topic/asoc branch
Hi,
FYI, I merged the current Linus tree back to topic/asoc branch on sound git tree for clean-up works including the latest commit in sound/soc/fsl.
If you have any problems with it, please let me know.
thanks,
Takashi
At Mon, 01 Dec 2008 18:00:04 +0100, I wrote:
Hi,
FYI, I merged the current Linus tree back to topic/asoc branch on sound git tree for clean-up works including the latest commit in sound/soc/fsl.
Oops, there was the latest update of sound/sparc on Linus tree, so I re-merged again...
Takashi
On Mon, Dec 01, 2008 at 06:00:04PM +0100, Takashi Iwai wrote:
FYI, I merged the current Linus tree back to topic/asoc branch on sound git tree for clean-up works including the latest commit in sound/soc/fsl.
If you have any problems with it, please let me know.
Hrm. Which compiler are you using? The WM8903 warning patch you introduced is not needed on any of my systems (primarily ARM and x86-64). It smells like a problem with the BUG() definition on your platform...
At Mon, 1 Dec 2008 17:06:34 +0000, Mark Brown wrote:
On Mon, Dec 01, 2008 at 06:00:04PM +0100, Takashi Iwai wrote:
FYI, I merged the current Linus tree back to topic/asoc branch on sound git tree for clean-up works including the latest commit in sound/soc/fsl.
If you have any problems with it, please let me know.
Hrm. Which compiler are you using?
gcc-4.1 for ARM, if I remember correctly...
The WM8903 warning patch you introduced is not needed on any of my systems (primarily ARM and x86-64). It smells like a problem with the BUG() definition on your platform...
Possibly. I'm not pretty sure on which systems, since I run test-builds regularly for ARM, PPC, x86 and x86-64 with cross compilers.
thanks,
Takashi
On Mon, Dec 01, 2008 at 06:14:12PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
Hrm. Which compiler are you using?
gcc-4.1 for ARM, if I remember correctly...
I'm at 4.2.4 for ARM.
The WM8903 warning patch you introduced is not needed on any of my systems (primarily ARM and x86-64). It smells like a problem with the BUG() definition on your platform...
Possibly. I'm not pretty sure on which systems, since I run test-builds regularly for ARM, PPC, x86 and x86-64 with cross compilers.
Could you investigate, please? I'd rather not add annotations like that since they mask genuine compiler warnings and are liable to crop up elsewhere. That particular function isn't likely to change but I'm worried in case this sort of thing starts cropping up elsewhere.
For that particular function I'd rather add return statements after the BUG()s...
As far as I'm aware the current ASoC code is warning free.
At Mon, 1 Dec 2008 17:24:55 +0000, Mark Brown wrote:
On Mon, Dec 01, 2008 at 06:14:12PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
Hrm. Which compiler are you using?
gcc-4.1 for ARM, if I remember correctly...
I'm at 4.2.4 for ARM.
The WM8903 warning patch you introduced is not needed on any of my systems (primarily ARM and x86-64). It smells like a problem with the BUG() definition on your platform...
Possibly. I'm not pretty sure on which systems, since I run test-builds regularly for ARM, PPC, x86 and x86-64 with cross compilers.
Could you investigate, please? I'd rather not add annotations like that since they mask genuine compiler warnings and are liable to crop up elsewhere. That particular function isn't likely to change but I'm worried in case this sort of thing starts cropping up elsewhere.
For that particular function I'd rather add return statements after the BUG()s...
Yes, this would work, too.
As far as I'm aware the current ASoC code is warning free.
OK, I'll test through all builds again.
Takashi
At Mon, 01 Dec 2008 18:32:27 +0100, I wrote:
At Mon, 1 Dec 2008 17:24:55 +0000, Mark Brown wrote:
On Mon, Dec 01, 2008 at 06:14:12PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
Hrm. Which compiler are you using?
gcc-4.1 for ARM, if I remember correctly...
I'm at 4.2.4 for ARM.
The WM8903 warning patch you introduced is not needed on any of my systems (primarily ARM and x86-64). It smells like a problem with the BUG() definition on your platform...
Possibly. I'm not pretty sure on which systems, since I run test-builds regularly for ARM, PPC, x86 and x86-64 with cross compilers.
Could you investigate, please? I'd rather not add annotations like that since they mask genuine compiler warnings and are liable to crop up elsewhere. That particular function isn't likely to change but I'm worried in case this sort of thing starts cropping up elsewhere.
For that particular function I'd rather add return statements after the BUG()s...
Yes, this would work, too.
As far as I'm aware the current ASoC code is warning free.
OK, I'll test through all builds again.
Oh, BTW, the following fix is also still pending on my local queue.
===
From: Takashi Iwai tiwai@suse.de Subject: ALSA: ASoC: Fix compile warnings on corgi.c
sound/soc/pxa/corgi.c: In function 'corgi_shutdown': sound/soc/pxa/corgi.c:114: warning: unused variable 'codec' sound/soc/pxa/corgi.c: At top level: sound/soc/pxa/corgi.c:175: warning: initialization from incompatible pointer type
Signed-off-by: Takashi Iwai tiwai@suse.de
--- diff --git a/sound/soc/pxa/corgi.c b/sound/soc/pxa/corgi.c index 647f056..e56bf4b 100644 --- a/sound/soc/pxa/corgi.c +++ b/sound/soc/pxa/corgi.c @@ -108,15 +108,11 @@ static int corgi_startup(struct snd_pcm_substream *substream) }
/* we need to unmute the HP at shutdown as the mute burns power on corgi */ -static int corgi_shutdown(struct snd_pcm_substream *substream) +static void corgi_shutdown(struct snd_pcm_substream *substream) { - struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct snd_soc_codec *codec = rtd->socdev->codec; - /* set = unmute headphone */ gpio_set_value(CORGI_GPIO_MUTE_L, 1); gpio_set_value(CORGI_GPIO_MUTE_R, 1); - return 0; }
static int corgi_hw_params(struct snd_pcm_substream *substream,
On Mon, Dec 01, 2008 at 06:37:17PM +0100, Takashi Iwai wrote:
Oh, BTW, the following fix is also still pending on my local queue.
That fix looks good, I don't regularly track the Zaurii since keeping track of the build failures in mainline was more trouble than it was worth last time I tried.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
At Mon, 1 Dec 2008 17:42:52 +0000, Mark Brown wrote:
On Mon, Dec 01, 2008 at 06:37:17PM +0100, Takashi Iwai wrote:
Oh, BTW, the following fix is also still pending on my local queue.
That fix looks good, I don't regularly track the Zaurii since keeping track of the build failures in mainline was more trouble than it was worth last time I tried.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
OK. I also applied one more fix below.
Takashi
=== From 682d5874f3d654b5d13d9b8dd56b9e05cfadd01b Mon Sep 17 00:00:00 2001 From: Takashi Iwai tiwai@suse.de Date: Mon, 1 Dec 2008 20:03:54 +0100 Subject: [PATCH] ALSA: ASoC: Fix old-style trigger callback in s3c2443-ac97.c
Fix the old-style trigger callback in s3c2443-ac97.c: sound/soc/s3c24xx/s3c2443-ac97.c:378: warning: initialization from incompatible pointer type
Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/soc/s3c24xx/s3c2443-ac97.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c2443-ac97.c b/sound/soc/s3c24xx/s3c2443-ac97.c index 41bde6a..f0bc9b7 100644 --- a/sound/soc/s3c24xx/s3c2443-ac97.c +++ b/sound/soc/s3c24xx/s3c2443-ac97.c @@ -285,7 +285,8 @@ static int s3c2443_ac97_hw_params(struct snd_pcm_substream *substream, return 0; }
-static int s3c2443_ac97_trigger(struct snd_pcm_substream *substream, int cmd) +static int s3c2443_ac97_trigger(struct snd_pcm_substream *substream, int cmd, + struct snd_soc_dai *dai) { u32 ac_glbctrl;
At Mon, 01 Dec 2008 18:32:27 +0100, I wrote:
At Mon, 1 Dec 2008 17:24:55 +0000, Mark Brown wrote:
On Mon, Dec 01, 2008 at 06:14:12PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
Hrm. Which compiler are you using?
gcc-4.1 for ARM, if I remember correctly...
I'm at 4.2.4 for ARM.
The WM8903 warning patch you introduced is not needed on any of my systems (primarily ARM and x86-64). It smells like a problem with the BUG() definition on your platform...
Possibly. I'm not pretty sure on which systems, since I run test-builds regularly for ARM, PPC, x86 and x86-64 with cross compilers.
Could you investigate, please? I'd rather not add annotations like that since they mask genuine compiler warnings and are liable to crop up elsewhere. That particular function isn't likely to change but I'm worried in case this sort of thing starts cropping up elsewhere.
For that particular function I'd rather add return statements after the BUG()s...
Yes, this would work, too.
As far as I'm aware the current ASoC code is warning free.
OK, I'll test through all builds again.
Through all builds, I couldn't reproduce the warnings again. So I reverted the commit. Sorry for noises.
Takashi
participants (2)
-
Mark Brown
-
Takashi Iwai