Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755266AbcDDLxh (ORCPT ); Mon, 4 Apr 2016 07:53:37 -0400 Received: from mail-lb0-f196.google.com ([209.85.217.196]:33061 "EHLO mail-lb0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752378AbcDDLxf (ORCPT ); Mon, 4 Apr 2016 07:53:35 -0400 Date: Mon, 4 Apr 2016 13:53:30 +0200 From: Rabin Vincent To: Marc Zyngier Cc: Rabin Vincent , daniel.lezcano@linaro.org, tglx@linutronix.de, srinivas.kandagatla@gmail.com, linux-kernel@vger.kernel.org, patrice.chotard@st.com, linux-arm-kernel@lists.infradead.org, maxime.coquelin@st.com Subject: Re: [PATCH] clockevents/drivers/arm_global_timer: Fix erratum 740657 workaround Message-ID: <20160404115330.GB27198@lnxrabinv.se.axis.com> References: <1459238917-2240-1-git-send-email-rabin.vincent@axis.com> <56FAA991.1080401@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FAA991.1080401@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1277 Lines: 27 On Tue, Mar 29, 2016 at 05:13:05PM +0100, Marc Zyngier wrote: > - What if my timer is not connected to a controller that implements this > API? Something that is not a GIC, for example? As you know irq_set_irqchip_state() does nothing in that case, and the erratum is thus presumably not worked around in such a system. By the way, while the original document from ARM is not public, this erratum can be seen here (among other places): http://www.nxp.com/files/32bit/doc/errata/IMX6DQCE.pdf#page=13 https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/es/es-01042.pdf#page=26 > - How does it work when the GIC (with EOImode==1) performs a priority > drop (by writing to the EOI register) before calling into the timer > handler, and finishing the handling with a write to DIR? I guess it doesn't. > - What are the comparative costs of taking a spurious (but nonetheless > harmless) interrupt vs poking the distributor (which is by no mean a > cheap operation)? The time taken by irq_set_irqchip_state() appears to be about 15% shorter than the time gic_handle_irq() and its called functions take to handle the spurious interrrupt. The overhead of going in and out of interrupt context for the spurious interrupt is not included in the latter time.