Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp587984pxb; Wed, 27 Jan 2021 16:00:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJya2v+PRmYLcqb2KZoiWsHj6rH3CTfDTKQ7JnrDW0BYK/kTq2jGXRnCryMIFlDznK5ki/Vw X-Received: by 2002:a05:6402:5206:: with SMTP id s6mr10991041edd.92.1611792001709; Wed, 27 Jan 2021 16:00:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611792001; cv=none; d=google.com; s=arc-20160816; b=R0kaF3s1f8cv/dnAvEy+0ige3+yEKDXf6EeV4IwSS8hIxuFjU2MNBmclRVeFfbrtz7 6zZdb5rt2dpR95xYWoaTD6CKTsLTNmVBw/cr/wQX4APs3ptpElpZaootl9HIiAf9OYv1 ne13ADZbj9/POcoIQTjJv+XgWo/ZYO4k2Y+Jq/ioW6SVHEel36ReIB4FVuTtZZRBsZmy 9bzg21FECy0CrsAZJP/+rtkBQW/lvtGWUT78+pxgZ23RohngHh5PHik3eE++EBHOX3Kg UzaYWzBN7AsT3YCQ5GgqnQKA3d9Jq6SFzuIoNDEl7LPAVfRyRWunySCFE7Q6cpL73kWH USCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=lyHtJgi7Va5tfzAaI5rqL9GriRxNME2Odjiq4+hk6MQ=; b=rLRt3wE7ReLLGbB9RubQxKT97Asm/enc9vu94wbp8ivx5Z6J7q0pRaX0IvxTJxUnIc UNH7mEV8DSxC2yXSPO8WcEiYp5IBUs9gIvq9O3KB4r1DIzzfh/coAImXVjjIgOSut3s7 giXzCRH95LWaeA3WQQzfQj3VG83zLHlgvOPPc4UFKmkRfEPz2QTewma42cKAkJneuAS5 MwFsdfbJ6M/Jy5Bzyq8sPsQDPAPteSRG0OT5hJLRcV21KSlFfYw9LSYoiFkgsd69Vb5q XSMubzLMZ3d4RgMqwKbbLTXClTm9TvxN4o+xliKzH007DYYYVhTtlFwdSHusTC7f3uQC 9fHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dm28si1753264edb.528.2021.01.27.15.59.37; Wed, 27 Jan 2021 16:00:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233757AbhA0OPZ (ORCPT + 99 others); Wed, 27 Jan 2021 09:15:25 -0500 Received: from foss.arm.com ([217.140.110.172]:48390 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232605AbhA0ONN (ORCPT ); Wed, 27 Jan 2021 09:13:13 -0500 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 8BA471FB; Wed, 27 Jan 2021 06:12:23 -0800 (PST) Received: from [10.57.40.145] (unknown [10.57.40.145]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B8C853F68F; Wed, 27 Jan 2021 06:12:21 -0800 (PST) Subject: Re: [PATCH V3 14/14] coresight: etm-perf: Add support for trace buffer format To: Peter Zijlstra , Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, mathieu.poirier@linaro.org, mike.leach@linaro.org, lcherian@marvell.com, linux-kernel@vger.kernel.org, Leo Yan References: <1611737738-1493-1-git-send-email-anshuman.khandual@arm.com> <1611737738-1493-15-git-send-email-anshuman.khandual@arm.com> From: Suzuki K Poulose Message-ID: Date: Wed, 27 Jan 2021 14:12:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: 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 Hi Peter On 1/27/21 12:54 PM, Peter Zijlstra wrote: > On Wed, Jan 27, 2021 at 02:25:38PM +0530, Anshuman Khandual wrote: > >> It is possible to have a >> perf session where some events end up collecting the trace >> in TMC-ETR while the others in TRBE. Thus we need a way >> to identify the type of the trace for each AUX record. > >> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h >> index 9a5ca45..169e6b3 100644 >> --- a/include/uapi/linux/perf_event.h >> +++ b/include/uapi/linux/perf_event.h >> @@ -1111,6 +1111,10 @@ enum perf_callchain_context { >> #define PERF_AUX_FLAG_COLLISION 0x08 /* sample collided with another */ >> #define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK 0xff00 /* PMU specific trace format type */ >> >> +/* CoreSight PMU AUX buffer formats */ >> +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT 0x0000 /* Default for backward compatibility */ >> +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW 0x0100 /* Raw format of the source */ > > Would CORESIGHT_FORMAT_ETR / CORESIGHT_FORMAT_TRBE be better names? > Not really. The format used by the ETR is CORESIGHT frame formatting. And there are other sinks that uses the formatting. e.g, TMC-ETB (a sink with internal memory), TMC-ETF (trace fifo with internal memory). So it is really not tied to ETR. As for TRBE, it simply pumps the data thrown at it to the memory. As such calling it TRBE format would be confusing as the format of the buffer is really Raw trace thrown at it. This can be inferred from the ETM/ETE looking at the ID registers, which the userspace perf already captures in the perf.data. So the decoder perf can look at the perf.data and the AUX records to interpret the buffer correctly. Suzuki