Messages in this thread |  | | Date | Tue, 18 Nov 2014 10:54:56 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [patch 01/16] irqdomain: Introduce new interfaces to support hierarchy irqdomains |
| |
On Tue, 18 Nov 2014, Yun Wu (Abel) wrote: > Hi Thomas, Jiang, > On 2014/11/12 21:42, Thomas Gleixner wrote: > > > From: Jiang Liu <jiang.liu@linux.intel.com> > > Index: tip/kernel/irq/chip.c > > =================================================================== > > --- tip.orig/kernel/irq/chip.c > > +++ tip/kernel/irq/chip.c > > @@ -15,6 +15,7 @@ > > #include <linux/module.h> > > #include <linux/interrupt.h> > > #include <linux/kernel_stat.h> > > +#include <linux/irqdomain.h> > > > > #include <trace/events/irq.h> > > > > @@ -178,6 +179,7 @@ int irq_startup(struct irq_desc *desc, b > > irq_state_clr_disabled(desc); > > desc->depth = 0; > > > > + irq_domain_activate_irq(&desc->irq_data); > > I'm not sure why this is needed, please help me out.. :)
Because it makes the whole error handling in stacked allocations way simpler.
We allocate and reserve resources, but do not program the hardware up to the point where request_irq and therefor irq_startup() is invoked.
So when in the allocation/reservation phase any of the stack level fails we just have to undo the allocations/reservations and not any hardware settings.
That also solves the issue that depending on the stacking we might not be able to program the hardware during the allocation because all stack levels need to be allocated/reserved before we can figure out which hardware configuration we need for the various levels.
So we decided to postpone the actual hardware programming to the point where the interrupt actually gets used.
Thanks,
tglx
|  |