[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1309130010110.4089@ionos.tec.linutronix.de>
Date: Fri, 13 Sep 2013 00:12:24 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Felipe Balbi <balbi@...com>
cc: Sricharan R <r.sricharan@...com>, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
linus.walleij@...aro.org, santosh.shilimkar@...com,
linux@....linux.org.uk, tony@...mide.com, rnayak@...com
Subject: Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thu, 12 Sep 2013, Thomas Gleixner wrote:
> On Thu, 12 Sep 2013, Felipe Balbi wrote:
>
> > On Thu, Sep 12, 2013 at 09:09:08PM +0530, Sricharan R wrote:
> > > +unsigned int crossbar_request_irq(struct irq_data *d)
> > > +{
> > > + int cb_no = d->hwirq;
> > > + int virq = allocate_free_irq(cb_no);
> > > + void *irq = &cb->crossbar_map[cb_no].hwirq;
> > > + int err;
> > > +
> > > + err = request_threaded_irq(virq, crossbar_irq, NULL,
> > > + 0, "CROSSBAR", irq);
> >
> > this is wrong, why don't you just set crossbar up as a chained handler.
>
> That's just a detail, which does not solve the underlying problem of
> the crossbar -> GIC mapping.
And actually the thing is the other way round:
GIC distributes to crossbar, so the underlying GIC irq would be the
chained handler.
Still does not solve the setup/request_irq issue.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists