From: Jiang Liu <jiang.liu@linux.intel.com> To: Abel <wuyun.wu@huawei.com>, Thomas Gleixner <tglx@linutronix.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Bjorn Helgaas <bhelgaas@google.com>, Randy Dunlap <rdunlap@infradead.org>, Yinghai Lu <yinghai@kernel.org>, Borislav Petkov <bp@alien8.de>, Grant Likely <grant.likely@linaro.org>, Marc Zyngier <marc.zyngier@arm.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Andrew Morton <akpm@linux-foundation.org>, Tony Luck <tony.luck@intel.com>, Joerg Roedel <joro@8bytes.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains Date: Tue, 07 Oct 2014 09:50:05 +0800 [thread overview] Message-ID: <543346CD.4070308@linux.intel.com> (raw) In-Reply-To: <542A8C5E.3040901@huawei.com> On 2014/9/30 18:56, Abel wrote: > Hi Thomas, > On 2014/9/29 23:53, Thomas Gleixner wrote: > >> On Mon, 29 Sep 2014, Abel wrote: >>> 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. > > Yes, I know that. :) > What I meant is... (please see below) > >> >>> 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. > > Actually the core infrastructure just calls domain->ops->alloc() which is > the one who really guarantees it by calling irq_domain_alloc_irqs_parent(). > I think it's enough for a particular domain to pick a hwirq from itself for > that linux irq, and need not to care about its parent. > What I suggest is something like: > > for (iter = domain; iter; iter = iter->parent) { > ret = iter->ops->alloc(iter, virq, nr_irqs, arg); > if (ret < 0) { > mutex_unlock(&irq_domain_mutex); > goto out_free_irq_data; > } > } > > in this way, the core infrastructure guarantees allocating down the irqdomain > hierarchy, and the implementers of domain_ops->alloc() need not to call > irq_domain_alloc_irqs_parent() any longer, just do the things they have to. Hi Abel, We have considered the above design when implementing hierarchy irqdomain, but adopted the irq_domain_alloc_irqs_parent(). The core could only support pre-order or post-order processing, it could support pre-order, post-order, pre-/post-order processing by using irq_domain_alloc_irqs_parent(). So we choose it for flexibility. Regards! Gerry > >> >>> 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. > > Yes, you are right. Thanks for pointing out. > >> >>> 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. >> > > Yes, I got it. And one more thing I concerned is that when hierarchy > irqdomains is enabled, shouldn't the ack_parent() be called by default > by the irqchip->irq_ack() of each domain to ensure all the domains in > the delivery path ack this interrupt? > > Thanks, > Abel. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
WARNING: multiple messages have this Message-ID (diff)
From: jiang.liu@linux.intel.com (Jiang Liu) To: linux-arm-kernel@lists.infradead.org Subject: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains Date: Tue, 07 Oct 2014 09:50:05 +0800 [thread overview] Message-ID: <543346CD.4070308@linux.intel.com> (raw) In-Reply-To: <542A8C5E.3040901@huawei.com> On 2014/9/30 18:56, Abel wrote: > Hi Thomas, > On 2014/9/29 23:53, Thomas Gleixner wrote: > >> On Mon, 29 Sep 2014, Abel wrote: >>> 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. > > Yes, I know that. :) > What I meant is... (please see below) > >> >>> 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. > > Actually the core infrastructure just calls domain->ops->alloc() which is > the one who really guarantees it by calling irq_domain_alloc_irqs_parent(). > I think it's enough for a particular domain to pick a hwirq from itself for > that linux irq, and need not to care about its parent. > What I suggest is something like: > > for (iter = domain; iter; iter = iter->parent) { > ret = iter->ops->alloc(iter, virq, nr_irqs, arg); > if (ret < 0) { > mutex_unlock(&irq_domain_mutex); > goto out_free_irq_data; > } > } > > in this way, the core infrastructure guarantees allocating down the irqdomain > hierarchy, and the implementers of domain_ops->alloc() need not to call > irq_domain_alloc_irqs_parent() any longer, just do the things they have to. Hi Abel, We have considered the above design when implementing hierarchy irqdomain, but adopted the irq_domain_alloc_irqs_parent(). The core could only support pre-order or post-order processing, it could support pre-order, post-order, pre-/post-order processing by using irq_domain_alloc_irqs_parent(). So we choose it for flexibility. Regards! Gerry > >> >>> 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. > > Yes, you are right. Thanks for pointing out. > >> >>> 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. >> > > Yes, I got it. And one more thing I concerned is that when hierarchy > irqdomains is enabled, shouldn't the ack_parent() be called by default > by the irqchip->irq_ack() of each domain to ensure all the domains in > the delivery path ack this interrupt? > > Thanks, > Abel. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
next prev parent reply other threads:[~2014-10-07 1:50 UTC|newest] Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-26 14:02 [RFT Part2 v2 00/24] Enable hierarchy irqdomian on x86 platforms Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-29 12:22 ` Abel 2014-09-29 12:22 ` Abel 2014-09-29 12:22 ` Abel 2014-09-29 15:53 ` Thomas Gleixner 2014-09-29 15:53 ` Thomas Gleixner 2014-09-30 10:56 ` Abel 2014-09-30 10:56 ` Abel 2014-09-30 10:56 ` Abel 2014-09-30 21:49 ` Thomas Gleixner 2014-09-30 21:49 ` Thomas Gleixner 2014-10-07 1:50 ` Jiang Liu [this message] 2014-10-07 1:50 ` Jiang Liu 2014-10-07 1:26 ` Jiang Liu 2014-10-07 1:26 ` Jiang Liu 2014-10-01 14:23 ` Joe.C 2014-10-01 14:23 ` Joe.C 2014-10-22 7:24 ` Jiang Liu 2014-10-22 7:24 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 02/24] genirq: Introduce helper functions to support stacked irq_chip Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 03/24] x86, irq: Save destination CPU ID in irq_cfg Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 04/24] x86, irq: Use hierarchy irqdomain to manage CPU interrupt vectors Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 05/24] x86, hpet: Use new irqdomain interfaces to allocate/free IRQ Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 06/24] x86, MSI: " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 07/24] x86, uv: " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 08/24] x86, htirq: " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 09/24] x86, dmar: " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 10/24] x86: irq_remapping: Introduce new interfaces to support hierarchy irqdomain Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 11/24] iommu/vt-d: Change prototypes to prepare for enabling " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 12/24] iommu/vt-d: Enhance Intel IR driver to suppport " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 13/24] iommu/amd: Enhance AMD " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 14/24] x86, hpet: Enhance HPET IRQ to support " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 15/24] x86, MSI: Use hierarchy irqdomain to manage MSI interrupts Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 16/24] x86, irq: Directly call native_compose_msi_msg() for DMAR IRQ Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 17/24] iommu/vt-d: Clean up unused MSI related code Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 18/24] iommu/amd: " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 19/24] x86: irq_remapping: " Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 20/24] x86, irq: Clean up unused MSI related code and interfaces Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 21/24] iommu/vt-d: Refine the interfaces to create IRQ for DMAR unit Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 22/24] x86, irq: Use hierarchy irqdomain to manage DMAR interrupts Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 23/24] x86, htirq: Use hierarchy irqdomain to manage Hypertransport interrupts Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:02 ` [RFT v2 24/24] x86, uv: Use hierarchy irqdomain to manage UV interrupts Jiang Liu 2014-09-26 14:02 ` Jiang Liu 2014-09-26 14:29 ` [RFT Part2 v2 00/24] Enable hierarchy irqdomian on x86 platforms Borislav Petkov 2014-09-26 14:29 ` Borislav Petkov 2014-09-26 16:30 ` Aravind Gopalakrishnan 2014-09-26 16:30 ` Aravind Gopalakrishnan 2014-09-26 16:30 ` Aravind Gopalakrishnan 2014-09-28 11:05 ` Borislav Petkov 2014-09-28 11:05 ` Borislav Petkov 2014-09-28 11:15 ` Jiang Liu 2014-09-28 11:15 ` Jiang Liu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=543346CD.4070308@linux.intel.com \ --to=jiang.liu@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=benh@kernel.crashing.org \ --cc=bhelgaas@google.com \ --cc=bp@alien8.de \ --cc=grant.likely@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=joro@8bytes.org \ --cc=konrad.wilk@oracle.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=mingo@redhat.com \ --cc=rdunlap@infradead.org \ --cc=rjw@rjwysocki.net \ --cc=tglx@linutronix.de \ --cc=tony.luck@intel.com \ --cc=wuyun.wu@huawei.com \ --cc=x86@kernel.org \ --cc=yinghai@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.