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 96AB42D6604; Fri, 14 Nov 2025 18:05:06 +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=1763143509; cv=none; b=MxZFdCb2Tb/3Fh/CHsoVdf2oeQ+7nUuKXLy0433SFhm1zm67IeJzIVovxHSlNr0G0parJok7sMAOrXUFlDGA0Mx0ig6kzEIKWYYr2KNnjrtiHz1l6hMYG2aVzq9fnSa16ZNKUzgQLWpzc7oMnJJ36Bx93o0CJqdOLR/soKCcsKY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763143509; c=relaxed/simple; bh=9Y7OxeCPQmSSSSiz3iY2a27ZhcrUFikrFKfb3aNbb68=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UfYDFVHp7FKtc7NerzNKt/n9VMp2p7SgiemZU7iPRrUrJlby6nCsgujcUVHRzF5jdkteQiY8szy1uV538LVkM4Ydmkh9dJubwk58DVAmBGnmNHLVd9c070LBi8GsYFnfmouInVZOTE9EAT677ncgflN46LP7FwDHmdgDpbi/ZoQ= 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; 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 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 5291A1063; Fri, 14 Nov 2025 10:04:58 -0800 (PST) Received: from localhost (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8D3E43F5A1; Fri, 14 Nov 2025 10:05:05 -0800 (PST) Date: Fri, 14 Nov 2025 18:05:03 +0000 From: Leo Yan To: James Clark Cc: Suzuki K Poulose , Mike Leach , Alexander Shishkin , Jonathan Corbet , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v4 13/13] coresight: docs: Document etm4x timestamp interval option Message-ID: <20251114180503.GM3568724@e132581.arm.com> References: <20251112-james-cs-syncfreq-v4-0-165ba21401dc@linaro.org> <20251112-james-cs-syncfreq-v4-13-165ba21401dc@linaro.org> Precedence: bulk X-Mailing-List: linux-doc@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: <20251112-james-cs-syncfreq-v4-13-165ba21401dc@linaro.org> On Wed, Nov 12, 2025 at 03:22:19PM +0000, James Clark wrote: > Document how the new field is used, maximum value and the interaction > with SYNC timestamps. > > Signed-off-by: James Clark > --- > Documentation/trace/coresight/coresight.rst | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst > index 806699871b80..80b5ed09d69b 100644 > --- a/Documentation/trace/coresight/coresight.rst > +++ b/Documentation/trace/coresight/coresight.rst > @@ -613,8 +613,19 @@ They are also listed in the folder /sys/bus/event_source/devices/cs_etm/format/ > - Session local version of the system wide setting: :ref:`ETM_MODE_RETURNSTACK > ` > * - timestamp > - - Session local version of the system wide setting: :ref:`ETMv4_MODE_TIMESTAMP > - ` > + - Controls generation and interval of timestamps. > + > + 0 = off, 1 = maximum interval .. 15 = minimum interval. I am struggling to understand the "maximum" and "minimum" usage here. Seems to me, you are saying: 1 = maximum frequency .. 15 = minimum frequency > + > + Values 1 - 14 use a counter that decrements every cycle to generate a > + timestamp on underflow. The reload value for the counter is 2 raised to > + the power of timestamp interval - 1. If the value is 1 then the reload > + value is 1, if the value is 11 then the reload value is 1024 etc. I saw your replying to Randy, yeah, the formula would be much clear. > + > + Setting the minimum interval (15) will disable the counter generated > + timestamps, freeing the counter resource, leaving only ones emitted when > + a SYNC packet is generated for every 4096 bytes of trace. "every 4096 bytes" is not always true. Isn't this defined in TRCSYNCPR.PERIOD? Maybe just say "... for every period of trace defined in TRCSYNCPR.PERIOD", or even more general "... for every period of trace". Thanks, Leo > + > * - cc_threshold > - Cycle count threshold value. If nothing is provided here or the provided value is 0, then the > default value i.e 0x100 will be used. If provided value is less than minimum cycles threshold > > -- > 2.34.1 >