Interrupt Handler

Interrupt Handler

[sanket rathi]

Hi,
I am writing a device driver for a pci card i know that whenever u r writing a interrupt handler there are some restrictions. like u cannot acquire a lock, u can't sleep but i want to know, is there some restriction like i can't use buffers which i have allocated through vmalloc. actually i allocated some structure through vmalloc in init_module() and referencing them in interrupt handler will that create some problem.

Thanks in advance

----Sanket
-------------
-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

Re: interrupt handler

[Kerenyi Gabor]

8/23/2002 8:58:20 PM, "sanket rathi" <sanket@linuxmail.org> wrote:

>hi,
>Can i use spin lock in the interrupt handler for a singlre processor machine. because books says u can not use locks 
>but spin lock is some thing diffrent 

Yes you can. Spinlocks will be compiled in if you choose SMP even on single processor machine.
But look at the documentation in the kernel source.
I think "lock" in your message is a semaphore in real life.

Spinlocks never sleep - they don't perform task switch and you can use them anywhere, while semaphores
can sleep and you can use them only in user context (not in interrupt or bottom half)

Gabor

Re: interrupt handler

[Kerenyi Gabor]

8/23/2002 9:17:07 PM, "Richard B. Johnson" <root@chaos.analogic.com> wrote:

>On Fri, 23 Aug 2002, sanket rathi wrote:
>
>> hi,
>> Can i use spin lock in the interrupt handler for a singlre processor
>> machine. because books says u can not use locks but spin lock is some
>> thing diffrent 
>> 
>> thanks in advance
>> 
>> --Sanket
>> ---------
>
>Interrupts default to OFF within an interrupt handler. Given this,
>why would you use a spin-lock within the ISR on a single-processor
>machine?

Because he would like to write a code that can be run on a computer
with more than one CPU. 

Anyway, do anybody know what kind of advantages/disadvantages I can get
if I don't disable interrupts at all in my driver? Even if I have to use a circular
buffer or anything else? Is it worth trying to find such a solution or is it
a wasted time?

Gabor

Re: interrupt handler

[Kerenyi Gabor]

8/23/2002 10:07:54 PM, "Richard B. Johnson" <root@chaos.analogic.com> wrote:

>On Fri, 23 Aug 2002, Kerenyi Gabor wrote:
>> Anyway, do anybody know what kind of advantages/disadvantages I can get
>> if I don't disable interrupts at all in my driver? Even if I have to
>> use a circular
>> buffer or anything else? Is it worth trying to find such a solution or is it
>> a wasted time?
>> 
>> Gabor
>
>If your ISR manipulates any data, which is quite likely, then
>your driver code, that is outside the ISR, must be written
>with the knowledge that an interrupt can happen at any time.

Well I wrote it in this way of course.

>There are probably certain critical regions of code that must
>be protected against modification from the ISR code. You need
>to protect those critical regions with spin-locks.

I know. But there are some technics that can be used to workaorund
the irq disabling thing.

>Spin-locks have very little code. If there is no contention,
>they do not affect performance in any measurable way. If there
>is contention, they simply delay execution of the ISR to a time
>where code is executing in a non-critical section. This delay
>is necessary so, even though it does affect performance, the
>system would not work without it.

I talked about irq disabling, not spinlocks. With or without spinlocks.
When you need synch between a bottom half(or user context) and irq
handler on single processor machine you can't use just spinlocks. you have to
disable the irq. so the question is about irq disabling to modify data
in a mutual way.
I solved it without disabling irq using a circular buffer (very simple one)
I think with this solution there is a better response time for the hardware
items. (they can get immediate response from the OS)

Gabor

interrupt handler

[sanket rathi]

hi,
Can i use spin lock in the interrupt handler for a singlre processor machine. because books says u can not use locks but spin lock is some thing diffrent 

thanks in advance

--Sanket
---------
-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

Re: interrupt handler

[Richard B. Johnson]

On Fri, 23 Aug 2002, sanket rathi wrote:

> hi,
> Can i use spin lock in the interrupt handler for a singlre processor
> machine. because books says u can not use locks but spin lock is some
> thing diffrent 
> 
> thanks in advance
> 
> --Sanket
> ---------

Interrupts default to OFF within an interrupt handler. Given this,
why would you use a spin-lock within the ISR on a single-processor
machine?

To directly answer your question, YES, you can use a spin-lock
within an ISR even though it won't do anything except add code
on a single processor machine.

On multiple CPU machines, you can use the form of spin-lock that
does not save/restore interrupts within the ISR, and use the
save/restore versions, with the same lock variable, outside the
ISR.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: interrupt handler

[Richard B. Johnson]

On Fri, 23 Aug 2002, Kerenyi Gabor wrote:

> 8/23/2002 9:17:07 PM, "Richard B. Johnson" <root@chaos.analogic.com> wrote:
> 
> >On Fri, 23 Aug 2002, sanket rathi wrote:
> >
> >> hi,
> >> Can i use spin lock in the interrupt handler for a singlre processor
> >> machine. because books says u can not use locks but spin lock is some
> >> thing diffrent 
> >> 
> >> thanks in advance
> >> 
> >> --Sanket
> >> ---------
> >
> >Interrupts default to OFF within an interrupt handler. Given this,
> >why would you use a spin-lock within the ISR on a single-processor
> >machine?
> 
> Because he would like to write a code that can be run on a computer
> with more than one CPU. 
> 
> Anyway, do anybody know what kind of advantages/disadvantages I can get
> if I don't disable interrupts at all in my driver? Even if I have to
> use a circular
> buffer or anything else? Is it worth trying to find such a solution or is it
> a wasted time?
> 
> Gabor

If your ISR manipulates any data, which is quite likely, then
your driver code, that is outside the ISR, must be written
with the knowledge that an interrupt can happen at any time.

There are probably certain critical regions of code that must
be protected against modification from the ISR code. You need
to protect those critical regions with spin-locks.

Spin-locks have very little code. If there is no contention,
they do not affect performance in any measurable way. If there
is contention, they simply delay execution of the ISR to a time
where code is executing in a non-critical section. This delay
is necessary so, even though it does affect performance, the
system would not work without it.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: interrupt handler

[Robert Love]

On Fri, 2002-08-23 at 08:17, Richard B. Johnson wrote:

> Interrupts default to OFF within an interrupt handler. Given this,
> why would you use a spin-lock within the ISR on a single-processor
> machine?

Only the current interrupt handler is disabled... interrupts are
normally ON.

	Robert Love

Re: interrupt handler

[Richard B. Johnson]

On 23 Aug 2002, Robert Love wrote:

> On Fri, 2002-08-23 at 08:17, Richard B. Johnson wrote:
> 
> > Interrupts default to OFF within an interrupt handler. Given this,
> > why would you use a spin-lock within the ISR on a single-processor
> > machine?
> 
> Only the current interrupt handler is disabled... interrupts are
> normally ON.
> 
> 	Robert Love

No. Check out irq.c, line 446. The interrupts are turned back on
only if the flag did not have SA_INTERRUPT set. Certainly most
requests for interrupt services within drivers have SA_INTERRUPT
set.

This is linux-2.4.18 or 2.4.19. If the current code, 2.5+ enables
by default, it's broken and should be fixed.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: interrupt handler

[Robert Love]

On Fri, 2002-08-23 at 12:45, Richard B. Johnson wrote:

> On 23 Aug 2002, Robert Love wrote:
> > Only the current interrupt handler is disabled... interrupts are
> > normally ON.
> 
> No. Check out irq.c, line 446. The interrupts are turned back on
> only if the flag did not have SA_INTERRUPT set. Certainly most
> requests for interrupt services within drivers have SA_INTERRUPT
> set.

Sigh... SA_INTERRUPT is used only for fast interrupts.  Certainly most
drivers do not have it (and most that do are probably from the way old
days when we went through great pains to distinguish between fast and
slow interrupt handlers).

Today, very few things should run with all interrupts disabled.  That is
just dumb.  In fact, on this system, it seems only the timer interrupt
sets SA_INTERRUPT...

	Robert Love

Re: interrupt handler

[george anzinger]

Robert Love wrote:
> 
> On Fri, 2002-08-23 at 12:45, Richard B. Johnson wrote:
> 
> > On 23 Aug 2002, Robert Love wrote:
> > > Only the current interrupt handler is disabled... interrupts are
> > > normally ON.
> >
> > No. Check out irq.c, line 446. The interrupts are turned back on
> > only if the flag did not have SA_INTERRUPT set. Certainly most
> > requests for interrupt services within drivers have SA_INTERRUPT
> > set.
> 
> Sigh... SA_INTERRUPT is used only for fast interrupts.  Certainly most
> drivers do not have it (and most that do are probably from the way old
> days when we went through great pains to distinguish between fast and
> slow interrupt handlers).
> 
> Today, very few things should run with all interrupts disabled.  That is
> just dumb.  In fact, on this system, it seems only the timer interrupt
> sets SA_INTERRUPT...
> 
And THAT makes sense as most of the timer interrupt is
processed holding the write_lock() on xtime which would need
to be an irq lock otherwise.  If they were turned on the
system would have an additional interrupts on/off overhead.

>         Robert Love
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Interrupt handler

[Giuliano Pochini]

When an interrupt arrives and I call snd_pcm_period_elapsed(), what
function gets from alsa middle layer the new block to play and sets up
the hardware ?

Bye.




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

RE: Interrupt handler

[Giuliano Pochini]

> When an interrupt arrives and I call snd_pcm_period_elapsed(), what
> function gets from alsa middle layer the new block to play and sets up
> the hardware ?

Ok, nobody answered, perhaps my question was too stupid :))
I still haven't found in the docs how can I get from ALSA the
address of the blocks to play/record, or how to tell ALSA where
it the space I allocated so it knows where it has to write the
audio data to be played.
I can build a very generic scatter-gather list. It has three
instructions: addr/length, generate interrupt, jump. Per example
I can write an sg list like this to emulate the cyclic buffer of
many soundblaster cards:

start:
addr0/len0
Irq
addr1/len1
Irq
goto start



Bye.



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Interrupt handler

[Takashi Iwai]

At Mon, 17 Mar 2003 10:17:04 +0100 (CET),
Giuliano Pochini wrote:
> 
> 
> > When an interrupt arrives and I call snd_pcm_period_elapsed(), what
> > function gets from alsa middle layer the new block to play and sets up
> > the hardware ?
> 
> Ok, nobody answered, perhaps my question was too stupid :))

both of Jaroslav and I were absent since the last friday to attend at
the LAD meeting...

> I still haven't found in the docs how can I get from ALSA the
> address of the blocks to play/record, or how to tell ALSA where
> it the space I allocated so it knows where it has to write the
> audio data to be played.

first, the data is not necessarily as a block on ALSA.
and second, you don't have to copy the data as long as the hardware
supports DMA on the host memory.  the alsa middle layer does this
job.

usually in the interrupt handler, you need to just send "ack" to the
middle layer by calling snd_pcm_period_elapsed().  then, the
middle-layer checks the current position by calling pointer callback,
and copy/send/set-silence in the necessary area.

the pointer callback, thus, must return the current position of the
hardware pointer, i.e. the position offset (in frames) in the DMA
buffer, where the DMA is working right now (or the last finished
positoin, if you cannot get the current DMA pointer due to the
hardware limitation).


Takashi


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Interrupt handler

[Giuliano Pochini]

On 17-Mar-2003 Takashi Iwai wrote:
> usually in the interrupt handler, you need to just send "ack" to the
> middle layer by calling snd_pcm_period_elapsed().  then, the
> middle-layer checks the current position by calling pointer callback,
> and copy/send/set-silence in the necessary area.

I didn't realize the role of .pointer callback. Tnx.

In hw_params callback I build the hardware sg list according
to sgbuf->table. Then I have to set the card to play the list
in a neverending loop and to issue an irq at the and of each
period. Is it right ?


Bye.



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Interrupt handler

[Takashi Iwai]

At Mon, 17 Mar 2003 15:22:45 +0100 (CET),
Giuliano Pochini wrote:
> 
> 
> On 17-Mar-2003 Takashi Iwai wrote:
> > usually in the interrupt handler, you need to just send "ack" to the
> > middle layer by calling snd_pcm_period_elapsed().  then, the
> > middle-layer checks the current position by calling pointer callback,
> > and copy/send/set-silence in the necessary area.
> 
> I didn't realize the role of .pointer callback. Tnx.
> 
> In hw_params callback I build the hardware sg list according
> to sgbuf->table. Then I have to set the card to play the list
> in a neverending loop and to issue an irq at the and of each
> period. Is it right ?

yes.

also, don't forget to unlock the spinlock during calling
snd_pcm_period_elapsed() if a single lock is used for callbacks.
as mentioned above, snd_pcm_period_elapsed() will call pointer
callback.  if you call snd_pcm_period_elapsed() inside the spinlock,
this may result in a deadlock.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Interrupt handler

[Giuliano Pochini]

On mar, 2003-03-18 at 13:32, Takashi Iwai wrote:
> also, don't forget to unlock the spinlock during calling
> snd_pcm_period_elapsed() if a single lock is used for callbacks.

Yes, I'm following the tutorial and it's clear about that.

Now I have another weird problem. This is a peice of my hw_param
function:

static int pcm_hw_params(){
  printk("pcm_hw_params bytes=%d\n",params_buffer_bytes(hw_params));
  for (per=0; per<params_periods(hw_params); per++) {
    printk("pcm_hw_params Add%d (%x - %d)\n",
            per,
            sgbuf->table[per].addr,
            params_period_bytes(hw_params));
  }
}

Mar 19 00:48:33 localhost kernel: pcm_hw_params bytes=44100
Mar 19 00:48:33 localhost kernel: pcm_hw_params Add0 (3a1d000 - 11026)
Mar 19 00:48:33 localhost kernel: pcm_hw_params Add1 (3a1c000 - 11026)
Mar 19 00:48:33 localhost kernel: pcm_hw_params Add2 (3a1b000 - 11026)
Mar 19 00:48:33 localhost kernel: pcm_hw_params OK

Look at the physical addresses. They're spaced by 4KB, but the periods
are 11KB long and 11026*3<44100 !! You can imagine how beatiful sound I
get... What am I missing ?


Bye.




-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Interrupt handler

[Giuliano Pochini]

> Look at the physical addresses. They're spaced by 4KB, but the periods
> are 11KB long and 11026*3<44100 !! You can imagine how beatiful sound I
> get... What am I missing ?

Ehm, I found the problem, ignore my previous msg.


Bye.




-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Interrupt handler

[MNH]

hi,

I have a general question.

If a process is executing a system call, and an interrupt is invoked,
the process blocks. Now since interrupt handlers cannot block, the time
for which the IH runs is taken out of the process's time-slice ( Is this
right ?).

What if the IH takes up all of the process's time-slice, does the
process gets knocked off the current list and thrown into the expired
list or is there something more to it?

thanks for your time

Re: Interrupt handler

[Karim Yaghmour]

MNH wrote:
> If a process is executing a system call, and an interrupt is invoked,
> the process blocks. Now since interrupt handlers cannot block, the time
> for which the IH runs is taken out of the process's time-slice ( Is this
> right ?).
> 
> What if the IH takes up all of the process's time-slice, does the
> process gets knocked off the current list and thrown into the expired
> list or is there something more to it?

This is the kind of thing LTT will allow you to see:
http://www.opersys.com/LTT/

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546