Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp984004pxk; Fri, 25 Sep 2020 03:10:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+23YlrGIVJ/tw65sQqsUzVQnsy3thR8h/smMM/ncAzVd7VLSQK8F9u36wmp+vcBFX2DOC X-Received: by 2002:a05:6402:1544:: with SMTP id p4mr434835edx.346.1601028647009; Fri, 25 Sep 2020 03:10:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601028647; cv=none; d=google.com; s=arc-20160816; b=XIk7w/jRIAhxpTAzRcb/IvN2E4bxVHw19VvmJj9PlMiu4Hwa7rSLMj+sysuEiYthRV rPoTxe0nLaQjOdgsoQe4rYFl53sXXOcbT671TKNECyJSiEMjVUrvNfculOZHYszWLcz/ ik40QBv8pzPOVT2x4rZT7tbkmgPv2EMlns2oGtOqbGiee96Ek2lumxe+65cdx6L7WsRz L1ixFmvVbJ3heuuBamFRp+6KCySEnPjGl5RKy5qQtpsQxbtUGnfbcjg2NltlPRyevIK0 TrmWtgTM7T5j9NuDYUokACIKQfDsPBNXm6tC5MBvTqDOI5Xr5zYGLUb93sMbym0dlMFo ECwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:message-id; bh=B0VL7XWoKpI70WbS1wpUXneED+VOfXfvU1ETZZsijYY=; b=re44qjJCrjEvnIrHsnggqmbR4z67HLOSXxs7K4sSYJ0Di3M/OLK7nlyb7YDCGMgWZ7 0oYvtQdP/Bo/EZqC7B1tQ7gerbqNxlEWV9qxGmA7osq4HeRstiZO+QlyYyAfP6mRzh/+ OcHKa8Z0InCS4STVvbraDEs8Y5+POyn8M4dZhjvmd27pmrNsa2+VJJDO2XY+A9xZTaHa w0pkx5gureoSZsNb1RL4XeRx+FHAMDXfgdhiT7NcB6bGxFh5qODbc0C7jX+tavcrrog3 c1te4rHvc6Qla8LaHnKMFZTceteqy3dvEdbDkbCO4oxL+eTlTwn19ss4+C9QkKM2Snin WZlg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oy13si1450675ejb.481.2020.09.25.03.10.23; Fri, 25 Sep 2020 03:10:46 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727960AbgIYKIb (ORCPT + 99 others); Fri, 25 Sep 2020 06:08:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727290AbgIYKIb (ORCPT ); Fri, 25 Sep 2020 06:08:31 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EBF95C0613CE for ; Fri, 25 Sep 2020 03:08:30 -0700 (PDT) Received: from [2a0a:edc0:0:900:6245:cbff:fea0:1793] (helo=kresse.office.stw.pengutronix.de) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1kLkeS-0004eN-W7; Fri, 25 Sep 2020 12:08:29 +0200 Message-ID: <9e6560a23a6b02fd9c041983bf2d843de1f7618e.camel@pengutronix.de> From: Lucas Stach To: Christian Gmeiner , linux-kernel@vger.kernel.org Cc: David Airlie , etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Daniel Vetter , Russell King , cphealy@gmail.com Date: Fri, 25 Sep 2020 12:08:27 +0200 In-Reply-To: <20200814090512.151416-4-christian.gmeiner@gmail.com> References: <20200814090512.151416-1-christian.gmeiner@gmail.com> <20200814090512.151416-4-christian.gmeiner@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:6245:cbff:fea0:1793 X-SA-Exim-Mail-From: l.stach@pengutronix.de X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.ext.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-1.1 required=4.0 tests=AWL,BAYES_00,RDNS_NONE, SPF_HELO_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Subject: Re: [PATCH 3/4] drm/etnaviv: add total hi bandwidth perfcounter X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on metis.ext.pengutronix.de) X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote: > These two perf counters represent the total read and write > GPU bandwidth in terms of 64bits. > > The used sequence was taken from Vivante kernel driver. > > Signed-off-by: Christian Gmeiner > --- > drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 35 ++++++++++++++++++++++- > 1 file changed, 34 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > index 782732e6ce72..b37459f022d7 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > @@ -69,6 +69,29 @@ static u32 pipe_perf_reg_read(struct etnaviv_gpu *gpu, > return value; > } > > +static u32 pipe_reg_read(struct etnaviv_gpu *gpu, > + const struct etnaviv_pm_domain *domain, > + const struct etnaviv_pm_signal *signal) > +{ > + u32 clock = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL); > + u32 value = 0; > + unsigned i; > + > + for (i = 0; i < gpu->identity.pixel_pipes; i++) { > + clock &= ~(VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE__MASK); > + clock |= VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE(i); > + gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, clock); > + value += gpu_read(gpu, signal->data); > + } > + > + /* switch back to pixel pipe 0 to prevent GPU hang */ > + clock &= ~(VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE__MASK); > + clock |= VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE(0); > + gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, clock); > + > + return value; > +} > + > static u32 hi_total_cycle_read(struct etnaviv_gpu *gpu, > const struct etnaviv_pm_domain *domain, > const struct etnaviv_pm_signal *signal) > @@ -102,8 +125,18 @@ static const struct etnaviv_pm_domain doms_3d[] = { > .name = "HI", > .profile_read = VIVS_MC_PROFILE_HI_READ, > .profile_config = VIVS_MC_PROFILE_CONFIG2, > - .nr_signals = 5, > + .nr_signals = 7, I've tripped across this part. It's something I don't particularly like, as this value has a risk of getting inconsistent with the actual array. Maybe we could split out signal array from this initialization, so we could then use the ARRAY_SIZE macro to initialize this value? But that's not really related to this patch and can be done in a follow-up cleanup. Regards, Lucas > .signal = (const struct etnaviv_pm_signal[]) { > + { > + "TOTAL_READ_BYTES8", > + VIVS_HI_PROFILE_READ_BYTES8, > + &pipe_reg_read, > + }, > + { > + "TOTAL_WRITE_BYTES8", > + VIVS_HI_PROFILE_WRITE_BYTES8, > + &pipe_reg_read, > + }, > { > "TOTAL_CYCLES", > 0,