soc - fsl_ssi.c fix "BUG: scheduling while atomic"
Subsystems (3)
PATCH 1/1 soc - fsl_ssi.c fix "BUG: scheduling while atomic"
This patch fixes following bug caught with PREEMPT enabled:
root@b1:~# cat /dev/dsp > /dev/null
BUG: scheduling while atomic: cat/965/0x00000003
Call Trace:
[df165ce0] [c0008e84] show_stack+0x4c/0x1ac (unreliable)
[df165d20] [c001c18c] __schedule_bug+0x64/0x78
[df165d30] [c02b3344] schedule+0x2d8/0x334
[df165d70] [c02b3674] schedule_timeout+0x64/0xe4
[df165db0] [c002c05c] msleep+0x1c/0x34
[df165dc0] [c01f2fe0] fsl_ssi_trigger+0x130/0x144
[df165dd0] [c01ece54] soc_pcm_trigger+0x94/0xb8
[df165df0] [c01da764] snd_pcm_do_start+0x48/0x60
[df165e00] [c01da630] snd_pcm_action_single+0x4c/0xb4
[df165e20] [c01e0f50] snd_pcm_lib_read1+0x2a0/0x2d4
[df165e70] [c01ec274] snd_pcm_oss_read3+0xf0/0x13c
[df165eb0] [c01ec2e4] snd_pcm_oss_read2+0x24/0x4c
[df165ec0] [c01ec4ac] snd_pcm_oss_read+0x1a0/0x1f0
[df165ef0] [c0076478] vfs_read+0xb4/0x108
[df165f10] [c00768cc] sys_read+0x4c/0x90
[df165f40] [c00117a4] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfe9a8d4
LR = 0x10002b24We must not sleep with irqs disabled, so replace msleep with mdelay.
--- sound/soc/fsl/fsl_ssi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
sound/soc/fsl/fsl_ssi.c +1 -1
@@ -416,7 +416,7 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd)* to put data into its FIFO. Without it, ALSA starts * to complain about overruns. */ -msleep (1 ); +mdelay (1 ); }break ;
Signature · 1 line
1.5.5.1
Quoted 3 lines · Anton Vorontsov
We must not sleep with irqs disabled, so replace msleep with mdelay.
Signed-off-by Anton Vorontsov <[email protected]>
Anton, can you try testing the code with the call to mdelay/msleep commented out? On my quick test, I didn't need it, so I have a suspicion that it was needed only for the old 1.0 silicon.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 10 lines · Timur Tabi
Quoted 3 lines · Anton Vorontsov
We must not sleep with irqs disabled, so replace msleep with mdelay.
Signed-off-by Anton Vorontsov <[email protected]>Acked-by Timur Tabi <[email protected]>Anton, can you try testing the code with the call to mdelay/msleep commented out?
Ok, I'll try...
Quoted 2 lines
On my quick test, I didn't need it, so I have a suspicion that it was needed only for the old 1.0 silicon.
Are there any drawbacks of mdelay'ing? Since some silicons need this we'd better leave it then.
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
Quoted 1 line · Anton Vorontsov
Are there any drawbacks of mdelay'ing?
All I remember is that without the delay, it wouldn't work. But that was a long time ago, and I never revisited the issue, even after the silicon was updated.
Quoted 2 lines
Since some silicons need this
we'd better leave it then.
The 1.0 silicon is dead and won't work with this driver anyway. We should still leave it in for now, but I plan on doing thorough testing without it. If the driver still works, I'll remove it for ASoC V2.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale