From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44358C4338F for ; Fri, 30 Jul 2021 12:57:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2251360F94 for ; Fri, 30 Jul 2021 12:57:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238806AbhG3M54 (ORCPT ); Fri, 30 Jul 2021 08:57:56 -0400 Received: from foss.arm.com ([217.140.110.172]:41734 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230328AbhG3M5z (ORCPT ); Fri, 30 Jul 2021 08:57:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B110F6D; Fri, 30 Jul 2021 05:57:50 -0700 (PDT) Received: from [10.57.86.111] (unknown [10.57.86.111]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B80E3F70D; Fri, 30 Jul 2021 05:57:49 -0700 (PDT) Subject: Re: [PATCH v2 06/10] coresight: trbe: Fix handling of spurious interrupts To: Anshuman Khandual , coresight@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, tamas.zsoldos@arm.com, al.grant@arm.com, leo.yan@linaro.org, mike.leach@linaro.org, mathieu.poirier@linaro.org, jinlmao@qti.qualcomm.com References: <20210723124611.3828908-1-suzuki.poulose@arm.com> <20210723124611.3828908-7-suzuki.poulose@arm.com> <5a8f30f2-188c-427f-98e5-5c1ec5ad0626@arm.com> From: Suzuki K Poulose Message-ID: <5b7cd17f-77e0-0a8e-29f4-3eda082c5a67@arm.com> Date: Fri, 30 Jul 2021 13:57:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <5a8f30f2-188c-427f-98e5-5c1ec5ad0626@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/07/2021 06:15, Anshuman Khandual wrote: > > > On 7/23/21 6:16 PM, Suzuki K Poulose wrote: >> On a spurious IRQ, right now we disable the TRBE and then re-enable >> it back, resetting the "buffer" pointers(i.e BASE, LIMIT and more >> importantly WRITE) to the original pointers from the AUX handle. >> This implies that we overwrite any trace that was written so far, >> (by overwriting TRBPTR) while we should have ignored the IRQ. > > The ideas was that a state (pointers) reset would improve the chances > of not getting the spurious IRQ once again. This is assuming that some > thing during this current state machine, had caused the spurious IRQ. > Hence just restart it back from the beginning. Yes, it does lose some > trace data but whats the real possibility of such spurious IRQs in the > first place ? > >> >> This patch cleans the behavior, by only stopping the TRBE if the >> IRQ was indeed raised, as we can read the TRBSR without stopping >> the TRBE (Only writes to the TRBSR requires the TRBE disabled). >> And also, on detecting a spurious IRQ after examining the TRBSR, >> we simply re-enable the TRBE without touching the other parameters. > > This makes sense. I was not sure if TRBSR could be safely read without > actually stopping the TRBE. > >> >> Cc: Anshuman Khandual >> Cc: Mathieu Poirier >> Cc: Mike Leach >> Cc: Leo Yan >> Signed-off-by: Suzuki K Poulose >> --- >> drivers/hwtracing/coresight/coresight-trbe.c | 29 ++++++++++---------- >> 1 file changed, 15 insertions(+), 14 deletions(-) >> >> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c >> index 62e1a08f73ff..503bea0137ae 100644 >> --- a/drivers/hwtracing/coresight/coresight-trbe.c >> +++ b/drivers/hwtracing/coresight/coresight-trbe.c >> @@ -679,15 +679,16 @@ static int arm_trbe_disable(struct coresight_device *csdev) >> >> static void trbe_handle_spurious(struct perf_output_handle *handle) >> { >> - struct trbe_buf *buf = etm_perf_sink_config(handle); >> + u64 limitr = read_sysreg_s(SYS_TRBLIMITR_EL1); >> >> - buf->trbe_limit = compute_trbe_buffer_limit(handle); >> - buf->trbe_write = buf->trbe_base + PERF_IDX2OFF(handle->head, buf); >> - if (buf->trbe_limit == buf->trbe_base) { >> - trbe_drain_and_disable_local(); >> - return; >> - } >> - trbe_enable_hw(buf); >> + /* >> + * If the IRQ was spurious, simply re-enable the TRBE >> + * back without modifiying the buffer parameters to > > Typo here ^^^^^^ s/modifiying/modifying > >> + * retain the trace collected so far. >> + */ >> + limitr |= TRBLIMITR_ENABLE; >> + write_sysreg_s(limitr, SYS_TRBLIMITR_EL1); >> + isb(); >> } >> >> static void trbe_handle_overflow(struct perf_output_handle *handle) >> @@ -760,12 +761,7 @@ static irqreturn_t arm_trbe_irq_handler(int irq, void *dev) >> enum trbe_fault_action act; >> u64 status; >> >> - /* >> - * Ensure the trace is visible to the CPUs and >> - * any external aborts have been resolved. >> - */ >> - trbe_drain_and_disable_local(); >> - >> + /* Reads to TRBSR_EL1 is fine when TRBE is active */ >> status = read_sysreg_s(SYS_TRBSR_EL1); >> /* >> * If the pending IRQ was handled by update_buffer callback >> @@ -774,6 +770,11 @@ static irqreturn_t arm_trbe_irq_handler(int irq, void *dev) >> if (!is_trbe_irq(status)) > > Warn here that a non-related IRQ has been delivered to this handler ? > But moving the trbe_drain_and_disable_local() later, enables it to > return back immediately after detecting an unrelated IRQ. Not really. There could be race with the update_buffer(), see the comment right above that. When that happens, we have disabled the TRBE in the update_buffer(). Either case, we have nothing to do. > >> return IRQ_NONE; >> >> + /* >> + * Ensure the trace is visible to the CPUs and >> + * any external aborts have been resolved. >> + */ >> + trbe_drain_and_disable_local(); >> clr_trbe_irq(); >> isb(); >> >> > > Actually there are two types of spurious interrupts here. > > 1. Non-TRBE spurious interrupt > > Fails is_trbe_irq() test and needs to be returned immediately from > arm_trbe_irq_handler(), after an warning for the platform IRQ > delivery wiring. Not necessarily warrant a WARNING. See above. > > 2. TRBE spurious interrupt > > Clears is_trbe_irq() and get handled in trbe_handle_spurious(). I > still think leaving this unchanged might be better as it reduces > the chance of getting further spurious TRBE interrupts. How does it reduce the chances of getting another spurious interrupt ? If the TRBE gets a spurious IRQ, that we cannot decode, I would rather leave it as NOP. Suzuki From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C012C4338F for ; Fri, 30 Jul 2021 12:59:42 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4A4D860F46 for ; Fri, 30 Jul 2021 12:59:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4A4D860F46 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8Sk8G+BCrfzhQocu51BDx7UD+HONvcimQUNEKDtYWfI=; b=hWY0GfW8JGTjGBbhcN3AtWbX/G v60US+4PBWWNTI1ORKGpyhDBuGkbUAVr/X3EYC7UpRFOtjRYPcpr2rrSfhOWcf2gUZOSwx2klCMA0 UiypeAvH8HcW+aaLPP4M1rPh6mAeHa8EAEq1T4gQKfYSdbiKBZq9TdVH96WshN6Sh4VK0KQemS9ug Xr5hZV6acVeKQ7K69xmFqI/cvgL9H2GJOnTFk4wHyGAPoIUWzqwk1fHt513s6bBlXhJVTcCHkSZrS IZAiTHMI/Mpjn6M6NZhJhOTL54VgcDAUksZ8PO9QFtr7K+/cGBXfV6JbGipiYJn9In12RknAT1wf+ hFDQWvWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9S5M-008g8D-DR; Fri, 30 Jul 2021 12:57:56 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9S5I-008g5y-6L for linux-arm-kernel@lists.infradead.org; Fri, 30 Jul 2021 12:57:53 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B110F6D; Fri, 30 Jul 2021 05:57:50 -0700 (PDT) Received: from [10.57.86.111] (unknown [10.57.86.111]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B80E3F70D; Fri, 30 Jul 2021 05:57:49 -0700 (PDT) Subject: Re: [PATCH v2 06/10] coresight: trbe: Fix handling of spurious interrupts To: Anshuman Khandual , coresight@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, tamas.zsoldos@arm.com, al.grant@arm.com, leo.yan@linaro.org, mike.leach@linaro.org, mathieu.poirier@linaro.org, jinlmao@qti.qualcomm.com References: <20210723124611.3828908-1-suzuki.poulose@arm.com> <20210723124611.3828908-7-suzuki.poulose@arm.com> <5a8f30f2-188c-427f-98e5-5c1ec5ad0626@arm.com> From: Suzuki K Poulose Message-ID: <5b7cd17f-77e0-0a8e-29f4-3eda082c5a67@arm.com> Date: Fri, 30 Jul 2021 13:57:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <5a8f30f2-188c-427f-98e5-5c1ec5ad0626@arm.com> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210730_055752_388147_C5379B9E X-CRM114-Status: GOOD ( 33.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 30/07/2021 06:15, Anshuman Khandual wrote: > > > On 7/23/21 6:16 PM, Suzuki K Poulose wrote: >> On a spurious IRQ, right now we disable the TRBE and then re-enable >> it back, resetting the "buffer" pointers(i.e BASE, LIMIT and more >> importantly WRITE) to the original pointers from the AUX handle. >> This implies that we overwrite any trace that was written so far, >> (by overwriting TRBPTR) while we should have ignored the IRQ. > > The ideas was that a state (pointers) reset would improve the chances > of not getting the spurious IRQ once again. This is assuming that some > thing during this current state machine, had caused the spurious IRQ. > Hence just restart it back from the beginning. Yes, it does lose some > trace data but whats the real possibility of such spurious IRQs in the > first place ? > >> >> This patch cleans the behavior, by only stopping the TRBE if the >> IRQ was indeed raised, as we can read the TRBSR without stopping >> the TRBE (Only writes to the TRBSR requires the TRBE disabled). >> And also, on detecting a spurious IRQ after examining the TRBSR, >> we simply re-enable the TRBE without touching the other parameters. > > This makes sense. I was not sure if TRBSR could be safely read without > actually stopping the TRBE. > >> >> Cc: Anshuman Khandual >> Cc: Mathieu Poirier >> Cc: Mike Leach >> Cc: Leo Yan >> Signed-off-by: Suzuki K Poulose >> --- >> drivers/hwtracing/coresight/coresight-trbe.c | 29 ++++++++++---------- >> 1 file changed, 15 insertions(+), 14 deletions(-) >> >> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c >> index 62e1a08f73ff..503bea0137ae 100644 >> --- a/drivers/hwtracing/coresight/coresight-trbe.c >> +++ b/drivers/hwtracing/coresight/coresight-trbe.c >> @@ -679,15 +679,16 @@ static int arm_trbe_disable(struct coresight_device *csdev) >> >> static void trbe_handle_spurious(struct perf_output_handle *handle) >> { >> - struct trbe_buf *buf = etm_perf_sink_config(handle); >> + u64 limitr = read_sysreg_s(SYS_TRBLIMITR_EL1); >> >> - buf->trbe_limit = compute_trbe_buffer_limit(handle); >> - buf->trbe_write = buf->trbe_base + PERF_IDX2OFF(handle->head, buf); >> - if (buf->trbe_limit == buf->trbe_base) { >> - trbe_drain_and_disable_local(); >> - return; >> - } >> - trbe_enable_hw(buf); >> + /* >> + * If the IRQ was spurious, simply re-enable the TRBE >> + * back without modifiying the buffer parameters to > > Typo here ^^^^^^ s/modifiying/modifying > >> + * retain the trace collected so far. >> + */ >> + limitr |= TRBLIMITR_ENABLE; >> + write_sysreg_s(limitr, SYS_TRBLIMITR_EL1); >> + isb(); >> } >> >> static void trbe_handle_overflow(struct perf_output_handle *handle) >> @@ -760,12 +761,7 @@ static irqreturn_t arm_trbe_irq_handler(int irq, void *dev) >> enum trbe_fault_action act; >> u64 status; >> >> - /* >> - * Ensure the trace is visible to the CPUs and >> - * any external aborts have been resolved. >> - */ >> - trbe_drain_and_disable_local(); >> - >> + /* Reads to TRBSR_EL1 is fine when TRBE is active */ >> status = read_sysreg_s(SYS_TRBSR_EL1); >> /* >> * If the pending IRQ was handled by update_buffer callback >> @@ -774,6 +770,11 @@ static irqreturn_t arm_trbe_irq_handler(int irq, void *dev) >> if (!is_trbe_irq(status)) > > Warn here that a non-related IRQ has been delivered to this handler ? > But moving the trbe_drain_and_disable_local() later, enables it to > return back immediately after detecting an unrelated IRQ. Not really. There could be race with the update_buffer(), see the comment right above that. When that happens, we have disabled the TRBE in the update_buffer(). Either case, we have nothing to do. > >> return IRQ_NONE; >> >> + /* >> + * Ensure the trace is visible to the CPUs and >> + * any external aborts have been resolved. >> + */ >> + trbe_drain_and_disable_local(); >> clr_trbe_irq(); >> isb(); >> >> > > Actually there are two types of spurious interrupts here. > > 1. Non-TRBE spurious interrupt > > Fails is_trbe_irq() test and needs to be returned immediately from > arm_trbe_irq_handler(), after an warning for the platform IRQ > delivery wiring. Not necessarily warrant a WARNING. See above. > > 2. TRBE spurious interrupt > > Clears is_trbe_irq() and get handled in trbe_handle_spurious(). I > still think leaving this unchanged might be better as it reduces > the chance of getting further spurious TRBE interrupts. How does it reduce the chances of getting another spurious interrupt ? If the TRBE gets a spurious IRQ, that we cannot decode, I would rather leave it as NOP. Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel