From patchwork Mon Dec 1 10:32:00 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Sander X-Patchwork-Id: 5411421 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 07C54BEEA8 for ; Mon, 1 Dec 2014 10:36:47 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 10A2420295 for ; Mon, 1 Dec 2014 10:36:46 +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 19EF92010E for ; Mon, 1 Dec 2014 10:36:45 +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 1XvOJ0-0004ri-AJ; Mon, 01 Dec 2014 10:34:10 +0000 Received: from casper.infradead.org ([2001:770:15f::2]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XvOHk-0003xz-SD for linux-arm-kernel@bombadil.infradead.org; Mon, 01 Dec 2014 10:32:53 +0000 Received: from lvps176-28-13-145.dedicated.hosteurope.de ([176.28.13.145]) by casper.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XvOHi-0001KH-69 for linux-arm-kernel@lists.infradead.org; Mon, 01 Dec 2014 10:32:50 +0000 Received: from krieglstein.org (unknown [62.159.134.147]) by lvps176-28-13-145.dedicated.hosteurope.de (Postfix) with ESMTPSA id 69B8CA8A401B; Mon, 1 Dec 2014 11:32:01 +0100 (CET) From: Tim Sander To: Russell King - ARM Linux Subject: Re: [PATCH 3.18-rc3 v9 5/5] arm: smp: Handle ipi_cpu_backtrace() using FIQ (if available) Date: Mon, 01 Dec 2014 11:32 +0100 Message-ID: <1633306.naE1qIcAOt@dabox> Organization: Sander and Lightning User-Agent: KMail/4.14.2 (Linux/3.16.3; KDE/4.14.2; x86_64; ; ) In-Reply-To: <20141128100828.GQ3836@n2100.arm.linux.org.uk> References: <1415968543-29469-1-git-send-email-daniel.thompson@linaro.org> <13373554.4deCsZOMXS@dabox> <20141128100828.GQ3836@n2100.arm.linux.org.uk> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141201_103250_275442_2221C9C9 X-CRM114-Status: GOOD ( 40.10 ) X-Spam-Score: 0.1 (/) Cc: Daniel Thompson , linaro-kernel@lists.linaro.org, Jason Cooper , patches@linaro.org, linux-kernel@vger.kernel.org, Daniel Drake , Dmitry Pervushin , Dirk Behme , John Stultz , Thomas Gleixner , Sumit Semwal , linux-arm-kernel@lists.infradead.org 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=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, 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 Hi Russel, Daniel Am Freitag, 28. November 2014, 10:08:28 schrieb Russell King - ARM Linux: > On Fri, Nov 28, 2014 at 10:10:04AM +0100, Tim Sander wrote: > > Hi Daniel, Russell > > > > Am Mittwoch, 26. November 2014, 16:17:06 schrieb Daniel Thompson: > > > On 26/11/14 13:12, Russell King - ARM Linux wrote: > > > > On Wed, Nov 26, 2014 at 01:46:52PM +0100, Tim Sander wrote: > > > >> Hi Daniel > > > >> > > > >> Am Dienstag, 25. November 2014, 17:26:41 schrieb Daniel Thompson: > > > >>> Previous changes have introduced both a replacement default FIQ > > > >>> handler > > > >>> and an implementation of arch_trigger_all_cpu_backtrace for ARM but > > > >>> these are currently independent of each other. > > > >>> > > > >>> This patch plumbs together these features making it possible, on > > > >>> platforms > > > >>> that support it, to trigger backtrace using FIQ. > > > >> > > > >> Does this ipi handler interfere in any way with set_fiq_handler? > > > >> > > > >> As far as i know there is only one FIQ handler vector so i guess > > > >> there is > > > >> a > > > >> potential conflict. But i have not worked with IPI's so i might be > > > >> completley wrong. > > > > > > > > First, the code in arch/arm/kernel/fiq.c should work with this new FIQ > > > > code in that the new FIQ code is used as the "default" handler (as > > > > opposed to the original handler which was a total no-op.) > > > > > > > > Secondly, use of arch/arm/kernel/fiq.c in a SMP system is really not a > > > > good idea: the FIQ registers are private to each CPU in the system, > > > > and > > > > there is no infrastructure to allow fiq.c to ensure that it loads the > > > > right CPU with the register information for the provided handler. > > > > Well given the races in the GIC v1. i have seen in the chips on my desk > > initializing with for_each_possible_cpu(cpu) work_on_cpu(cpu,..) is rather > > easy. > > > > > > So, use of arch/arm/kernel/fiq.c and the IPI's use of FIQ /should/ be > > > > mutually exclusive. > > > > Yes but i digress on the assessment that this a decision between SMP and > > non- SMP usage or the availbility of the GIC. > > The two things are mutually exclusive. You can either have FIQ being used > for debug purposes, where we decode the FIQ reason and call some function > (which means that we will only service one FIQ at a time) or you can use > it in exclusive mode (provided by fiq.c) where your handler has sole usage > of the vector, and benefits from fast and immediate servicing of the event. As far as i am aware, die CONFIG_FIQ symbol is not pulled by all ARM platforms. Since there are ARM platforms which don't use this symbol but the hardware is fully capable of handling FIQ requests i would expect, that adding CONFIG_FIQ to a plattform, that this platform honors the set_fiq_handler functionality. > You can't have fast and immediate servicing of the event _and_ debug usage > at the same time. > > > Well i am not against these features as they assumably improve the > > backtrace, but it would be nice to have a config option which switches > > between set_fiq_handler usage and the other conflicting usages of the > > fiq. > You have a config option already. CONFIG_FIQ. Yes, but if the FIQ handler is also used for IPI, set_fiq_handler gets IPI interrupts (with the patch starting this thread)? So i think that the patch needs to look like: set_fiq_handler ? Best regards Tim --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -483,6 +483,9 @@ asmlinkage void __exception_irq_entry handle_fiq_as_nmi(struct pt_regs *regs) +#ifndef CONFIG_FIQ #ifdef CONFIG_ARM_GIC gic_handle_fiq_ipi(); #endif +#endif As otherwise if the platform has CONFIG_SMP and CONFIG_FIQ and CONFIG_ARM_GIC the GIC will get reprogrammed to deliver FIQ's to the handler set by