On Wed, 14 May 2014, Chris Metcalf wrote:
> On 5/7/2014 7:15 PM, Thomas Gleixner wrote:
> > On Wed, 7 May 2014, Chris Metcalf wrote:
> > > We have an internal change that we haven't upstreamed yet that makes
> > > irqs actually (cpu,ipi) pairs, so that more irqs can be allocated.
> > > As a result
On Wed, 14 May 2014, Chris Metcalf wrote:
> On 5/7/2014 11:44 AM, Thomas Gleixner wrote:
> > --- tip.orig/kernel/irq/Kconfig
> > +++ tip/kernel/irq/Kconfig
> > @@ -17,6 +17,11 @@ config GENERIC_IRQ_SHOW
> > config GENERIC_IRQ_SHOW_LEVEL
> > bool
> > +# Facility to allocate an hardware
On 5/7/2014 7:15 PM, Thomas Gleixner wrote:
On Wed, 7 May 2014, Chris Metcalf wrote:
We have an internal change that we haven't upstreamed yet that makes
irqs actually (cpu,ipi) pairs, so that more irqs can be allocated.
As a result we allocate some irqs as bound to a specific IPI on a single
cp
On 5/7/2014 11:44 AM, Thomas Gleixner wrote:
--- tip.orig/kernel/irq/Kconfig
+++ tip/kernel/irq/Kconfig
@@ -17,6 +17,11 @@ config GENERIC_IRQ_SHOW
config GENERIC_IRQ_SHOW_LEVEL
bool
+# Facility to allocate an hardware interrupt. This is legacy support
+# and should not be used in n
> - a bitmap based matrix vector allocator, but that shouldn't be rocket
> science to write one.
Not rocket science - but some tricky corner cases to make sure all the
allocations will fit. MSI needs blocks of irqs that start on a power-of-two
boundary so the h/w can just fiddle with low order
Chris,
On Thu, 8 May 2014, Thomas Gleixner wrote:
> 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, bu
On Thu, 8 May 2014, Grant Likely wrote:
> On Wed, 07 May 2014 15:44:05 -, Thomas Gleixner
> wrote:
> > +EXPORT_SYMBOL_GPL(irq_alloc_hwirqs);
>
> Okay, so regarding this and irq_domains, I think the functionality
> overlaps and irq_domain conversion wouldn't directly use this API. I
> could s
On Wed, 07 May 2014 15:44:05 -, Thomas Gleixner wrote:
> Not really the solution to the problem, but at least it confines the
> mess in the core code and allows to get rid of the create/destroy_irq
> variants from hell, i.e. 3 implementations with different semantics
> plus the x86 specific va
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 talk
On Wed, 7 May 2014, Chris Metcalf wrote:
> On 5/7/2014 11:44 AM, Thomas Gleixner wrote:
> > Not really the solution to the problem, but at least it confines the
> > mess in the core code and allows to get rid of the create/destroy_irq
> > variants from hell, i.e. 3 implementations with different s
On 5/7/2014 11:44 AM, Thomas Gleixner wrote:
> Not really the solution to the problem, but at least it confines the
> mess in the core code and allows to get rid of the create/destroy_irq
> variants from hell, i.e. 3 implementations with different semantics
> plus the x86 specific variants __create
11 matches
Mail list logo
