From patchwork Tue Jul 15 09:41:25 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Thompson X-Patchwork-Id: 33650 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-qc0-f200.google.com (mail-qc0-f200.google.com [209.85.216.200]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id B7A1120CAD for ; Tue, 15 Jul 2014 09:41:49 +0000 (UTC) Received: by mail-qc0-f200.google.com with SMTP id m20sf7192880qcx.7 for ; Tue, 15 Jul 2014 02:41:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe:content-type :content-transfer-encoding; bh=c3SuyJrWn0CZU3UOV9LxPUSa0Urx9nCZzeAuFHBx6u8=; b=V8qaGT/zinPfHg1UsZUTgfD16H5g4634O/VBSVqXaZhhYlOzJgixFOuWzpkcN9sIDi jl9QUaNcLa8vStjbEgOhDURk53/UwRWN/NAdzbPhZrET4tmf0y7/Nhnl7pN9zXIehjk8 1xCWq814gUM1XvjcY80gypFfbcYw3/GFLupmRZwc0zAXAW3+ifNNMISvo+Bf8M1ucveI vpJFf2Ccb9as9kYtITHwsl9tEhDeWQrNCt0wu2EepvmR0+TASCJN3BvFVESejlQNeR6L 9l1rDQCNndfvodYQbDbM6Yevcd/gEvIP69rcmepTAscsxA+LX0+1dRVbcxQhTT113IKw AIhQ== X-Gm-Message-State: ALoCoQnFEVX+xjMq73CTYJxJN1hn8tIGIWwK8y/Rw0rYhRg2isvZA+vm9adb46RrbiCUyq6Ui6ut X-Received: by 10.52.114.42 with SMTP id jd10mr9169452vdb.0.1405417309582; Tue, 15 Jul 2014 02:41:49 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.30.36 with SMTP id c33ls38734qgc.72.gmail; Tue, 15 Jul 2014 02:41:49 -0700 (PDT) X-Received: by 10.58.113.69 with SMTP id iw5mr12178952veb.23.1405417309490; Tue, 15 Jul 2014 02:41:49 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id y3si6443573vdx.29.2014.07.15.02.41.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 02:41:49 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.172 as permitted sender) client-ip=209.85.220.172; Received: by mail-vc0-f172.google.com with SMTP id hq11so8465349vcb.17 for ; Tue, 15 Jul 2014 02:41:49 -0700 (PDT) X-Received: by 10.53.5.162 with SMTP id cn2mr1552449vdd.23.1405417309411; Tue, 15 Jul 2014 02:41:49 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.221.37.5 with SMTP id tc5csp200481vcb; Tue, 15 Jul 2014 02:41:48 -0700 (PDT) X-Received: by 10.194.89.168 with SMTP id bp8mr26175599wjb.73.1405417308029; Tue, 15 Jul 2014 02:41:48 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by mx.google.com with ESMTPS id f15si19183952wjr.124.2014.07.15.02.41.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 02:41:48 -0700 (PDT) Received-SPF: pass (google.com: domain of daniel.thompson@linaro.org designates 74.125.82.173 as permitted sender) client-ip=74.125.82.173; Received: by mail-we0-f173.google.com with SMTP id q58so357443wes.32 for ; Tue, 15 Jul 2014 02:41:47 -0700 (PDT) X-Received: by 10.180.207.48 with SMTP id lt16mr4299975wic.32.1405417307360; Tue, 15 Jul 2014 02:41:47 -0700 (PDT) Received: from harvey.bri.st.com (cpc4-aztw19-0-0-cust157.18-1.cable.virginm.net. [82.33.25.158]) by mx.google.com with ESMTPSA id ft17sm31437648wjc.14.2014.07.15.02.41.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 02:41:46 -0700 (PDT) Message-ID: <53C4F745.3070701@linaro.org> Date: Tue, 15 Jul 2014 10:41:25 +0100 From: Daniel Thompson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Harro Haan CC: Russell King , linaro-kernel@lists.linaro.org, Catalin Marinas , patches@linaro.org, kgdb-bugreport@lists.sourceforge.net, Linus Walleij , Nicolas Pitre , linux-kernel@vger.kernel.org, Frederic Weisbecker , Anton Vorontsov , Ben Dooks , John Stultz , Fabio Estevam , Colin Cross , kernel-team@android.com, Dave Martin , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v8 0/4] arm: KGDB NMI/FIQ support References: <1404118391-3850-1-git-send-email-daniel.thompson@linaro.org> <1404979427-12943-1-git-send-email-daniel.thompson@linaro.org> In-Reply-To: X-Enigmail-Version: 1.6 X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: daniel.thompson@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.172 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On 14/07/14 14:51, Harro Haan wrote: > On 10 July 2014 10:03, Daniel Thompson wrote: >> >> This patchset makes it possible to use kgdb's NMI infrastructure on ARM >> platforms. >> >> The patches have been previously circulated as part of a large patchset >> mixing together ARM architecture code and driver changes >> (http://thread.gmane.org/gmane.linux.ports.arm.kernel/333901 ). This >> patchset is dramatically cut down to include only the arch/arm code. The >> driver code (irqchip and tty/serial) will follow when/if the arch code >> is accepted. >> >> The first two patches modify the FIQ infrastructure to allow interrupt >> controller drivers to register callbacks (the fiq_chip structure) to >> manage FIQ routings and to ACK and EOI the FIQ. This makes it possible >> to use FIQ in multi-platform kernels and with recent ARM interrupt >> controllers. >> > > Daniel, > > Thanks for the patches. I have tested the fiq and irq-gic patches on > an i.MX6 (SabreSD board) for a different purpose: > A FIQ timer interrupt at 1 kHz. The TWD watchdog block is used in > timer mode for this (interrupt ID 30). The GIC affinity is set to CPU > core 0 only for this interrupt ID. > > I was surprised by the following behavior: > $ cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 29: 5459 3381 3175 3029 GIC 29 twd > 30: 11 0 0 0 GIC 30 fake-fiq > > Once every few seconds is interrupt ID 30 handled by the regular GIC > handler instead of the FIQ exception path (which causes for example a > bit more latencies). The other thousands of FIQ's are handled by the > FIQ exception path. The problem is also confirmed by the following > stackframe of the Lauterbach tooling: > fake_fiq_handler(irq = 30, ...) > handle_percpu_devid_irq(irq = 30, ...) > generic_handle_irq(irq = 30) > handle_IRQ(irq = 30, ...) > gic_handle_irq > __irq_svc > -->exception > > Notes: > - The problem will occur more often by executing the following command: > $ while true; do hackbench 20; done & > - Reading the GIC_CPU_INTACK register returns the interrupt ID of the > highest priority pending interrupt. > - The GIC_CPU_INTACK register (used by fiq_ack) will return spurious > interrupt ID 0x3FF when read in fake_fiq_handler, because > GIC_CPU_INTACK is already read by gic_handle_irq. > - The FIQ exception will not occur anymore after gic_handle_irq > read/acknowledges the FIQ by reading the GIC_CPU_INTACK register > > From the behavior above I conclude that the GIC_CPU_INTACK register is > first updated before the FIQ exception is generated, so there is a > small period of time that gic_handle_irq can read/acknowledge the FIQ. Makes sense. Avoiding this problem on GICv2 is easy (thanks to the aliased intack register) but on iMX.6 we have only a GICv1. > I can reduce the number of occurrences (not prevent it) by adding the > following hack to irq-gic.c > @@ -297,10 +309,12 @@ static asmlinkage void __exception_irq_entry > gic_handle_irq(struct pt_regs *regs > u32 irqstat, irqnr; > struct gic_chip_data *gic = &gic_data[0]; > void __iomem *cpu_base = gic_data_cpu_base(gic); > > do { > + while(readl_relaxed(gic_data_dist_base(gic) + GIC_DIST_PENDING_SET) > & (1 << 30)) > + printk(KERN_ERR "TEMP: gic_handle_irq: wait for FIQ exception\n"); > irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK); > irqnr = irqstat & ~0x1c00; I've made a more complete attempt to fix this. Could you test the following? (and be prepared to fuzz the line numbers) { u32 irqstat, irqnr; @@ -310,8 +332,10 @@ static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs) void __iomem *cpu_base = gic_data_cpu_base(gic); do { + local_fiq_disable(); irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK); - irqnr = irqstat & GICC_IAR_INT_ID_MASK; + irqnr = gic_handle_spurious_group_0(gic, irqstat); + local_fiq_enable(); if (likely(irqnr > 15 && irqnr < 1021)) { irqnr = irq_find_mapping(gic->domain, irqnr); diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 73ae896..309bf2c 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -303,6 +303,28 @@ static int gic_set_wake(struct irq_data *d, unsigned int on) #define gic_set_wake NULL #endif +/* Check for group 0 interrupt spuriously acked as a normal IRQ. This + * workaround will only work for level triggered interrupts (and in + * its current form is actively harmful on systems that don't support + * FIQ). + */ +static u32 gic_handle_spurious_group_0(struct gic_chip_data *gic, u32 irqstat) +{ + u32 irqnr = irqstat & GICC_IAR_INT_ID_MASK; + + if (!gic_data_fiq_enable(gic) || irqnr >= 1021) + return irqnr; + + if (readl_relaxed(gic_data_dist_base(gic) + GIC_DIST_IGROUP + + (irqnr / 32 * 4)) & + BIT(irqnr % 32)) + return irqnr; + + /* this interrupt was spurious (needs to be handled as FIQ) */ + writel_relaxed(irqstat, gic_data_cpu_base(gic) + GIC_CPU_EOI); + return 1023; +} + static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)