Skip to contentSkip to conversation

irqchip: vt8500: Properly mask the interrupt in irq_mask()

PATCH RESEND In review Axel Lin 2 participants 3 messages May 4, 2014 – May 11, 2014 1 message not in the archive irqchip drivers

lore
Share & tools
lore

Axel Lin

author
#0 lore raw

PATCH RESEND 1/1 irqchip: vt8500: Properly mask the interrupt in irq_mask()

Current code sets both irq_ack and irq_mask callbacks to vt8500_irq_mask(). However, vt8500_irq_mask does not clear interrupt enable bit when the interrupt trigger mode is edge trigger.

This patch moves the code clearing Interrupt Status Register bit to irq_ack(). Make irq_mask() always clear interrupt enable bit for all interrupt trigger mode.

According to the datasheet, the Interrupt Status Register is written one to clear(Write 0 has no effect). So we don't need a read-modify-write operation for clearing a bit in interrupt status register.

---
Resend and also CC: [email protected]. I appreciate if someone can test this patch.
Thanks,
Axel

 drivers/irqchip/irq-vt8500.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)
drivers/irqchip/irq-vt8500.c +15 -16
index d970595..eb6d05a 100644
@@ -81,25 +81,24 @@ struct vt8500_irq_data {
 static struct vt8500_irq_data intc[VT8500_INTC_MAX];
 static u32 active_cnt = 0;
 
-static void vt8500_irq_mask(struct irq_data *d)
+static void vt8500_irq_ack(struct irq_data *d)
 {
 	struct vt8500_irq_data *priv = d->domain->host_data;
 	void __iomem *base = priv->base;
 	void __iomem *stat_reg = base + VT8500_ICIS + (d->hwirq < 32 ? 0 : 4);
-	u8 edge, dctr;
-	u32 status;
-
-	edge = readb(base + VT8500_ICDC + d->hwirq) & VT8500_EDGE;
-	if (edge) {
-		status = readl(stat_reg);
-
-		status |= (1 << (d->hwirq & 0x1f));
-		writel(status, stat_reg);
-	} else {
-		dctr = readb(base + VT8500_ICDC + d->hwirq);
-		dctr &= ~VT8500_INT_ENABLE;
-		writeb(dctr, base + VT8500_ICDC + d->hwirq);
-	}
+
+	writel(1 << (d->hwirq & 0x1f), stat_reg);
+}
+
+static void vt8500_irq_mask(struct irq_data *d)
+{
+	struct vt8500_irq_data *priv = d->domain->host_data;
+	void __iomem *base = priv->base;
+	u8 dctr;
+
+	dctr = readb(base + VT8500_ICDC + d->hwirq);
+	dctr &= ~VT8500_INT_ENABLE;
+	writeb(dctr, base + VT8500_ICDC + d->hwirq);
 }
 
 static void vt8500_irq_unmask(struct irq_data *d)
@@ -145,7 +144,7 @@ static int vt8500_irq_set_type(struct irq_data *d, unsigned int flow_type)
 
 static struct irq_chip vt8500_irq_chip = {
 	.name = "vt8500",
-	.irq_ack = vt8500_irq_mask,
+	.irq_ack = vt8500_irq_ack,
 	.irq_mask = vt8500_irq_mask,
 	.irq_unmask = vt8500_irq_unmask,
 	.irq_set_type = vt8500_irq_set_type,
Signature · 1 line
1.8.1.2
#1 lore raw

2014-05-04 7:14 GMT+04:00 Axel Lin <[email protected]>:

Quoted 7 lines

Current code sets both irq_ack and irq_mask callbacks to vt8500_irq_mask(). However, vt8500_irq_mask does not clear interrupt enable bit when the interrupt trigger mode is edge trigger.

This patch moves the code clearing Interrupt Status Register bit to irq_ack(). Make irq_mask() always clear interrupt enable bit for all interrupt trigger mode.

Quoted 8 lines

According to the datasheet, the Interrupt Status Register is written one to clear(Write 0 has no effect). So we don't need a read-modify-write operation for clearing a bit in interrupt status register.

---
Resend and also CC: [email protected]. I appreciate if someone can test this patch.

Axel, I believe the change makes perfect sense. Current code seems to be based on my original code that was in turn based on very limited understanding of the hardware, and furthermore I don't think that any of the existing drivers use edge-triggered interrupts anyway.

The way you've structured it seems more logical, so I would be happy for this to be merged.

Just booted a kernel with this patch on my WM8850, and everything seems to work fine. Can't really say 'Tested-by', though, given the above (no existing uses of edge-triggered interrupts that I'm aware of).

Thanks a lot,
Alexey

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw

2014-05-11 23:29 GMT+04:00 lautriv <[email protected]>:

Quoted 3 lines

Alexey, i wonder how you can tell "all works fine" since 8850 is still vomiting a bunch when it comes to I2C or GPIO. Maybe i missed some changes there ?

I've never noticed anything like that on my machine... Note though that I don't use I2C actively (or at all), and I'm currently on mainline 3.15-rc2 with just Rhine patches on top (upstream for 3.16) and some changes in dts to suit my netbook. GPIO works fine for me - I've only applied another one-liner to make 'echo high > direction' work (also upstream now).

I've got a fully functioning Fedora 20 on my WM8850 (except sound and other known-missing parts, of course). It's updating KDE4 as I type :-)

Best,
Alexey