Re: [RFC Patch Part1 V1 00/30] use irqdomain to dynamically allocate IRQ for IOAPIC pin

[Thomas Gleixner]

Jiang,

On Fri, 16 May 2014, Jiang Liu wrote:

> On x86 platforms, IRQ number are statically allocated to IOAPIC pins at boot.
> There are two issues with this design. First it causes trouble to IOAPIC
> hotplug because we need to allocate a block of IRQ numbers for each IOAPIC.
> Second it may waste IRQ nubmers even if some IOAPIC pins are not used because
> IRQ numbers are statically assigned.
> 
> This patchset tries to enable dynamic IRQ number allocation for IOAPIC
> by adopting the irqdomain framework, it solves the two issues mentioned
> above. It also simplifies the IOAPIC driver by consolidating ways to
> program IOAPIC pins with the irqdomain map interface.
> 
> We will enhance the IOAPIC driver core to support ACPI based IOAPIC hotplug
> once the IOAPIC driver has been converted to irqdomain.

Thanks for tackling this!
 
> This patchset applies to v3.15-rc4-260-g38583f095c5a and has been tested

That's a bit unfortunate, as there are conflicting changes in the tip
tree irq/core branch. Can you please rebase on top of that.

> TODO list:
> 1) check whether it affects Xen or not
> 
> Patch 1-17 are trivial code improvements, bugfixes and preparation.

Can you please move the bugfixes before the other changes, so we can
pick them up independently from the outcome?
 
> Patch 18-24 enable basic irqdomain support and IRQ number dynamic
> allocation.
> 
> Patch 25-29 consoldate the way to program IOAPIC pins by using
> irqdomain map() interface.
> 
> Patch 30 cleans up unused interfaces and functions in IOAPIC driver.
> 
> Tests and comments are warmly welcomed!

I like the general approach, but we have now a mixture of legacy irq
handling and irq domains. We really want to cleanup the legacy PIC no
ioapic case as well. That will cleanup the code further.

The other thing we discussed here: https://lkml.org/lkml/2014/5/7/901
in several places of the thread is to move the vector allocation into
a irqdomain with a generic matrix allocator as well. We have other use
cases for this as well. It would be nice if you could look at that as
well.

Thanks,

	tglx




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/