spin_lock_irqwhat ?

spin_lock_irqwhat ?

[Giuliano Pochini]

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 ?



--
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

Re: spin_lock_irqwhat ?

[Clemens Ladisch]

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

Re: spin_lock_irqwhat ?

[Takashi Iwai]

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

Re: spin_lock_irqwhat ?

[Giuliano Pochini]

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

Re: spin_lock_irqwhat ?

[Takashi Iwai]

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

Re: spin_lock_irqwhat ?

[Giuliano Pochini]

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=2562&alloc_id=6184&op=click

Re: spin_lock_irqwhat ?

[Giuliano Pochini]

On Mon, 10 May 2004 17:08:49 +0200
Takashi Iwai <tiwai@suse.de> 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=2562&alloc_id=6184&op=click

Re: spin_lock_irqwhat ?

[Takashi Iwai]

At Thu, 13 May 2004 20:57:51 +0200,
Giuliano Pochini wrote:
> 
> 
> On Mon, 10 May 2004 17:08:49 +0200
> Takashi Iwai <tiwai@suse.de> 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=2562&alloc_id=6184&op=click

Re: spin_lock_irqwhat ?

[Giuliano Pochini]

On Fri, 14 May 2004 12:37:46 +0200
Takashi Iwai <tiwai@suse.de> 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().



--
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=2562&alloc_id=6184&op=click

Re: spin_lock_irqwhat ?

[Takashi Iwai]

At Sat, 15 May 2004 23:37:47 +0200,
Giuliano Pochini wrote:
> 
> On Fri, 14 May 2004 12:37:46 +0200
> Takashi Iwai <tiwai@suse.de> 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=2562&alloc_id=6184&op=click