Message-ID: <alpine.DEB.2.02.1405192250170.22305@ionos.tec.linutronix.de>
Date:	Mon, 19 May 2014 23:04:22 +0900 (JST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Jiang Liu <jiang.liu@...ux.intel.com>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tony Luck <tony.luck@...el.com>,
	Joerg Roedel <joro@...tes.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org,
	sfi-devel@...plefirmware.org,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [RFC Patch Part1 V1 00/30] use irqdomain to dynamically allocate
 IRQ for IOAPIC pin

Jiang,

On Sun, 18 May 2014, Jiang Liu wrote:
> On 2014/5/16 23:28, Thomas Gleixner wrote:
> >> 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?
> Sure, will reorder the patch set in next version.

Thanks.
 
> >  
> >> 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.
> I have read through the thread, it's an interesting discussion.
> 
> After my first thought, I have gotten some ideas about how to reorganize
> x86 interrupt subsystem using irqdomain framework based on ideas from
> the thread. Because I'm newbie to interrupt subsystem, I will share my
> naive ideas first and RFC for whether it's the right direction.
> 
> We may build hierarchy irqdomains as below for x86,
> [IOAPIC]      [MSI/MSI-x]  [HPET]  [DMAR] [Legacy]
>     |            |           |       |       |
>     v            v           v       |       |
> [           Remapping           ]    |       |
>                  |                   |       |
>                  v                   v       v
> [                   Root/vector                ]
> 
> The remapping domain is optional and used to support IRQ remapping unit.
> We abstract remapping entry as hardware interrupt pin and will extend
> irqdomain interface to support automatic assignment of hardware
> interrupt pin.
> 
> The root/vector domain is used to manage per CPU vector numbers and
> CPU vector is abstracted as hardware interrupt pin. It will support
> automatic vector number assignment. To support root/vector domain,
> we need to extend irqdomain interface to pass down information
> or constraints about the IRQ allocation.
> 
> So how about following extension to current irqdomain interfaces?

I cc'ed Grant Likely. He might have some opinion on this as well.

> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index c983ed18c332..2fd7e50cde32 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -42,6 +42,13 @@ struct of_device_id;
>  /* Number of irqs reserved for a legacy isa controller */
>  #define NUM_ISA_INTERRUPTS     16
> 
> +#define        IRQDOMAIN_AUTO_ASSIGN_HWIRQ     ULONG_MAX
> +#ifdef arch_irq_alloc_info_t
> +typedef        arch_irq_alloc_info_t irq_alloc_info_t;
> +#else
> +typedef        void irq_alloc_info_t;
> +#endif
> 
>  /**
>   * struct irq_domain_ops - Methods for irq_domain objects
>   * @match: Match an interrupt controller device node to a host, returns
> @@ -59,7 +66,11 @@ struct of_device_id;
>   */
>  struct irq_domain_ops {
>         int (*match)(struct irq_domain *d, struct device_node *node);
> -       int (*map)(struct irq_domain *d, unsigned int virq,
> irq_hw_number_t hw);
> +       int (*alloc)(struct irq_domain *d, irq_hw_number_t hw,
> +                    irq_alloc_info_t *info);
> +       int (*free)(struct irq_domain *d, unsigned int virq);
> +       int (*map)(struct irq_domain *d, unsigned int virq,
> irq_hw_number_t hw,
> +                  irq_alloc_info_t *info);
>         void (*unmap)(struct irq_domain *d, unsigned int virq);
>         int (*xlate)(struct irq_domain *d, struct device_node *node,
>                      const u32 *intspec, unsigned int intsize,
> 
> alloc()/free() interfaces will be used allocate/free IRQ from parent
> domain. And irq_alloc_info_t structure is used to host parameters
> and constraints for IRQ allocation.
> 
> For x86, irq_alloc_info_t structure will be used to host CPU mask,
> device pointer, IOAPIC pin attributes, NUMA node info etc.

Do we really need to hand all of this down?

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