From patchwork Mon Jul 14 03:22:26 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Liu hua X-Patchwork-Id: 4542371 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 033F6C0514 for ; Mon, 14 Jul 2014 03:26:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2C85220145 for ; Mon, 14 Jul 2014 03:26:24 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 430732012D for ; Mon, 14 Jul 2014 03:26:23 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1X6Wrh-000125-1h; Mon, 14 Jul 2014 03:23:45 +0000 Received: from szxga01-in.huawei.com ([119.145.14.64]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1X6Wre-0000zz-3r for linux-arm-kernel@lists.infradead.org; Mon, 14 Jul 2014 03:23:43 +0000 Received: from 172.24.2.119 (EHLO szxeml402-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYS27910; Mon, 14 Jul 2014 11:22:42 +0800 (CST) Received: from [127.0.0.1] (10.111.58.238) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server id 14.3.158.1; Mon, 14 Jul 2014 11:22:29 +0800 Message-ID: <53C34CF2.5050209@huawei.com> Date: Mon, 14 Jul 2014 11:22:26 +0800 From: Liu hua User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Will Deacon Subject: Re: [RFC PATCH 0/2] irqchip: GIC: check and clear GIC interupt active status References: <1405061177-43834-1-git-send-email-sdu.liu@huawei.com> <20140711123507.GE12899@arm.com> In-Reply-To: <20140711123507.GE12899@arm.com> X-Originating-IP: [10.111.58.238] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140713_202342_549115_81C2E65A X-CRM114-Status: GOOD ( 15.69 ) X-Spam-Score: -0.7 (/) Cc: "nicolas.pitre@linaro.org" , "wangnan0@huawei.com" , "linux@arm.linux.org.uk" , "jason@lakedaemon.net" , marc.zyngier@arm.com, "liusdu@126.com" , "linux-kernel@vger.kernel.org" , "ebiederm@xmission.com" , "liuxueliu.liu@huawei.com" , "tglx@linutronix.de" , "linux-arm-kernel@lists.infradead.org" , "peifeiyue@huawei.com" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 2014/7/11 20:35, Will Deacon wrote: > [adding Marc] > > On Fri, Jul 11, 2014 at 07:46:15AM +0100, Liu Hua wrote: >> For this version of GIC codes, kernel assumes that all the interrupt >> status of GIC is inactive. So the kernel does not check this when >> booting. >> >> This is no problem on must sitations. But when kdump is deplayed. >> And a panic occurs when a interrupt is being handled (may be PPI >> and SPI). We have no chance to write relative bit to GICC_EOIR. >> So this interrupt remains active. And GIC will not deliver this >> type interrupt to cpu interface. And the capture kernel may >> fail to boot becase of lacking of certain interrupt (such as timer >> interupt). >> >> >> I glanced over the GIC Architecture Specification, but did not >> find a simple way to deactive state of all interrupts. For GICv1, >> I can only deal with one abnormal interrupt state one time. For >> GICv2, I can deactive 32 one time. >> >> >> So guys, Do you know a better way to do that? > > What happens if, in the crash kernel, you disable the CPU interfaces > (GICC_CTLR.ENABLE) then disable the distributor (GICD_CTLR.ENABLE) before > enabling everything again in the reverse order? Is that enough to cause the > GIC to drop any active states? It's not clear to me from a quick look at > the TRM. > Hi Will, Thanks for your reply! I did what you said at the beginning of "gic_dist_init". The active states remained (panic in local timer interrupt (PPI))and the kernel failed to boot, Did I do that at wrong place? ------------------- ------------------------ As shown in GIC Architecture Specification manual,I think that the GICC_CTLR.ENABLE and GICD_CTLR.ENABLE only control the delivering of the interrupt, not the active states. As GIC manual says "For every read of a valid Interrupt ID from the GICC_IAR, the connected processor must perform a matching write to the GICC_EOIR". So we should find a way to drop the active states when booting, if we do not remain these active states by design. Thanks, Liu Hua > Will > > . > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index b6b0a81..94d6352 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -454,6 +455,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic) void __iomem *base = gic_data_dist_base(gic); void __iomem *cpu_base = gic_data_cpu_base(gic); + writel_relaxed(0, base + GIC_CPU_CTRL); writel_relaxed(0, base + GIC_DIST_CTRL); /*