19 Feb, 2011
40 commits
-
The saving of this switch is minimal versus the ifdef mess it
creates. Simple enable PER_CPU unconditionally and remove the config
switch.Signed-off-by: Thomas Gleixner
-
chip implementations need to know about it. Keep status in sync until
all users are fixed.Accessor function: irqd_is_setaffinity_pending(irqdata)
Coders who access them directly will be tracked down and slapped with
stinking trouts.Signed-off-by: Thomas Gleixner
-
Some chip implementations need to access certain status flags. With
sparse irqs that requires a lookup of the irq descriptor. Add a state
field which contains such flags.Name it in a way which will make coders happy to access it with the
proper accessor functions. And it's easy to grep for.Signed-off-by: Thomas Gleixner
-
No users outside of core.
Signed-off-by: Thomas Gleixner
-
No users outside of core.
Signed-off-by: Thomas Gleixner
-
Keep status in sync until all users are fixed.
Signed-off-by: Thomas Gleixner
-
Keep status in sync until all users are fixed.
Signed-off-by: Thomas Gleixner
-
Keep status in sync until all abusers are fixed.
Signed-off-by: Thomas Gleixner
-
No users outside of core.
Signed-off-by: Thomas Gleixner
-
No users outside of core.
Signed-off-by: Thomas Gleixner
-
We need to maintain the flag for now in both fields status and istate.
Add a CONFIG_GENERIC_HARDIRQS_NO_COMPAT switch to allow testing w/o
the status one. Wrap the access to status IRQ_INPROGRESS in a inline
which can be turned of with CONFIG_GENERIC_HARDIRQS_NO_COMPAT along
with the define.There is no reason that anything outside of core looks at this. That
needs some modifications, but we'll get there.Signed-off-by: Thomas Gleixner
-
No users outside of core.
Signed-off-by: Thomas Gleixner
-
No need for a separate function in the core code.
Signed-off-by: Thomas Gleixner
-
No users outside.
Signed-off-by: Thomas Gleixner
-
No users outside of core
Signed-off-by: Thomas Gleixner
-
The irq_desc.status field will either go away or renamed to
settings. Anyway we need to maintain compatibility to avoid breaking
the world and some more. While moving bits into the core, I need to
avoid that I use any of the still existing IRQ_ bits in the core code
by typos. So that file will hold the inline wrappers and some nasty
CPP tricks to break the build when typoed.Signed-off-by: Thomas Gleixner
-
That field will contain internal state information which is not going
to be exposed to anything outside the core code - except via accessor
functions. I'm tired of everyone fiddling in irq_desc.status.core_internal_state__do_not_mess_with_it is clear enough, annoying to
type and easy to grep for. Offenders will be tracked down and slapped
with stinking trouts.Signed-off-by: Thomas Gleixner
-
Signed-off-by: Thomas Gleixner
-
All archs implement show_interrupts() in more or less the same
way. That's tons of duplicated code with different bugs with no
value. Implement a generic version and deprecate show_interrupts()Unfortunately we need some ifdeffery for !GENERIC_HARDIRQ archs.
Signed-off-by: Thomas Gleixner
-
Now that all core users are converted one layer can go.
Signed-off-by: Thomas Gleixner
-
Signed-off-by: Thomas Gleixner
-
Signed-off-by: Thomas Gleixner
-
It's safe to drop the IRQ_INPROGRESS flag between action chain walks
as we are protected by desc->lock.Signed-off-by: Thomas Gleixner
-
Signed-off-by: Thomas Gleixner
-
Signed-off-by: Thomas Gleixner
-
Signed-off-by: Thomas Gleixner
-
Core code replacement for the ugly camel case. It contains all the
code which is shared in all handlers.clear status flags
set INPROGRESS flag
unlock
call action chain
note_interrupt
lock
clr INPROGRESS flagSigned-off-by: Thomas Gleixner
-
IRQ_MASKED is set in mask_ack_irq() anyway. Remove it from
handle_edge_irq() to allow simpler ab^HHreuse of that function.Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
LKML-Reference: -
Handle IRQ_DISABLED consistent.
Signed-off-by: Thomas Gleixner
-
Now that everything uses the wrappers, we can remove the default
functions. None of those functions is performance critical.That makes the IRQ_MASKED flag tracking fully consistent.
Signed-off-by: Thomas Gleixner
-
Create irq_disable/enable and use them to keep the flags consistent.
Signed-off-by: Thomas Gleixner
-
Aside of duplicated code some of the startup/shutdown sites do not
handle the MASKED/DISABLED flags and the depth field at all. Move that
to a helper function and take care of it there.Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
LKML-Reference: -
The if (chip->irq_shutdown) check will always evaluate to true, as we
fill in chip->irq_shutdown with default_shutdown in
irq_chip_set_defaults() if the chip does not provide its own function.Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
LKML-Reference: -
Soleley used in core code.
Signed-off-by: Thomas Gleixner
-
With the chip.end() function gone we might run into a situation where
a poll call runs and the real interrupt comes in, sees IRQ_INPROGRESS
and disables the line. That might be a perfect working one, which will
then be masked forever.So mark them polled while the poll runs. When the real handler sees
IRQ_INPROGRESS it checks the poll flag and waits for the polling to
complete. Add the necessary amount of sanity checks to it to avoid
deadlocks.Signed-off-by: Thomas Gleixner
-
No point in running concurrent pollers which confuse each other by
setting PENDING.Signed-off-by: Thomas Gleixner
-
There is no point in polling disabled lines.
percpu does not make sense at all because we only poll on the cpu
we're currently running on. Also polling per_cpu interrupts is racy as
hell. The handler runs without locking so we might get a huge
surprise.If the timer interrupt needs polling, then we wont get there anyway.
Signed-off-by: Thomas Gleixner
-
try_one_irq() contains redundant code and lots of useless checks for
shared interrupts. Check for shared before setting IRQ_INPROGRESS and
then call handle_IRQ_event() while pending. Shorter version with the
same functionality.Signed-off-by: Thomas Gleixner
-
We run all handlers with interrupts disabled and expect them not to
enable them. Warn when we catch one who does.Signed-off-by: Thomas Gleixner
-
We cannot walk the action chain unlocked. Even if IRQ_INPROGRESS is
set an action can be removed and we follow a null pointer. It's safe
to take the lock there, because the code which removes the action will
call synchronize_irq() which waits unlocked for IRQ_INPROGRESS going
away.Signed-off-by: Thomas Gleixner
