From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C48C7C07E99 for ; Mon, 12 Jul 2021 11:19:08 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 96E2761003 for ; Mon, 12 Jul 2021 11:19:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96E2761003 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=iVtnCOUwQa6Kf9M7inCGGaK2fuQ5BFpcH2tgfxKE5m8=; b=lvVctk1KXUfBBZKPDdLBLw+R2P 1g1u+ojWi/ZeJMNtu5JCsZZ0L2z4VfdZ4vh72dFn0UkZworkCW4yrjDsLFts+Cpz+l4VfQ4fzAo0F S+goFuDbGrGFwK9XGrzjym3HWAG9Vw92Q4pYLjOSagX16rChSXLJCb4O12JsgAmQ0HtPvfoJ/VAMd 1elNkaUCGofXvWS80i37VlETXZTP22YrIsOHW12J00uGcg416BfVXP+bys69t8aKvTZXEZy5jlPN1 9fxKW3pUU2+FBU5xCVDt+lrBVLqvzgiTrt/HeRGGCXQt57CqbyqGVHgXQDMLIiXxQ7zZE3IVGJKGh 1P7aEHtg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m2tw4-0077Dg-RJ; Mon, 12 Jul 2021 11:17:16 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m2tw0-0077Cl-Hh for linux-arm-kernel@lists.infradead.org; Mon, 12 Jul 2021 11:17:14 +0000 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 90A336D; Mon, 12 Jul 2021 04:17:07 -0700 (PDT) Received: from [10.57.35.32] (unknown [10.57.35.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6DFE53F694; Mon, 12 Jul 2021 04:17:06 -0700 (PDT) Subject: Re: [PATCH v2] coresight: tmc-etr: Speed up for bounce buffer in flat mode To: Leo Yan Cc: Mathieu Poirier , Mike Leach , Alexander Shishkin , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20210710070115.462674-1-leo.yan@linaro.org> <20210712110916.GB704210@leoy-ThinkPad-X240s> From: Suzuki K Poulose Message-ID: <5f3148bf-3efa-5866-b426-8bab4eb40282@arm.com> Date: Mon, 12 Jul 2021 12:17:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210712110916.GB704210@leoy-ThinkPad-X240s> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210712_041712_684169_1C1DD3EE X-CRM114-Status: GOOD ( 23.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 12/07/2021 12:09, Leo Yan wrote: > Hi Suzuki, > > On Mon, Jul 12, 2021 at 10:55:32AM +0100, Suzuki Kuruppassery Poulose wrote: > > [...] > >>> static void tmc_etr_sync_flat_buf(struct etr_buf *etr_buf, u64 rrp, u64 rwp) >>> { >>> + struct etr_flat_buf *flat_buf = etr_buf->private; >>> + struct device *real_dev = flat_buf->dev->parent; >>> + >>> /* >>> * Adjust the buffer to point to the beginning of the trace data >>> * and update the available trace data. >>> @@ -648,6 +668,28 @@ static void tmc_etr_sync_flat_buf(struct etr_buf *etr_buf, u64 rrp, u64 rwp) >>> etr_buf->len = etr_buf->size; >>> else >>> etr_buf->len = rwp - rrp; >>> + >>> + if (etr_buf->offset + etr_buf->len > etr_buf->size) { >>> + int len1, len2; >>> + >>> + /* >>> + * If trace data is wrapped around, sync AUX bounce buffer >>> + * for two chunks: "len1" is for the trace date length at >>> + * the tail of bounce buffer, and "len2" is the length from >>> + * the start of the buffer after wrapping around. >>> + */ >>> + len1 = etr_buf->size - etr_buf->offset; >>> + len2 = etr_buf->len - len1; >>> + dma_sync_single_for_cpu(real_dev, >>> + flat_buf->daddr + etr_buf->offset, >>> + len1, DMA_FROM_DEVICE); >>> + dma_sync_single_for_cpu(real_dev, flat_buf->daddr, >>> + len2, DMA_FROM_DEVICE); >> >> We always start tracing at the beginning of the buffer and the only reason >> why we would get a wrap around, is when the buffer is full. >> So you could as well sync the entire buffer in one go >> >> dma_sync_single_for_cpu(real_dev, flat_buf->daddr, >> etr_buf->len, DMA_FROM_DEVICE); > > I am doubt why you conclude "always start tracing at the beginning of > the buffer"? I read the driver but cannot find any code in the driver > to reset rrp and rwp after fetching the trace data, or there have any > implict operation to reset pointers? The ETR is always programmed with the base address of the "ETR" buffer, which is *not the same* as the perf ring buffer, since we always do double buffering. We do not program the RRP/RWP of the ETR (except for the SoC-600, where it is mandatory and we set them to the base address). Thus there is no context associated with the ETR buffer. But at the end of the run, we do read the RRP/ RWP to figure out where the ETR has reached. As for reseting the RRP / RWP, at the beginning of a session, is done implicitly for the ETR (except for SoC-600 ETRs as explained above) by the hardware to the base address. Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel