local_save_flags(flags)

local_save_flags(flags)

[Fundu]

Hi,

From my understanding the local_irq_save(flags) saves the current irq state and disables the interrupts. 

My question is what happens to those interrupts that arriving while the interrupts are disabled. 
is the following understanding correct ... 

if they are edge triggered they would be lost, 
only level triggered interrupts would be serviced after interrupts are enabled.

TIA
Fundu.


      

RE: local_save_flags(flags)

[Fundu]

> turning off interrupts just masks them. the interrupt
> hardware should
> "latch" them and they fire when you reenable
> interrupts.
>
> You loose track of "how many" not if any
> happened...
>
> marty

Thanks Marty,

a follow up question,
why do we need to save the flags then ? if the interrupt hardware would
latch them ?
can we not just disable all interrupts ?

TIA,
Fundo


      

Re: local_save_flags(flags)

[Mike Frysinger]

On Thu, Sep 18, 2008 at 17:09, Fundu wrote:
>> turning off interrupts just masks them. the interrupt
>> hardware should
>> "latch" them and they fire when you reenable
>> interrupts.
>>
>> You loose track of "how many" not if any
>> happened...
>
> a follow up question,
> why do we need to save the flags then ? if the interrupt hardware would
> latch them ?
> can we not just disable all interrupts ?

you really should just read a book on the topic.  LDD3 covers these
intricacies (and a lot more), as does Essential Linux Device Drivers.
-mike

Re: local_save_flags(flags)

[Fundu]

> you really should just read a book on the topic.  LDD3
> covers these
> intricacies (and a lot more), as does Essential Linux
> Device Drivers.
i'm actually reading essential linux device drivers. And to get some clarification i made the post. 
 



      

Re: local_save_flags(flags)

[Mike Frysinger]

On Thu, Sep 18, 2008 at 18:05, Fundu wrote:
>> you really should just read a book on the topic.  LDD3
>> covers these
>> intricacies (and a lot more), as does Essential Linux
>> Device Drivers.
>
> i'm actually reading essential linux device drivers. And to get some clarification i made the post.

that book explicitly covers your question.  read chapter 2 where it
covers these irq functions.
-mike

Re: local_save_flags(flags)

[Fundu]

> that book explicitly covers your question.  read chapter 2
> where it
> covers these irq functions.
as i said i'm reading the book and actully i did read that chapter. 

for me, here's the exact line that needs clarification,
In chapter 2, page 42 last paragraph(starts with "However, if ..." )

here's the code snippet he's talking about.
Point A:
local_irq_disable();
/* critical section ...*/
local_irq_enable();


Author say, if irg are already disabled at Point A (see snippet above) then local_irq_enable() creates an unpleasant side effect of re-enabling interrupts rather than restoring interrupt state. 

1) first what's the difference between re-enabling and restoring interrupt state. 
2) so is disable interrupts twice a problem, or just enabling them when after they are diabled (which sounds like how it should be ) a problem.

hope i have made myself clear enough for you to respond.

TIA  




      

Re: local_save_flags(flags)

[Mike Frysinger]

On Thu, Sep 18, 2008 at 18:45, Fundu wrote:
>> that book explicitly covers your question.  read chapter 2
>> where it
>> covers these irq functions.
>
> as i said i'm reading the book and actully i did read that chapter.
>
> for me, here's the exact line that needs clarification,
> In chapter 2, page 42 last paragraph(starts with "However, if ..." )
>
> here's the code snippet he's talking about.
> Point A:
> local_irq_disable();
> /* critical section ...*/
> local_irq_enable();
>
>
> Author say, if irg are already disabled at Point A (see snippet above) then local_irq_enable() creates an unpleasant side effect of re-enabling interrupts rather than restoring interrupt state.

this was the section i referred to ... but i guess it made perfect
sense to me since i'm familiar with the details

> 1) first what's the difference between re-enabling and restoring interrupt state.

many irq controllers have a global enable bit.  you can restore the
interrupt mask state without toggling that bit.

> 2) so is disable interrupts twice a problem, or just enabling them when after they are diabled (which sounds like how it should be ) a problem.

both are a problem.  the non-state saving version cannot be used
recursively nor in parallel to the state-saving version.
-mike

Re: local_save_flags(flags)

[Daniel THOMPSON]

Fundu wrote:
> 
>> that book explicitly covers your question.  read chapter 2
>> where it
>> covers these irq functions.
> as i said i'm reading the book and actully i did read that chapter. 
> 
> for me, here's the exact line that needs clarification,
> In chapter 2, page 42 last paragraph(starts with "However, if ..." )
> 
> here's the code snippet he's talking about.
> Point A:
> local_irq_disable();
> /* critical section ...*/
> local_irq_enable();
> 
> 
> Author say, if irg are already disabled at Point A (see snippet above) then local_irq_enable() creates an unpleasant side effect of re-enabling interrupts rather than restoring interrupt state. 
> 
> 1) first what's the difference between re-enabling and restoring interrupt state. 
> 2) so is disable interrupts twice a problem, or just enabling them when after they are diabled (which sounds like how it should be ) a problem.
> 
> hope i have made myself clear enough for you to respond.

I think you are confused by the term 'flags'. In this case 'flags' is
not the interrupts that are pending, there are the interrupts that where
enabled before calling local_irq_save().

Does an example help? Consider driver A that calls 'library' code B.

void driver_A()
{
  local_irq_disable();
  /* do something critical */
  library_code_B();
  /* do something else critical */
  local_irq_enable();

  /* NO BUG - if interrupts are not locked when local_irq_disable()
   * was called.
   */
}

void library_code_B(void)
{
#if BUGGY_CODE_COMES_FIRST
    local_irq_disable();
    /* do something critical */
    local_irq_enable();

    /* BUG HERE - driver A thinks interrupts are still disabled but
     * they are not
     */
#else
   flags = local_irq_save();
   /* do something critical */
   local_irq_restore(flags);

   /* NO BUG - interrupts are still locked (flags is used to remember
    * that interrupts were locked when we called local_irq_save().
    */
#endif
}

In fewer words: use local_irq_save/restore() if you don't know whether
interrupts where locked or not when your function was called.

PS There are only a small number of drivers that should use the
   local_irq_... family of functions anyway. Normally you should use
   create a spin lock and use spin_lock_irq() and spin_lock_irqsave()
   instead.

-- 
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

If a car is a horseless carriage then is a motorcycle a horseless horse?

Re: local_save_flags(flags)

[Fundu]

> > 2) so is disable interrupts twice is a problem, or just
> enabling them after they are disabled (which sounds like
> how it should be) a problem.
> 
> both are a problem.  the non-state saving version cannot be
> used
> recursively nor in parallel to the state-saving version.

Much clear now, Thanks Mike! 

here's a follow up question.

what about Non maskable interrupts ? disabling interrupt won't have any effect on that right ? 

thanks 
Fundu. 



      

Re: local_save_flags(flags)

[Mike Frysinger]

On Tue, Sep 23, 2008 at 16:01, Fundu wrote:
>> > 2) so is disable interrupts twice is a problem, or just
>> enabling them after they are disabled (which sounds like
>> how it should be) a problem.
>>
>> both are a problem.  the non-state saving version cannot be
>> used
>> recursively nor in parallel to the state-saving version.
>
> Much clear now, Thanks Mike!
>
> here's a follow up question.
>
> what about Non maskable interrupts ? disabling interrupt won't have any effect on that right ?

that really doesnt make sense by definition huh.  non-maskable means
they cant be masked.
-mike

Re: local_save_flags(flags)

[Fundu]

> >
> > what about Non maskable interrupts ? disabling
> interrupt won't have any effect on that right ?
> 
> that really doesnt make sense by definition huh. 
> non-maskable means
> they cant be masked.
> -mike

yeah thats the point. i should have elaborated more. 
then there's no guarantee that your code wont be interrupted ?
typically what NMI interrupt does a embedded system have ? 

fundu


      

Re: local_save_flags(flags)

[Mike Frysinger]

On Tue, Sep 23, 2008 at 21:15, Fundu wrote:
>>> what about Non maskable interrupts ? disabling
>>> interrupt won't have any effect on that right ?
>>
>> that really doesnt make sense by definition huh.
>> non-maskable means
>> they cant be masked.
>
> yeah thats the point. i should have elaborated more.
> then there's no guarantee that your code wont be interrupted ?

design your system properly and it wont be an issue

> typically what NMI interrupt does a embedded system have ?

it depends on the processor and the kernel configuration.  i can tell
you about the Blackfin processor, but i doubt you're using that.
-mike

Re: local_save_flags(flags)

[Fundu]

> >>> what about Non maskable interrupts ? disabling
> >>> interrupt won't have any effect on that
> right ?
> >>
> >> that really doesnt make sense by definition huh.
> >> non-maskable means
> >> they cant be masked.
> >
> > yeah thats the point. i should have elaborated more.
> > then there's no guarantee that your code wont be
> interrupted ?
> 
> design your system properly and it wont be an issue

could you elaborate more on this, as to what you mean by good design in this context.

> you about the Blackfin processor, but i doubt you're
> using that.
sure i would like to know. i also have a 537 which i would work on for the next project and don't mind more info on it.

thanks!
Fundu


      

Re: local_save_flags(flags)

[Robin Getz]

On Wed 24 Sep 2008 13:06, Fundu pondered:
> > >>> what about Non maskable interrupts ? disabling
> > >>> interrupt won't have any effect on that
> > right ?
> > >>
> > >> that really doesnt make sense by definition huh.
> > >> non-maskable means
> > >> they cant be masked.
> > >
> > > yeah thats the point. i should have elaborated more.
> > > then there's no guarantee that your code wont be
> > interrupted ?

Disabling interrupts does not normally mask NMI, reset, exceptions
and emulation. All can interrupt your code. Most do not return (except 
exceptions) - so it is not a big deal.

exceptions - also depend heavily on your processor type/architecture - but can 
range from TLB miss/dirty - to unaligned access fixups.

On Blackfin - we don't do unaligned access fixups - this has the upside of 
when your code does this - it crashes - so you tend to find it early :) The 
downside is that the code which functions (slowly) on other architectures 
does not run on Blackfin...

> > design your system properly and it wont be an issue
> 
> could you elaborate more on this, as to what you mean by good design in
> this context.

If you have something that is timing critical - make sure - by design - that 
you will not cause exception events.

In most Blackfin systems that is done by ensuring that the TLB for the kernel 
is covered and locked. You never get a ITLB miss in kernel code, and a DTLB 
miss only occurs on kmalloced data. (which you shouldn't be acessing)

> > you about the Blackfin processor, but i doubt you're
> > using that.
>
> sure i would like to know. i also have a 537 which i would work on for
> the next project and don't mind more info on it.

It really depends on what you are trying to do.

If you are that timing critical - you want to put things into internal L1 
memory - so you don't take the penalty of cache misses/flushes either...