lkml.org 
[lkml]   [2014]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2014-11-18 11:21    [W:0.120 / U:4.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site