Re: [Alsa-devel] spin_lock_irqwhat ?
At Sat, 15 May 2004 23:37:47 +0200, Giuliano Pochini wrote: On Fri, 14 May 2004 12:37:46 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: prepare and trigger callbacks are already in irq-disabled. i.e. you need only spin_lock() in them. Does it mean that ALSA acquires the lock only when it calls PCM callbacks, that is trigger(), etc., are atomic only wrt other PCM functions ? sorry i don't understand your question. the prepare and the trigger callbacks acquire several locks. first, the global rw_lock for the pcm linking (snd_pcm_link_rwlock), the group lock the substream belongs to, and the lock for the substream itself. and the first lock/unlock is done with *_irq(). Ok, are those locks acquired also before calling any other interface callback (control, midi...) ? If so, it shouldn't be necessary protecting with a spin_lock() the code which touches the hw inside prepare(). no, all of these locks are specific to PCM. you still likely need another spinlock for protecting the h/w registers reading/writing. Takashi --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] spin_lock_irqwhat ?
At Thu, 13 May 2004 20:57:51 +0200, Giuliano Pochini wrote: On Mon, 10 May 2004 17:08:49 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: prepare and trigger callbacks are already in irq-disabled. i.e. you need only spin_lock() in them. Does it mean that ALSA acquires the lock only when it calls PCM callbacks, that is trigger(), etc., are atomic only wrt other PCM functions ? sorry i don't understand your question. the prepare and the trigger callbacks acquire several locks. first, the global rw_lock for the pcm linking (snd_pcm_link_rwlock), the group lock the substream belongs to, and the lock for the substream itself. and the first lock/unlock is done with *_irq(). hdsp.c and rme9652.x use spin_*lock_irq() inside prepare(). oh, it's wrong. fixed on cvs now. thanks, Takashi --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] spin_lock_irqwhat ?
On Mon, 10 May 2004 17:08:49 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: prepare and trigger callbacks are already in irq-disabled. i.e. you need only spin_lock() in them. Does it mean that ALSA acquires the lock only when it calls PCM callbacks, that is trigger(), etc., are atomic only wrt other PCM functions ? hdsp.c and rme9652.x use spin_*lock_irq() inside prepare(). -- Giuliano. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] spin_lock_irqwhat ?
On 10-May-2004 Takashi Iwai wrote: prepare and trigger callbacks are already in irq-disabled. i.e. you need only spin_lock() in them. [...] Fine. I moved SetSampleRate() from prepare() to the hw_params() callback because it may need to reload the firmware. -- Giuliano. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] spin_lock_irqwhat ?
On 10-May-2004 Takashi Iwai wrote: Some drivers use spin_lock_irq() a lot, while others always use spin_lock_irqsave(). I can't see the difference. When it's safe using the _irq() version ? Only when you know that you are not in interrupt context. also, not in the context which already disabled irq. Yes, I read the famous Rusty's unreliable guide. My question was ALSA-specific. The point is that I don't know when those conditions are true. Can and_pcm_period_elapsed() call anything other than the pcm callbacks ? Does the ALSA middle layer ever disable interrupts before calling a driver function ? If it doesn't, I can replace spin_lock_irqsave() with spin_lock_irq() almost everything. Some callbacks are atomic according to the tutorial, but it doesn't say if interrupts are disabled too. Are irq (and preempt) disabled before calling .prepare and .trigger callbacks ? -- Giuliano. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] spin_lock_irqwhat ?
At Mon, 10 May 2004 16:51:24 +0200 (CEST), Giuliano Pochini wrote: On 10-May-2004 Takashi Iwai wrote: Some drivers use spin_lock_irq() a lot, while others always use spin_lock_irqsave(). I can't see the difference. When it's safe using the _irq() version ? Only when you know that you are not in interrupt context. also, not in the context which already disabled irq. Yes, I read the famous Rusty's unreliable guide. My question was ALSA-specific. The point is that I don't know when those conditions are true. Can and_pcm_period_elapsed() call anything other than the pcm callbacks ? Does the ALSA middle layer ever disable interrupts before calling a driver function ? If it doesn't, I can replace spin_lock_irqsave() with spin_lock_irq() almost everything. Some callbacks are atomic according to the tutorial, but it doesn't say if interrupts are disabled too. Are irq (and preempt) disabled before calling .prepare and .trigger callbacks ? prepare and trigger callbacks are already in irq-disabled. i.e. you need only spin_lock() in them. also, ioctl(SNDRV_PCM_IOCTL1_RESET) is in the irq-disabled context. others are not. some points to be noted: - prepare can be non-atomic by setting SNDRV_PCM_INFO_NONATOMIC_OPS to pcm-info_flags. (e.g. usbaudio.c) - pointer callback is not protected. but it's called also in the interrupt context, so you can't use spin_lock_irq() in general. Takashi --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] spin_lock_irqwhat ?
Giuliano Pochini wrote: Some drivers use spin_lock_irq() a lot, while others always use spin_lock_irqsave(). I can't see the difference. When it's safe using the _irq() version ? Only when you know that you are not in interrupt context. Regards, Clemens --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] spin_lock_irqwhat ?
At Mon, 10 May 2004 10:31:07 +0200 (METDST), Clemens Ladisch wrote: Giuliano Pochini wrote: Some drivers use spin_lock_irq() a lot, while others always use spin_lock_irqsave(). I can't see the difference. When it's safe using the _irq() version ? Only when you know that you are not in interrupt context. also, not in the context which already disabled irq. Takashi --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
