From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains Date: Mon, 29 Sep 2014 17:53:01 +0200 (CEST) Message-ID: References: <1411740145-30626-1-git-send-email-jiang.liu@linux.intel.com> <1411740145-30626-2-git-send-email-jiang.liu@linux.intel.com> <54294F1C.30606@huawei.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <54294F1C.30606@huawei.com> Sender: linux-kernel-owner@vger.kernel.org To: Abel Cc: Jiang Liu , Benjamin Herrenschmidt , Ingo Molnar , "H. Peter Anvin" , "Rafael J. Wysocki" , Bjorn Helgaas , Randy Dunlap , Yinghai Lu , Borislav Petkov , Grant Likely , Marc Zyngier , Konrad Rzeszutek Wilk , Andrew Morton , Tony Luck , Joerg Roedel , Greg Kroah-Hartman , x86@kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-acpi@vger.kernel.org On Mon, 29 Sep 2014, Abel wrote: > On 2014/9/26 22:02, Jiang Liu wrote: > > +static void irq_domain_free_descs(unsigned int virq, unsigned int nr_irqs) > > +{ > > + unsigned int i; > > + > > + for (i = 0; i < nr_irqs; i++) > > + irq_free_desc(virq + i); > > +} > > I am not sure why this function is needed, since it works in the exact same > way as irq_free_descs(virq, nr_irqs). Indeed. > I've been through your patches and noticed that the only domain > which does not call irq_domain_alloc_irqs_parent() is > x86_vector_domain. And this makes sense *if* we already knew which > domain is the nearest one to the CPU. Right, and in case of x86 the vector domain _IS_ the one which is always the nearest one to the cpu. > But I don't think a well implemented device driver should assume > itself be in a particular position of the interrupt delivery path. The device driver has no knowledge of this. The irq domain driver definitely has to know to some extent. > Actually it should be guaranteed by the core infrastructure that all > the domains in the interrupt delivery path should allocate a > hardware interrupt for the interrupt source. Well, that's what we do. We allocate down the irq domain hierarchy. If one level fails the whole operation fails. > And besides the comments/questions I mentioned above, I am also curious about > how the chained interrupts been processed. > > Let's take a 3-level-chained-domains for example. > Given 3 interrupt controllers A, B and C, and the interrupt delivery path is: > > DEV -> A -> B -> C -> CPU > > After the hierarchy irqdomains are established, the unique linux interrupt of > DEV will be mapped with a hardware interrupt in each domain: > > DomainA: HWIRQ_A => VIRQ_DEV > DomainB: HWIRQ_B => VIRQ_DEV > DomainC: HWIRQ_C => VIRQ_DEV > > When the DEV triggered an interrupt signal, the CPU will acknowledge HWIRQ_C, Not necessarily. The CPU will process HWIRQ_C. The acknowledge mechanism depends on the implementation details of the hierarchy. > and then irq_find_mapping(DomainC, HWIRQ_C) will be called to get the linux > interrupt VIRQ_DEV, and after the handler of the VIRQ_DEV has been processed, > the interrupt will end with the level (if have) uncleared on B, which will > result in the interrupt of DEV cannot be processed again. > > Or is there anything I misunderstand? This heavily depends on the properties of the stacked domains. It depends on the hardware requirements and the implementation of domain A and B how this is handled. It might be sufficient to have the following code in the irq_ack() callback of domain A: irq_ack_A(struct irq_data *d) { ack_hw_A(); } Another HW or stacking scenario requires irq_ack_A(struct irq_data *d) { ack_hw_A(); ack_parent(); } where ack_parent() does: if (d->parent_data) d->parent_data->chip->ack(d->parent_data); and ack_hw_A() can be anything from a nop to some more or less complex hw access. So we cannot define upfront how deep an ack/mask/unmask/... has to be propagated down the chain. This needs a careful consideration in terms of functionality and we want to be able to do performance shortcuts as well. Thanks, tglx From mboxrd@z Thu Jan 1 00:00:00 1970 From: tglx@linutronix.de (Thomas Gleixner) Date: Mon, 29 Sep 2014 17:53:01 +0200 (CEST) Subject: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains In-Reply-To: <54294F1C.30606@huawei.com> References: <1411740145-30626-1-git-send-email-jiang.liu@linux.intel.com> <1411740145-30626-2-git-send-email-jiang.liu@linux.intel.com> <54294F1C.30606@huawei.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 29 Sep 2014, Abel wrote: > On 2014/9/26 22:02, Jiang Liu wrote: > > +static void irq_domain_free_descs(unsigned int virq, unsigned int nr_irqs) > > +{ > > + unsigned int i; > > + > > + for (i = 0; i < nr_irqs; i++) > > + irq_free_desc(virq + i); > > +} > > I am not sure why this function is needed, since it works in the exact same > way as irq_free_descs(virq, nr_irqs). Indeed. > I've been through your patches and noticed that the only domain > which does not call irq_domain_alloc_irqs_parent() is > x86_vector_domain. And this makes sense *if* we already knew which > domain is the nearest one to the CPU. Right, and in case of x86 the vector domain _IS_ the one which is always the nearest one to the cpu. > But I don't think a well implemented device driver should assume > itself be in a particular position of the interrupt delivery path. The device driver has no knowledge of this. The irq domain driver definitely has to know to some extent. > Actually it should be guaranteed by the core infrastructure that all > the domains in the interrupt delivery path should allocate a > hardware interrupt for the interrupt source. Well, that's what we do. We allocate down the irq domain hierarchy. If one level fails the whole operation fails. > And besides the comments/questions I mentioned above, I am also curious about > how the chained interrupts been processed. > > Let's take a 3-level-chained-domains for example. > Given 3 interrupt controllers A, B and C, and the interrupt delivery path is: > > DEV -> A -> B -> C -> CPU > > After the hierarchy irqdomains are established, the unique linux interrupt of > DEV will be mapped with a hardware interrupt in each domain: > > DomainA: HWIRQ_A => VIRQ_DEV > DomainB: HWIRQ_B => VIRQ_DEV > DomainC: HWIRQ_C => VIRQ_DEV > > When the DEV triggered an interrupt signal, the CPU will acknowledge HWIRQ_C, Not necessarily. The CPU will process HWIRQ_C. The acknowledge mechanism depends on the implementation details of the hierarchy. > and then irq_find_mapping(DomainC, HWIRQ_C) will be called to get the linux > interrupt VIRQ_DEV, and after the handler of the VIRQ_DEV has been processed, > the interrupt will end with the level (if have) uncleared on B, which will > result in the interrupt of DEV cannot be processed again. > > Or is there anything I misunderstand? This heavily depends on the properties of the stacked domains. It depends on the hardware requirements and the implementation of domain A and B how this is handled. It might be sufficient to have the following code in the irq_ack() callback of domain A: irq_ack_A(struct irq_data *d) { ack_hw_A(); } Another HW or stacking scenario requires irq_ack_A(struct irq_data *d) { ack_hw_A(); ack_parent(); } where ack_parent() does: if (d->parent_data) d->parent_data->chip->ack(d->parent_data); and ack_hw_A() can be anything from a nop to some more or less complex hw access. So we cannot define upfront how deep an ack/mask/unmask/... has to be propagated down the chain. This needs a careful consideration in terms of functionality and we want to be able to do performance shortcuts as well. Thanks, tglx