From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Andrew Lunn <andrew@lunn.ch>,
Gregory Clement <gregory.clement@bootlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Antoine Tenart <antoine.tenart@bootlin.com>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Nadav Haklai <nadavh@marvell.com>, Haim Boot <hayim@marvell.com>,
Hanna Hawa <hannah@marvell.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 09/16] irqchip/irq-mvebu-sei: add new driver for Marvell SEI
Date: Fri, 8 Jun 2018 12:26:09 +0200 [thread overview]
Message-ID: <20180608122609.0bb051f6@xps13> (raw)
In-Reply-To: <b11849f0-3593-51e1-8d4f-b05bfe6412a1@arm.com>
Hi Marc,
> > +static struct irq_chip mvebu_sei_ap_wired_irq_chip = {
> > + .name = "AP wired SEI",
> > + .irq_mask = mvebu_sei_mask_irq,
> > + .irq_unmask = mvebu_sei_unmask_irq,
> > + .irq_eoi = irq_chip_eoi_parent,
> > + .irq_set_affinity = irq_chip_set_affinity_parent,
> > + .irq_set_type = irq_chip_set_type_parent,
>
> You seem to assume that this driver is purely dealing with edge
> interrupts. And yet you pass the request directly to the parrent. What
> does it mean? Shouldn't you at least check that this is an edge request
> and fail otherwise?
MSI are rising-edge interrupts while wired ones are level (high)
interrupts. I will correct this.
> > + irq_chip = &mvebu_sei_ap_wired_irq_chip;
> > + hwirq = fwspec->param[0];
> > + } else {
> > + irq_chip = &mvebu_sei_cp_msi_irq_chip;
> > + spin_lock(&sei->cp_msi_lock);
>
> This could as well be a mutex.
Ok.
>
> > + hwirq = bitmap_find_free_region(sei->cp_msi_bitmap,
> > + SEI_IRQ_COUNT, 0);
>
> It is a bit weird that you're allocating from a 64bit bitmap while you
> only have 43 interrupts available... At the 44th interrupt, something
> bad is going to happen.
Absolutely, to solve this issue, I just had to:
s/SEI_IRQ_COUNT/sei->cp_interrupts.number/
>
> > + spin_unlock(&sei->cp_msi_lock);
> > + if (hwirq < 0)
> > + return -ENOSPC;
> > + }
> > +
[...]
> > +static void mvebu_sei_handle_cascade_irq(struct irq_desc *desc)
> > +{
> > + struct mvebu_sei *sei = irq_desc_get_handler_data(desc);
> > + struct irq_chip *chip = irq_desc_get_chip(desc);
> > + unsigned long irqmap, irq_bit;
> > + u32 reg_idx, virq, irqn;
> > +
> > + chained_irq_enter(chip, desc);
> > +
> > + /* Read both SEI cause registers (64 bits) */
> > + for (reg_idx = 0; reg_idx < SEI_IRQ_REG_COUNT; reg_idx++) {
> > + irqmap = readl_relaxed(sei->base + GICP_SECR(reg_idx));
> > +
> > + /* Call handler for each set bit */
> > + for_each_set_bit(irq_bit, &irqmap, SEI_IRQ_COUNT_PER_REG) {
> > + /* Cause Register gives the SEI number */
> > + irqn = irq_bit + reg_idx * SEI_IRQ_COUNT_PER_REG;
> > + /*
> > + * Finding Linux mapping (virq) needs the right domain
> > + * and the relative hwirq (which start at 0 in both
> > + * cases, while irqn is relative to all SEI interrupts).
> > + */
>
> It is a bit odd that you're virtualizing the hwirq number. The whole
> point of splitting hwirq from virq is that you don't have to do that and
> can use the the raw HW number. You're saving a tiny bit of memory in the
> irq_domain, at the expense of more complexity. I don't know if that's
> worth it...
>
> > + if (irqn < sei->ap_interrupts.number) {
> > + virq = irq_find_mapping(sei->ap_domain, irqn);
> > + } else {
> > + irqn -= sei->ap_interrupts.number;
> > + virq = irq_find_mapping(sei->cp_domain, irqn);
> > + }
> > +
> > + /* Call IRQ handler */
> > + generic_handle_irq(virq);
> > + }
> > +
> > + /* Clear interrupt indication by writing 1 to it */
> > + writel(irqmap, sei->base + GICP_SECR(reg_idx));
> > + }
> > +
> > + chained_irq_exit(chip, desc);
> > +}
[...]
> It feels like this patch could do with a total split:
>
> - Introduce the wired side of the driver
> - then the MSI part
>
> Drop the common domain callbacks, and treat the two domains separately.
> I seriously doubt there will be much of an overlap anyway.
Maybe I don't get what "saving a tiny bit of memory" really means in
this situation. What I am doing right now is duplicating hundreds of
lines and changing things like:
sei_hwirq = mvebu_sei_domain_to_sei_irq(..., hwirq)
into
sei_hwirq = sei->ap_interrupts.first + d->hwirq;
and
sei_hwirq = sei->cp_interrupts.first + d->hwirq;
because I still need to translate this hwirq number into an offset
within 64 bits. In fact, for each configuration/management operation
like clearing, checking or masking an interrupt, a bit must be twisted
within a pair of registers. This offset cannot be just the hwirq
number, it must be shifted depending on the IRQ domain/type of
interrupt.
I'm sorry but I will need more guidance on this because I don't see the
point in duplicating so much code that was factorized.
Thanks,
Miquèl
next prev parent reply other threads:[~2018-06-08 10:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 9:40 [PATCH v2 00/16] Add System Error Interrupt support to Armada SoCs Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 01/16] dt-bindings/interrupt-controller: fix Marvell ICU length in the example Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 02/16] arm64: dts: marvell: fix CP110 ICU node size Miquel Raynal
2018-05-23 7:36 ` Gregory CLEMENT
2018-05-22 9:40 ` [PATCH v2 03/16] irqchip/irq-mvebu-icu: fix wrong private data retrieval Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 04/16] irqchip/irq-mvebu-icu: clarify the reset operation of configured interrupts Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 05/16] irqchip/irq-mvebu-icu: switch to regmap Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 06/16] irqchip/irq-mvebu-icu: make irq_domain local Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 07/16] irqchip/irq-mvebu-icu: disociate ICU and NSR Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 08/16] irqchip/irq-mvebu-icu: support ICU subnodes Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 09/16] irqchip/irq-mvebu-sei: add new driver for Marvell SEI Miquel Raynal
2018-05-23 14:05 ` Marc Zyngier
2018-06-08 10:26 ` Miquel Raynal [this message]
2018-05-22 9:40 ` [PATCH v2 10/16] arm64: marvell: enable SEI driver Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 11/16] irqchip/irq-mvebu-icu: add support for System Error Interrupts (SEI) Miquel Raynal
2018-05-23 14:23 ` Marc Zyngier
2018-06-08 13:08 ` Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 12/16] dt-bindings/interrupt-controller: update Marvell ICU bindings Miquel Raynal
2018-06-05 20:29 ` Rob Herring
2018-06-05 20:35 ` Thomas Petazzoni
2018-06-08 14:00 ` Miquel Raynal
2018-06-08 21:34 ` Rob Herring
2018-05-22 9:40 ` [PATCH v2 13/16] dt-bindings/interrupt-controller: add documentation for Marvell SEI controller Miquel Raynal
2018-06-05 20:51 ` Rob Herring
2018-06-08 14:46 ` Miquel Raynal
2018-06-22 14:57 ` Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 14/16] arm64: dts: marvell: add AP806 SEI subnode Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 15/16] arm64: dts: marvell: use new bindings for CP110 interrupts Miquel Raynal
2018-05-22 9:40 ` [PATCH v2 16/16] arm64: dts: marvell: add CP110 ICU SEI subnode Miquel Raynal
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=20180608122609.0bb051f6@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=andrew@lunn.ch \
--cc=antoine.tenart@bootlin.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=gregory.clement@bootlin.com \
--cc=hannah@marvell.com \
--cc=hayim@marvell.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=maxime.chevallier@bootlin.com \
--cc=nadavh@marvell.com \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tglx@linutronix.de \
--cc=thomas.petazzoni@bootlin.com \
--cc=will.deacon@arm.com \
/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;
as well as URLs for NNTP newsgroup(s).