From patchwork Mon Dec 10 08:52:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 153247 Delivered-To: patch@linaro.org Received: by 2002:a2e:299d:0:0:0:0:0 with SMTP id p29-v6csp3327348ljp; Mon, 10 Dec 2018 00:53:40 -0800 (PST) X-Google-Smtp-Source: AFSGD/VmdSmCT6xBPGA63yYcxwJoSfuj5BhTvFDIz45ekkt43Rd9f3YFlXbr0NZQAybbRYzmULgp X-Received: by 2002:a65:6645:: with SMTP id z5mr10239442pgv.351.1544432020144; Mon, 10 Dec 2018 00:53:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544432020; cv=none; d=google.com; s=arc-20160816; b=IBykkPY1lCrd2zpw5AHLotYia9DgzlR+tODYxF+nfEfCTskWYuMbLzgyr0ih8K+zUa GIqwiUgcL6m5JQh8bbnpdsIQLd5B8ZbEoeZsAZBOC6EaxBPQ33OcDRef8EAvPUZH7B1a WB2VBQnq2E03Pdx8rWAC3I7m467ZQzRTGLqxWdkpu/xkBGLSpcVZB5RiAsbzDjWInlcg gqPSbcbVtly559jhxhVmQdbXjPaTX9gZbNFfe+iBcmqy/xCUPjYo4DxYE4pSExXJq5Mt LV0Up9h3nEUmwZcKfQXtPOORHLlD/7NKBrhTCLCtPhd62NZ0lkci9HJsZkcxt0j8WYxM 70ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=WgMRTLtOLhYT8FlarRUnYgdidlPs5flIzaegKvjmyYI=; b=OoSNjkY8T/YmhqEbnjbYtobiIgRi9CZurNM5F8Kh+kN3CZAT88HW3vHO7PndXl+lrJ 2i6ee5J3L8k1qb/09jkg0VWzyJLZSxJLqWAIGqQr5HkjmgbsIkibTvjgz02tiqPvhXM2 Sy6fsKHzP23HdFXCHuplXLK+Pd/t89HvfS557KoQEYuzWzk/bOOBVWdI7Ogpe48+g6lY kAjCUZSges3e3rSWpcDzHUo+km2K+4vMAhdbFyBOCjjAukaSI8Vyg5Ch1Kf+/gJZeSNc E/0ENMxlc+QB8Y5f92PGcNzpT+DXPUTYCvbn+AgvoDtlF7T2ACCwDVH94kPAVVhOSclJ SThQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EiIUh07K; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h5si9082225pgk.249.2018.12.10.00.53.39; Mon, 10 Dec 2018 00:53:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EiIUh07K; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726752AbeLJIxj (ORCPT + 31 others); Mon, 10 Dec 2018 03:53:39 -0500 Received: from mail-wm1-f42.google.com ([209.85.128.42]:38722 "EHLO mail-wm1-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726636AbeLJIxi (ORCPT ); Mon, 10 Dec 2018 03:53:38 -0500 Received: by mail-wm1-f42.google.com with SMTP id m22so10301936wml.3 for ; Mon, 10 Dec 2018 00:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=WgMRTLtOLhYT8FlarRUnYgdidlPs5flIzaegKvjmyYI=; b=EiIUh07KJ15nJAm0JkYmA6j0bfQk4wTHlH9S3w0vtyejd92gNNVA5+lB0Eg1QJSXxS znaz8c/sHTTuS60A565mN+yxnk5kPhiU58zhjcfDiArb+dsolwlfdQ/COw1ppFfum8nb FiwC5dTXlXR6XSd/DmNcLcKosB7fM4xj0KPIM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=WgMRTLtOLhYT8FlarRUnYgdidlPs5flIzaegKvjmyYI=; b=agXg9P1Qop5wu2iZL0odOM7ubneZz/rpRRNOf4axTTNdeoR2EUxKLT+oGgJ1cBCCDk 2ONAjqj7FgvHwWcDDK5J/Hd+GqcYeul2sLx8Fh0UtX8J+NqHwds9cK4fxN0iP9jmGhE7 t/fvJL43+DrNJFtxBYb5mCkY8h5Tq3SHHS47ijPB5e8gWrqXz7mGRL9bIY1wnQxXyX7w JJlRTmayKspznzWk+SDtlkus+nXDm2dF8Ca5j1CAfijqQRBFO98dWGfo8wWITnwKqYkA Pc1MHleRQA+kc8LQPtPYw3MdRueGvESTwqM0EYnifKlG6GQPvwzYdd/f9cFhcWfj/ugR giIg== X-Gm-Message-State: AA+aEWbl2lh2D/U73Lt5TY8k42+J3BlOKdG2PLaRyahTFOhw+eCpvK21 Q6xdruqlGAEalRmtnYenNJOCfg== X-Received: by 2002:a1c:a485:: with SMTP id n127mr10064898wme.15.1544432016030; Mon, 10 Dec 2018 00:53:36 -0800 (PST) Received: from localhost.localdomain ([209.250.228.18]) by smtp.gmail.com with ESMTPSA id m4sm9097351wml.2.2018.12.10.00.53.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Dec 2018 00:53:35 -0800 (PST) From: Leo Yan To: Arnaldo Carvalho de Melo , Mathieu Poirier , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Coresight ML Cc: Leo Yan , Mike Leach , Robert Walker Subject: [PATCH v2 4/6] perf cs-etm: Treat NO_SYNC element as trace discontinuity Date: Mon, 10 Dec 2018 16:52:59 +0800 Message-Id: <1544431981-24144-5-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1544431981-24144-1-git-send-email-leo.yan@linaro.org> References: <1544431981-24144-1-git-send-email-leo.yan@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CoreSight tracer driver might insert barrier packet between different buffers, thus the decoder can spot the boundaries based on the barrier packet; the decoder is possible to hit a barrier packet and emit a NO_SYNC element, then the decoder will find a periodic synchronisation point inside that next trace block that starts trace again but does not have the TRACE_ON element as indicator - usually because this block of trace has wrapped the buffer so we have lost the original point that trace was enabled. In upper case, it results in the trace stream only inserts the OCSD_GEN_TRC_ELEM_NO_SYNC element in the middle of tracing stream, but we don't handle NO_SYNC element properly and at the end users miss to see the info for trace discontinuity. Though OCSD_GEN_TRC_ELEM_NO_SYNC is different from CS_ETM_TRACE_ON when output from the decoder, but both of them indicate the trace data is discontinuous; this patch treats OCSD_GEN_TRC_ELEM_NO_SYNC as trace discontinuity and generates CS_ETM_DISCONTINUITY packet for it, so cs-etm can handle discontinuity for this case, finally it saves the last trace data for previous trace block and restart samples for new block. Credit to Mike Leach and Robert Walker who made me clear for underlying mechanism for NO_SYNC element, Mike also shared with me for detailed explanation for why we can treat NO_SYNC and TRACE_ON elements as the same, so this commit log reused most of his explanation. Cc: Mathieu Poirier Cc: Mike Leach Cc: Robert Walker Signed-off-by: Leo Yan --- tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.7.4 Reviewed-by: Mathieu Poirier diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c index a3994f1..46b67f1 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c @@ -411,6 +411,8 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer( case OCSD_GEN_TRC_ELEM_UNKNOWN: break; case OCSD_GEN_TRC_ELEM_NO_SYNC: + resp = cs_etm_decoder__buffer_discontinuity(decoder, + trace_chan_id); decoder->trace_on = false; break; case OCSD_GEN_TRC_ELEM_TRACE_ON: