From patchwork Thu Sep 10 10:55:34 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 7153501 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.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id F131BBEEC1 for ; Thu, 10 Sep 2015 10:58:05 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E449720880 for ; Thu, 10 Sep 2015 10:58:04 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D003A2087F for ; Thu, 10 Sep 2015 10:58:03 +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 1ZZzWP-0000PJ-EF; Thu, 10 Sep 2015 10:56:05 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZZzWL-0000NZ-Jj for linux-arm-kernel@lists.infradead.org; Thu, 10 Sep 2015 10:56:02 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 34D6C3EF; Thu, 10 Sep 2015 03:55:49 -0700 (PDT) Received: from [10.1.209.148] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 522453F317; Thu, 10 Sep 2015 03:55:36 -0700 (PDT) Message-ID: <55F161A6.7070602@arm.com> Date: Thu, 10 Sep 2015 11:55:34 +0100 From: Marc Zyngier Organization: ARM Ltd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Julien Grall , Thomas Gleixner , Jason Cooper , Pranavkumar Sawargaonkar Subject: Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1 References: <1440604845-28229-1-git-send-email-marc.zyngier@arm.com> <1440604845-28229-4-git-send-email-marc.zyngier@arm.com> <55F08731.3050402@citrix.com> <55F15353.2000800@arm.com> In-Reply-To: <55F15353.2000800@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150910_035601_666706_B2588A66 X-CRM114-Status: GOOD ( 39.13 ) X-Spam-Score: -6.9 (------) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ian Campbell , kvm@vger.kernel.org, Eric Auger , Stefano Stabellini , linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Jiang Liu , Christoffer Dall Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_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 10/09/15 10:54, Marc Zyngier wrote: > Hi Julian, > > On 09/09/15 20:23, Julien Grall wrote: >> Hi, >> >> I've been trying the latest linus/master (a794b4f), which include this >> patch, as baremetal kernel on X-gene. This is failing on early boot >> without much log. >> >> After bisecting the tree, I found the error coming from this patch. >> While this patch is valid, it made me remembered that X-Gene (at least >> the first version) as an odd GICv2. >> >> The GICC is divided in 2 area of 4K, each one aligned at a 64KB address. >> This means that, the address of GICC_DIR won't be 0x1000 but 0x10000. > > Not really. I already mentioned that one a while ago: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332249.html > > The first page of GIC is aliased over the first 64kB, and the second > page aliased over the second 64kB. So you get a consistent mapping if > you use (base + 0xF000) to address GICC. Also, the DT that's in > mainline is showing a 4kB CPU interface, which doesn't enable > EOImode==1. You must be using a firmware that's newer than mine, since > I'm perfectly able to boot my Mustang with these patches. > >> We had the same issue on Xen when we did the first port of X-gene [1]. >> Although, we choose to add a quirk in Xen for this platform in order to >> map contiguously in the virtual memory the 2 part of GICC. >> >> Note that, back then, Ian suggested to extend the bindings to support a >> such platform [2]. AFAICT, there was no follow-up on it. > > The main problem here is not to update the binding, but the fact that > you *cannot* update the DT on x-gene (the firmware will replace your > GIC node with what it thinks it is), and the APM guys can't be bothered > to fix their stuff. > > In the meantime, can you give the following patch a shot? My Mustang is > wired to a 4kB CPU interface, so I'll need your help to test it. > > Thanks, > > M. > > From f0f086a4462198a5a2ac840901d9b8fd23b25134 Mon Sep 17 00:00:00 2001 > From: Marc Zyngier > Date: Thu, 10 Sep 2015 10:23:45 +0100 > Subject: [PATCH] irqchip/GIC: Add workaround for aliased GIC400 > > The GICv2 architecture mandates that the two 4kB GIC regions are > contiguous, and on two separate physical pages. This doesn't work > very well when PAGE_SIZE is 64kB. > > A relatively common hack to work around this is to alias each 4kB > region over its own 64kB page. Of course in this case, the base > address you want to use is not really the begining of the region, > but base + 60kB (so that you get a contiguous 8kB region over two > distinct pages). > > Normally, this would be describe in DT with a new property, but > some HW is already out there, and the firmware makes sure that > it will override whatever you put in the GIC node. Duh. And of course, > said firmware source code is not available, despite being based > on u-boot. > > The workaround is to detect the case where the CPU interface size > is set to 128kB, and verify the aliasing by checking that the ID > register for GIC400 (which is the only GIC wired this way so far) > is the same at base and base + 0xF000. In this case, we update > the GIC base address and let it roll. > > And if you feel slightly sick by looking at this, rest assured that > I do too... > > Reported-by: Julien Grall > Signed-off-by: Marc Zyngier > --- > drivers/irqchip/irq-gic.c | 45 ++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 40 insertions(+), 5 deletions(-) > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index e6b7ed5..b62f2b2 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -1119,12 +1119,50 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start, > #ifdef CONFIG_OF > static int gic_cnt __initdata; > > +static bool gic_check_eoimode(struct device_node *node, void __iomem **base) > +{ > + struct resource cpuif_res; > + > + of_address_to_resource(node, 1, &cpuif_res); > + > + if (!is_hyp_mode_available()) > + return false; > + if (resource_size(&cpuif_res) < SZ_8K) > + return false; > + if (resource_size(&cpuif_res) == SZ_128K) { > + u32 val; > + > + /* > + * Verify that we have a GIC400 aliased over the first > + * 64kB by checking the GICC_IIDR register. > + */ > + val = readl_relaxed(*base + GIC_CPU_IDENT); > + if (val != 0x0202043B) > + return false; > + > + val = readl_relaxed(*base + GIC_CPU_IDENT + 0xF000); > + if (val != 0x0202043B) > + return false; > + > + /* > + * Move the base up by 60kB, so that we have a 8kB > + * contiguous region, which allows us to use GICC_DIR > + * at its normal offset. > + */ > + *base += 0xF000; > + cpuif_res.start += 0xF000; > + pr_warn("GIC: Adjusting CPU interface base to %pa", > + &cpuif_res.start); > + } > + > + return true; > +} > + > static int __init > gic_of_init(struct device_node *node, struct device_node *parent) > { > void __iomem *cpu_base; > void __iomem *dist_base; > - struct resource cpu_res; > u32 percpu_offset; > int irq; > > @@ -1137,14 +1175,11 @@ gic_of_init(struct device_node *node, struct device_node *parent) > cpu_base = of_iomap(node, 1); > WARN(!cpu_base, "unable to map gic cpu registers\n"); > > - of_address_to_resource(node, 1, &cpu_res); > - > /* > * Disable split EOI/Deactivate if either HYP is not available > * or the CPU interface is too small. > */ > - if (gic_cnt == 0 && (!is_hyp_mode_available() || > - resource_size(&cpu_res) < SZ_8K)) > + if (gic_cnt == 0 && !gic_check_eoimode(node, &cpu_base)) > static_key_slow_dec(&supports_deactivate); > > if (of_property_read_u32(node, "cpu-offset", &percpu_offset)) > Meh. Multiple revisions of GIC400. This patchlet on top of the above should take care of it: Thanks, M. diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index b62f2b2..a9ecb29 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -1122,6 +1122,8 @@ static int gic_cnt __initdata; static bool gic_check_eoimode(struct device_node *node, void __iomem **base) { struct resource cpuif_res; + u32 mask = 0xffff0fff; + u32 gic400_id = 0x0202043B; of_address_to_resource(node, 1, &cpuif_res); @@ -1137,11 +1139,11 @@ static bool gic_check_eoimode(struct device_node *node, void __iomem **base) * 64kB by checking the GICC_IIDR register. */ val = readl_relaxed(*base + GIC_CPU_IDENT); - if (val != 0x0202043B) + if ((val & mask) != gic400_id) return false; val = readl_relaxed(*base + GIC_CPU_IDENT + 0xF000); - if (val != 0x0202043B) + if ((val & mask) != gic400_id) return false; /*