A spinlock_irqsave question

A spinlock_irqsave question

[Ryan]

Hi,

I have a question on spinlock_irqsave api. Am not sure if this is the
right place to ask.
Any help is highly appreciated.


let me know if my understanding is correct?



spinlock_irqsave()  <== Disables the IRQ?

                            <== No IRQs (that means no KB
interrupt,Interrupts from touch screen... etc..)



spinlock_irqrestore()


Is my understanding correct?
So the "time spend between spinlock_irqsave and spinlock_restore
should be very short?

For example there should not be something like this? Am i correct?


spinlock_irqsave()

mdelay(1000);


spinlock_irqrestore()




Also, what is meant by "spinlock_irqsave" disabled irq locally?


What is locally here?




Thanks,
Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: A spinlock_irqsave question

[Mario Smarduch]

On 4/29/2013 10:30 AM, Ryan wrote:

> 
> 
> 
> spinlock_irqsave()  <== Disables the IRQ?
> 
>                             <== No IRQs (that means no KB
> interrupt,Interrupts from touch screen... etc..)
> 
> 
> 
> spinlock_irqrestore()
spin_lock_irqsave(lock,flags)/ affects the running
CPU, it does not disable any device IRQ. Device
interrupts may be taken by other CPUs. There is a whole
other set of calls that deal with individual IRQs.

> 
> 
> Is my understanding correct?
> So the "time spend between spinlock_irqsave and spinlock_restore
> should be very short?
> 
> For example there should not be something like this? Am i correct?
> 
> 
> spinlock_irqsave()
> 
> mdelay(1000);
> 
> 
> spinlock_irqrestore()

Yes, but much shorter then mdelay(1000)
> 
> 
> 
> 
> Also, what is meant by "spinlock_irqsave" disabled irq locally?

spin_lock_irqsave()disables interrupts on the CPU it's issued.




--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: A spinlock_irqsave question

[Ryan]

On Mon, Apr 29, 2013 at 2:42 PM, Mario Smarduch
<mario.smarduch@huawei.com> wrote:
> On 4/29/2013 10:30 AM, Ryan wrote:
>
>>
>>
>>
>> spinlock_irqsave()  <== Disables the IRQ?
>>
>>                             <== No IRQs (that means no KB
>> interrupt,Interrupts from touch screen... etc..)
>>
>>
>>
>> spinlock_irqrestore()
> spin_lock_irqsave(lock,flags)/ affects the running
> CPU, it does not disable any device IRQ. Device
> interrupts may be taken by other CPUs. There is a whole
> other set of calls that deal with individual IRQs.

You mean to say that
      a) Device IRQ can be taken care of some other core of the Same CPU?
      b) If the CPU Load is Less. then only one core will be active.
In that case - The device irq will be blocked?


>
>>
>>
>> Is my understanding correct?
>> So the "time spend between spinlock_irqsave and spinlock_restore
>> should be very short?
>>
>> For example there should not be something like this? Am i correct?
>>
>>
>> spinlock_irqsave()
>>
>> mdelay(1000);
>>
>>
>> spinlock_irqrestore()
>
> Yes, but much shorter then mdelay(1000)
>>
>>
>>
>>
>> Also, what is meant by "spinlock_irqsave" disabled irq locally?
>
> spin_lock_irqsave()disables interrupts on the CPU it's issued.

This also include device irqs right? Apart from device irqs (touch
screen and so on).
what other irqs can be there. So what about mdelay(1000) in the above?
does that effect performance.

>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: A spinlock_irqsave question

[Mario Smarduch]

On 4/29/2013 11:21 AM, Ryan wrote:
>> spin_lock_irqsave(lock,flags)/ affects the running
>> > CPU, it does not disable any device IRQ. Device
>> > interrupts may be taken by other CPUs. There is a whole
>> > other set of calls that deal with individual IRQs.
> You mean to say that
>       a) Device IRQ can be taken care of some other core of the Same CPU?
>       b) If the CPU Load is Less. then only one core will be active.
> In that case - The device irq will be blocked?
> 
> 

I don't understand (a), in SMP you may disable IRQs on a CPU
(via *_irqsave()) but other CPUs may continue to receive interrupts.
The CPU load has nothing to do with blocking IRQs (on vanilla kernel)
To disable device IRQ you must disable it at the interrupt controller
level like disable_irq().
 

--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: A spinlock_irqsave question

[Ryan]

Hi Mario,
   Thanks for your inputs. I understood the diabling the irq on the
local CPU by spinlock_irqsave function.

   Can you also explain why should someone use spinlock_irqsave
instead of spinlock call.
   Why someone would want to also disable interrupts while holding a spinlock.

   One situation i can think of is as using spinlock_irqsave inside an
interrupt handler. Is this correct.
   But i also read that when one interrupt handler is being processed
- Linux will mask the same interrupt handler from being called again
until the current one has finished processing.
   that is  - Until the processing of interrupt handler is complete.
Linux will disable the future interrupts of the same type.
   In that case why should be disable interrupts by calling (
spinlock_irqsave) and use only spin_lock call alone.


Thanks


On Tue, Apr 30, 2013 at 2:24 PM, Mario Smarduch
<mario.smarduch@huawei.com> wrote:
> On 4/29/2013 11:21 AM, Ryan wrote:
>>> spin_lock_irqsave(lock,flags)/ affects the running
>>> > CPU, it does not disable any device IRQ. Device
>>> > interrupts may be taken by other CPUs. There is a whole
>>> > other set of calls that deal with individual IRQs.
>> You mean to say that
>>       a) Device IRQ can be taken care of some other core of the Same CPU?
>>       b) If the CPU Load is Less. then only one core will be active.
>> In that case - The device irq will be blocked?
>>
>>
>
> I don't understand (a), in SMP you may disable IRQs on a CPU
> (via *_irqsave()) but other CPUs may continue to receive interrupts.
> The CPU load has nothing to do with blocking IRQs (on vanilla kernel)
> To disable device IRQ you must disable it at the interrupt controller
> level like disable_irq().
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs