[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1405081140410.6261@ionos.tec.linutronix.de>
Date: Thu, 8 May 2014 12:22:40 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Chris Metcalf <cmetcalf@...era.com>
cc: LKML <linux-kernel@...r.kernel.org>, Tony Lu <zlu@...era.com>,
Ingo Molnar <mingo@...e.hu>, Peter Anvin <hpa@...or.com>,
Tony Luck <tony.luck@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Fenghua Yu <fenghua.yu@...el.com>,
Grant Likely <grant.likely@...aro.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [patch 03/32] genirq: Provide generic hwirq allocation
facility
On Thu, 8 May 2014, Thomas Gleixner wrote:
> Now on top of that we need irq domain support for this kind of matrix
> mappings down to the vector level and everything else falls in
> place. I have not thought through the irq domain angle, but maybe
> Grant/Ben can give some input on that.
Just talked to Grant to get my irqdomain foo up to speed.
irq domains support parent irq domains already, which allow you to
request an irq from the parent.
What's missing is:
- a bitmap based matrix vector allocator, but that shouldn't be rocket
science to write one.
- a mechanism to hand a cpumask down in the allocation chain
- a shortcut support to avoid multi level map lookups for the fast
path.
Once we have that everything just falls in place and when tile and x86
are switched over we can rip out the LEGACY allocator again. That'll
leave itanic with its homebrewn create_irq machinery, but I'm happy to
ignore that as this is almost completely confined in ia64 code where
is can bitrot happily until it sinks.
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