From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9E1A0371D16 for ; Sat, 9 May 2026 11:55:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778327733; cv=none; b=k1AqOiMFabuuOXoCYJYT9s4BlZF/AdCxHtGbisTUV+iW0KQghOXtzKTyA0A52g+lMDUg6B+z79te3xZP7hToZ+C/RPjphYQExQbSbxQBFsdIZ33Kg8Rjqyb7i8vwTfa6VVsqqmC3BQqCrJJNJAqB2Bo1J9sJNb+wBIq/8hIJTQE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778327733; c=relaxed/simple; bh=JKDorVrqgPYt76T47+Dr9mhHeScyJUMoQtzohtWxRgk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bWNlXwc6QvZXEGEIxD52u2TY+b8u6YMPdMA07+UkqHzUUf5sqqAB7Xhsivt6+hXqT26RNLxQ+Za6b+IA3LvDwIXb2hdl7ilF82mjaLaJtkAFbnUw7lb0yk9AsECP4rdp3DcAz0+URD402HmNfK36srno12nOiSuA5PwoS0/bhvg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=FPFd+mrF; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="FPFd+mrF" 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 138C52454; Sat, 9 May 2026 04:55:18 -0700 (PDT) Received: from e129823.arm.com (e129823.arm.com [10.1.197.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E45B43F763; Sat, 9 May 2026 04:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778327723; bh=JKDorVrqgPYt76T47+Dr9mhHeScyJUMoQtzohtWxRgk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FPFd+mrFRP4jVNf/a5pNTb1XKaHS0bbRi/TOMaBCm104UhyBCwXaIwFWbly7xv5JR CK589ANcjMbiPIGL9hxz9MB8PFHWQ6R7CT/51Qln5M7VlekA8/vr8lZuIStmIlmO03 GOLiG7YaPimdJPyRG2Ucrae8QDpYQlWZ21TTrCgs= Date: Sat, 9 May 2026 12:55:19 +0100 From: Yeoreum Yun To: Leo Yan Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, mike.leach@arm.com, james.clark@linaro.org, alexander.shishkin@linux.intel.com, jie.gan@oss.qualcomm.com Subject: Re: [PATCH v6 04/13] coresight: etm4x: exclude ss_status from drvdata->config Message-ID: References: <20260422132203.977549-1-yeoreum.yun@arm.com> <20260422132203.977549-5-yeoreum.yun@arm.com> <20260508152742.GI3778514@e132581.arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260508152742.GI3778514@e132581.arm.com> Hi Leo, > On Wed, Apr 22, 2026 at 02:21:54PM +0100, Yeoreum Yun wrote: > > [...] > > > @@ -573,11 +573,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > > etm4x_relaxed_write32(csa, config->res_ctrl[i], TRCRSCTLRn(i)); > > > > for (i = 0; i < caps->nr_ss_cmp; i++) { > > - /* always clear status bit on restart if using single-shot */ > > - if (config->ss_ctrl[i] || config->ss_pe_cmp[i]) > > - config->ss_status[i] &= ~TRCSSCSRn_STATUS; > > etm4x_relaxed_write32(csa, config->ss_ctrl[i], TRCSSCCRn(i)); > > - etm4x_relaxed_write32(csa, config->ss_status[i], TRCSSCSRn(i)); > > + /* always clear status and pending bits on restart if using single-shot */ > > + etm4x_relaxed_write32(csa, 0x0, TRCSSCSRn(i)); > > After confirmed with hardware team, we should preserve status bits > (including STATUS and PENDING bits) during a session. So here we should > set drvdata->ss_status to TRCSSCSRn. > > > @@ -1503,8 +1501,9 @@ static void etm4_init_arch_data(void *info) > > */ > > caps->nr_ss_cmp = FIELD_GET(TRCIDR4_NUMSSCC_MASK, etmidr4); > > for (i = 0; i < caps->nr_ss_cmp; i++) { > > - drvdata->config.ss_status[i] = > > - etm4x_relaxed_read32(csa, TRCSSCSRn(i)); > > + drvdata->ss_status[i] = etm4x_relaxed_read32(csa, TRCSSCSRn(i)); > > + drvdata->ss_status[i] &= (TRCSSCSRn_PC | TRCSSCSRn_DV | > > + TRCSSCSRn_DA | TRCSSCSRn_INST); > > It is fine for read these capacity bits when probe, but we need to clear > status when a session is starting to avoid the stale value left from > previous session: > > drvdata->ss_status[idx] &= ~(TRCSSCSRn_STATUS | TRCSSCSRn_PENDING); > > We can do this in etm4_parse_event_config() for perf mode, and might > create a new function (say etm4_parse_sysfs_config()) for preparing > config for sysfs mode? > As we discussed in offline, those bits should be cleared at the begining of the session. so clearing drvdata->ss_status at start of session in each mode is fine for me and for future integration for cpu suspend/resume. But, I want to clarify that the perf is one of exceptional case since the "etm4_parse_event_config()" is called at the "resume" of session for per-thread mode event. TBH, We don't have some specific usage how STATUS or PENDING bit could be used with perf session and until now those bits are always cleared at the time of "sched-in" though we need to keep those bits theoretically. Anyway as we discussed, since now there have been no issue relavant for those bits, let the clear drvdata->ss_status at the etm4_parse_event_config() or when setting a active config for start/resume in this patchset and let me fix this with another patchset. -- Sincerely, Yeoreum Yun