[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 10/16] xen/arm: IRQ: Don't need to have a specific function to route IRQ to Xen
On Thu, 2014-04-03 at 21:42 +0100, Julien Grall wrote: > When the IRQ is handling by Xen, the setup is done in 2 steps: "an IRQ is handled" (and perhaps s/, the//) $subject is an odd way to describe the change too (it's more like the motivation). Something like "defer routing IRQ to Xen until setup_irq() call" perhaps? > - Route the IRQ to the current CPU and set priorities > - Set up the handler > > For PPIs, these steps are called on every cpu. For SPIs, they are only called > on the boot CPU. > > Dividing the setup in two step complicates the code when a new driver is > added to Xen (for instance a SMMU driver). Xen can safely route the IRQ > when the driver sets up the interrupt handler. > > Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> > > --- > Changes in v2: > - Fix typo in commit message > - s/SGI/SPI/ in comments > - Rename gic_route_dt_irq into gic_route_irq_to_xen which is > taking a desc now > - Call setup_irq before initializing the GIC IRQ as the first one > can fail. > --- > xen/arch/arm/gic.c | 63 > +++++++------------------------------------- > xen/arch/arm/irq.c | 24 ++++++++++++++++- > xen/arch/arm/setup.c | 2 -- > xen/arch/arm/smpboot.c | 2 -- > xen/arch/arm/time.c | 11 -------- > xen/include/asm-arm/gic.h | 10 +++---- > xen/include/asm-arm/time.h | 3 --- > 7 files changed, 36 insertions(+), 79 deletions(-) > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index 8c53e52..9127ecf 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -257,30 +257,20 @@ static void gic_set_irq_properties(unsigned int irq, > bool_t level, > spin_unlock(&gic.lock); > } > > -/* Program the GIC to route an interrupt */ > -static int gic_route_irq(unsigned int irq, bool_t level, > - const cpumask_t *cpu_mask, unsigned int priority) > +/* Program the GIC to route an interrupt to the host (eg Xen) You mean i.e. not e.g. > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > index 798353b..1262a9c 100644 > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -247,15 +247,37 @@ int setup_dt_irq(const struct dt_irq *irq, struct > irqaction *new) > int rc; > unsigned long flags; > struct irq_desc *desc; > + bool_t disabled = 0; No need to init, it's unconditionally assigned below. But if you do want to keep it then I think boot_t wants to go with false even if that is the same as 0 in the end. > desc = irq_to_desc(irq->irq); > > spin_lock_irqsave(&desc->lock, flags); > + > + disabled = (desc->action == NULL); > + > rc = __setup_irq(desc, new); > + if ( rc ) > + goto err; > > - if ( !rc ) > + /* First time the IRQ is setup */ > + if ( disabled ) There's no way we can get back into this state. Perhaps with calls to release_irq? > + { > + bool_t level; > + > + level = dt_irq_is_level_triggered(irq); > + /* It's fine to use smp_processor_id() because: > + * For PPI: irq_desc is banked > + * For SPI: we don't care for now which CPU will receive the > + * interrupt setup_dt_irq expected to be called multiple times for a PPI and the desc is not shared, so that's how they get setup as well, right? > + * TODO: Handle case where SPI is setup on different CPU than > + * the targeted CPU and the priority. > + */ > + gic_route_irq_to_xen(desc, level, cpumask_of(smp_processor_id()), > + GIC_PRI_IRQ); > desc->handler->startup(desc); > + } > > +err: > spin_unlock_irqrestore(&desc->lock, flags); > > return rc; Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |