From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
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
Subject: Re: [PATCH v2 06/10] coresight: trbe: Fix handling of spurious interrupts
Date: Fri, 30 Jul 2021 13:57:47 +0100 [thread overview]
Message-ID: <5b7cd17f-77e0-0a8e-29f4-3eda082c5a67@arm.com> (raw)
In-Reply-To: <5a8f30f2-188c-427f-98e5-5c1ec5ad0626@arm.com>
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 <anshuman.khandual@arm.com>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Cc: Mike Leach <mike.leach@linaro.org>
>> Cc: Leo Yan <leo.yan@linaro.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> 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
next prev parent reply other threads:[~2021-07-30 12:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-23 12:46 [PATCH v2 00/10] coresight: TRBE and Self-Hosted trace fixes Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 01/10] coresight: etm4x: Save restore TRFCR_EL1 Suzuki K Poulose
2021-07-30 3:05 ` Anshuman Khandual
2021-07-23 12:46 ` [PATCH v2 02/10] coresight: etm4x: Use Trace Filtering controls dynamically Suzuki K Poulose
2021-07-30 3:48 ` Anshuman Khandual
2021-07-30 11:29 ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 03/10] coresight: etm-pmu: Ensure the AUX handle is valid Suzuki K Poulose
2021-07-30 4:14 ` Anshuman Khandual
2021-07-23 12:46 ` [PATCH v2 04/10] coresight: trbe: Ensure the format flag is set on truncation Suzuki K Poulose
2021-07-30 4:26 ` Anshuman Khandual
2021-07-30 11:37 ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 05/10] coresight: trbe: Drop duplicate TRUNCATE flags Suzuki K Poulose
2021-07-30 4:47 ` Anshuman Khandual
2021-07-30 12:58 ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 06/10] coresight: trbe: Fix handling of spurious interrupts Suzuki K Poulose
2021-07-30 5:15 ` Anshuman Khandual
2021-07-30 12:57 ` Suzuki K Poulose [this message]
2021-07-23 12:46 ` [PATCH v2 07/10] coresight: trbe: Do not truncate buffer on IRQ Suzuki K Poulose
2021-07-26 12:34 ` Mike Leach
2021-07-26 16:01 ` Suzuki K Poulose
2021-07-27 10:46 ` Mike Leach
2021-07-27 13:06 ` Suzuki K Poulose
2021-07-28 9:25 ` Suzuki K Poulose
2021-07-23 12:46 ` [PATCH v2 08/10] coresight: trbe: Unify the enabling sequence Suzuki K Poulose
2021-07-30 5:40 ` Anshuman Khandual
2021-07-23 12:46 ` [PATCH v2 09/10] coresight: trbe: End the AUX handle on truncation Suzuki K Poulose
2021-07-30 5:54 ` Anshuman Khandual
2021-07-23 12:46 ` [PATCH v2 10/10] coresight: trbe: Prohibit trace before disabling TRBE Suzuki K Poulose
2021-07-30 6:58 ` Anshuman Khandual
2021-07-23 13:45 ` [PATCH v2 00/10] coresight: TRBE and Self-Hosted trace fixes Suzuki K Poulose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b7cd17f-77e0-0a8e-29f4-3eda082c5a67@arm.com \
--to=suzuki.poulose@arm.com \
--cc=al.grant@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=coresight@lists.linaro.org \
--cc=jinlmao@qti.qualcomm.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=tamas.zsoldos@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).