From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC Part4 v1 00/17] Refine support of non-PCI-compliant Message
Date: Thu, 13 Nov 2014 14:27:42 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.11.1411131410560.3935@nanos> (raw)
In-Reply-To: <546495AB.9050308@arm.com>
On Thu, 13 Nov 2014, Marc Zyngier wrote:
> On 12/11/14 14:46, Thomas Gleixner wrote:
> > On Wed, 12 Nov 2014, Marc Zyngier wrote:
> >> This patch introduces two optionnal fields to the msi_chip structure:
> >> - a pointer to an irq domain, describing the MSI domain associated
> >> with this msi_chip. To be populated with msi_create_irq_domain.
> >> - a domain_alloc_irqs() callback that has the same purpose as
> >> arch_setup_msi_irqs(), with the above domain as an additional
> >> parameter.
> >>
> >> If both of these fields are non-NULL, then domain_alloc_irqs() is
> >> called, bypassing the setup_irq callback. This allows the MSI driver
> >> to use the domain stacking feature without mandating core support in
> >> the architecture.
> >
> > I'd rather have the callback in the irqdomain itself. Along with a
> > callback to free the interrupts.
> >
> > AFAICT is msi_chip more or less a wrapper around the actual MSI irq
> > domain. So we rather move towards assigning irqdomain to the pci bus
> > and get rid of msi_chip instead of adding another level of obscure
> > indirection through msi_chip.
>
> I can see that putting the irq domain at the bus level makes a lot of
> sense (assuming nobody tries to have multiple MSI controllers per bus...).
That would be interesting :)
> So I'm starting with something like this:
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 640a1ec..07e50fc 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -41,6 +41,7 @@ struct irq_domain;
> struct of_device_id;
> struct irq_chip;
> struct irq_data;
> +struct device;
>
> /* Number of irqs reserved for a legacy isa controller */
> #define NUM_ISA_INTERRUPTS 16
> @@ -76,6 +77,10 @@ struct irq_domain_ops {
> unsigned int nr_irqs);
> void (*activate)(struct irq_domain *d, struct irq_data *irq_data);
> void (*deactivate)(struct irq_domain *d, struct irq_data *irq_data);
> + int (*prepare_alloc_irqs)(struct irq_domain *d, struct device *dev,
> + unsigned int nr_irqs, int type);
> + int (*cleanup_free_irqs)(struct irq_domain *d, struct device *dev,
> + unsigned int virq, unsigned int nr_irqs);
> #endif
> };
>
> How do you see this behaving? At the moment, I have the "prepare" callback
> directly calling into pci_msi_domain_alloc_irqs() so that the irqs get
> created, but I have the nagging feeling that it's not what you want... ;-)
> The main issue I can see is that if more than one domain in the stack
> implements that, who gets to call pci_msi_domain_alloc_irqs?
>
> If we try to decouple those two, there is a problem with the creation of
> the intermediate structure (the irq_alloc_info that's in Jiang's patches),
> as this is a arch/driver/whatever specific structure.
Hard to tell. I just saw Jiangs new series arrive and I want to look
at that first before muttering nonsense.
Thanks,
tglx
prev parent reply other threads:[~2014-11-13 13:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-09 15:10 [RFC Part4 v1 00/17] Refine support of non-PCI-compliant Message Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 01/17] x86, irq: Normalize x86 irq_chip name Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 02/17] genirq: Introduce helper irq_domain_set_info() to reduce duplicated code Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 03/17] x86, PCI/MSI: Simplify the way to deal with remapped MSI interrupts Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 04/17] PCI/MSI: Replace msi_update_msg() with irq_chip_compose_msi_msg() Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 05/17] PCI/MSI: Move msi_set_affinity() to PCI core Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 06/17] genirq: Introduce callback irq_chip.irq_write_msi_msg Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 07/17] x86, irq: Implement irq_chip.irq_write_msi_msg for MSI/DMAR/HPET irq_chips Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 08/17] PCI/MSI: Use irq_chip.irq_write_msi_msg() to share common code Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 09/17] x86, irq: Simplify MSI/DMAR/HPET implementation by using " Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 10/17] PCI, MSI: Split MSI code into PCI dependent and PCI independent parts Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 11/17] PCI, MSI: Rename __read_msi_msg() as __pci_read_msi_msg() Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 12/17] PCI, MSI: Rename __write_msi_msg() as __pci_write_msi_msg() Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 13/17] MSI: Provide irqdomain support for generic MSI Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 14/17] x86, PCI, MSI: Use common code to manage MSI interrupts Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 15/17] PCI, MSI: Clean up unused irqdomain related code Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 16/17] x86, htirq: Kill struct ht_irq_msg by reusing struct msi_msg Jiang Liu
2014-11-09 15:10 ` [RFC Part4 v1 17/17] x86, htirq: Use common MSI code to manage Hypertransport interrupts Jiang Liu
2014-11-12 13:47 ` [RFC Part4 v1 00/17] Refine support of non-PCI-compliant Message Marc Zyngier
2014-11-12 14:46 ` Thomas Gleixner
2014-11-12 14:52 ` Jiang Liu
2014-11-13 11:27 ` Marc Zyngier
2014-11-13 13:27 ` Thomas Gleixner [this message]
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=alpine.DEB.2.11.1411131410560.3935@nanos \
--to=tglx@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox