Received: by 10.223.164.202 with SMTP id h10csp398214wrb; Wed, 22 Nov 2017 23:35:15 -0800 (PST) X-Google-Smtp-Source: AGs4zMYJjlHZi1bDnB6qTS1EY2PjvMfLbPwB4rMQbWqshbGp+ksxZUXJIujx/pCWWtiQiCdnp3MT X-Received: by 10.99.173.78 with SMTP id y14mr16531677pgo.107.1511422515386; Wed, 22 Nov 2017 23:35:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511422515; cv=none; d=google.com; s=arc-20160816; b=rA704kA389CWYB3+XbHgAgeDK5HEipvXaU4D8KMObJEvhZ5S2yWUt8PKTo5js0EC7o dwYUNSUfwT3ew7+QG+lNJXioae1nI9DzIBhf0O5+qwAtR7eQkUQT6O4vDjafOWatLCly yUaBT5tx49k5M7L9OtpxNoPNWzWwMBfDpJaxWmx/WxywhcdK0L+EtLk5554T/RteSW5q 1t8ajEvEEkSp9mMUdBrP61Tu7z4lozlKD5cadK5S7QpINYHhS6eutWUbxBOuXmUVJJQw Z9lBf6I63p2E310JES0qIY1CxpSpKGW9ngRTJxZvBmqYOGwA2+CmNYcA8COaJIXppKlg QnWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=0noZniIH0m3nXvHDq+JZ3V1Y6VMtCW7+K02DsveRyiQ=; b=jw+/+Wv8SlK9xIFrZFsOtrwAPn8+QL7NbIzpsogq5TzksTJcaEPXPv6BYsA8VogE5d BbFegrppjbJCfpbpW4QJdAqv4I1jrkzaTifgRJvZyFJBUc+vq8huP5zifvEnfF3vYigd 5Y7aiqOqDYEvkue/DE8S5cRNoMahR3TL/rdqYXxLWc5j5aNsGyBqabgbWTFfGyhpzIY5 ap+IO2/ve9QL4215qprpn7Hjzli54/f8rpdKEnBjenbGJgVA4CoRw1D6/xwDKPoOz+nx f+ivQJeN2Mq8lLw4je6Wg+tBGMua5+CWL851jrAgy3EhCl9Un3WyZIiEU27u07W5jNQQ wViA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v13si15368399plo.273.2017.11.22.23.35.03; Wed, 22 Nov 2017 23:35:15 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752034AbdKWHeR (ORCPT + 77 others); Thu, 23 Nov 2017 02:34:17 -0500 Received: from mga11.intel.com ([192.55.52.93]:29913 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750880AbdKWHeQ (ORCPT ); Thu, 23 Nov 2017 02:34:16 -0500 Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Nov 2017 23:34:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,440,1505804400"; d="scan'208";a="4926942" Received: from sakamble-mobl.gar.corp.intel.com (HELO [10.223.178.30]) ([10.223.178.30]) by FMSMGA003.fm.intel.com with ESMTP; 22 Nov 2017 23:34:13 -0800 Subject: Creating cyclecounter and lock member in timecounter structure [ Was Re: [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time] To: John Stultz , Thomas Gleixner , Stephen Boyd Cc: Chris Wilson , linux-kernel@vger.kernel.org, Sagar A Kamble References: <1510748034-14034-1-git-send-email-sagar.a.kamble@intel.com> <1510748034-14034-2-git-send-email-sagar.a.kamble@intel.com> <151074872901.26264.3145709294590477412@mail.alporthouse.com> From: Sagar Arun Kamble Message-ID: Date: Thu, 23 Nov 2017 13:04:13 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <151074872901.26264.3145709294590477412@mail.alporthouse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, We needed inputs on possible optimization that can be done to timecounter/cyclecounter structures/usage. This mail is in response to review of patch https://patchwork.freedesktop.org/patch/188448/. As Chris's observation below, about dozen of timecounter users in the kernel have below structures defined individually: spinlock_t lock; struct cyclecounter cc; struct timecounter tc; Can we move lock and cc to tc? That way it will be convenient. Also it will allow unifying the locking/overflow watchdog handling across all drivers. Please suggest. Thanks Sagar On 11/15/2017 5:55 PM, Chris Wilson wrote: > Quoting Sagar Arun Kamble (2017-11-15 12:13:51) >> #include >> #include >> @@ -2149,6 +2150,14 @@ struct i915_perf_stream { >> * @oa_config: The OA configuration used by the stream. >> */ >> struct i915_oa_config *oa_config; >> + >> + /** >> + * System time correlation variables. >> + */ >> + struct cyclecounter cc; >> + spinlock_t systime_lock; >> + struct timespec64 start_systime; >> + struct timecounter tc; > This pattern is repeated a lot by struct timecounter users. (I'm still > trying to understand why the common case is not catered for by a > convenience timecounter api.) > >> }; >> >> /** >> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c >> index 00be015..72ddc34 100644 >> --- a/drivers/gpu/drm/i915/i915_perf.c >> +++ b/drivers/gpu/drm/i915/i915_perf.c >> @@ -192,6 +192,7 @@ >> */ >> >> #include >> +#include >> #include >> #include >> >> @@ -2391,6 +2392,56 @@ static unsigned int i915_perf_poll(struct file *file, poll_table *wait) >> } >> >> /** >> + * i915_cyclecounter_read - read raw cycle/timestamp counter >> + * @cc: cyclecounter structure >> + */ >> +static u64 i915_cyclecounter_read(const struct cyclecounter *cc) >> +{ >> + struct i915_perf_stream *stream = container_of(cc, typeof(*stream), cc); >> + struct drm_i915_private *dev_priv = stream->dev_priv; >> + u64 ts_count; >> + >> + intel_runtime_pm_get(dev_priv); >> + ts_count = I915_READ64_2x32(GEN4_TIMESTAMP, >> + GEN7_TIMESTAMP_UDW); >> + intel_runtime_pm_put(dev_priv); >> + >> + return ts_count; >> +} >> + >> +static void i915_perf_init_cyclecounter(struct i915_perf_stream *stream) >> +{ >> + struct drm_i915_private *dev_priv = stream->dev_priv; >> + int cs_ts_freq = dev_priv->perf.oa.timestamp_frequency; >> + struct cyclecounter *cc = &stream->cc; >> + u32 maxsec; >> + >> + cc->read = i915_cyclecounter_read; >> + cc->mask = CYCLECOUNTER_MASK(CS_TIMESTAMP_WIDTH(dev_priv)); >> + maxsec = cc->mask / cs_ts_freq; >> + >> + clocks_calc_mult_shift(&cc->mult, &cc->shift, cs_ts_freq, >> + NSEC_PER_SEC, maxsec); >> +} >> + >> +static void i915_perf_init_timecounter(struct i915_perf_stream *stream) >> +{ >> +#define SYSTIME_START_OFFSET 350000 /* Counter read takes about 350us */ >> + unsigned long flags; >> + u64 ns; >> + >> + i915_perf_init_cyclecounter(stream); >> + spin_lock_init(&stream->systime_lock); >> + >> + getnstimeofday64(&stream->start_systime); >> + ns = timespec64_to_ns(&stream->start_systime) + SYSTIME_START_OFFSET; > Use ktime directly. Or else Arnd will be back with a patch to fix it. > (All non-ktime interfaces are effectively deprecated; obsolete for > drivers.) > >> + spin_lock_irqsave(&stream->systime_lock, flags); >> + timecounter_init(&stream->tc, &stream->cc, ns); >> + spin_unlock_irqrestore(&stream->systime_lock, flags); >> +} >> + >> +/** >> * i915_perf_enable_locked - handle `I915_PERF_IOCTL_ENABLE` ioctl >> * @stream: A disabled i915 perf stream >> * >> @@ -2408,6 +2459,8 @@ static void i915_perf_enable_locked(struct i915_perf_stream *stream) >> /* Allow stream->ops->enable() to refer to this */ >> stream->enabled = true; >> >> + i915_perf_init_timecounter(stream); >> + >> if (stream->ops->enable) >> stream->ops->enable(stream); >> } >> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h >> index cfdf4f8..e7e6966 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -8882,6 +8882,12 @@ enum skl_power_gate { >> >> /* Gen4+ Timestamp and Pipe Frame time stamp registers */ >> #define GEN4_TIMESTAMP _MMIO(0x2358) >> +#define GEN7_TIMESTAMP_UDW _MMIO(0x235C) >> +#define PRE_GEN7_TIMESTAMP_WIDTH 32 >> +#define GEN7_TIMESTAMP_WIDTH 36 >> +#define CS_TIMESTAMP_WIDTH(dev_priv) \ >> + (INTEL_GEN(dev_priv) < 7 ? PRE_GEN7_TIMESTAMP_WIDTH : \ >> + GEN7_TIMESTAMP_WIDTH) > s/PRE_GEN7/GEN4/ would be consistent. > If you really want to add support for earlier, I9XX_. > > Ok. I can accept the justification, and we are not the only ones who do > the cyclecounter -> timecounter correction like this. > -Chris From 1585564276592951405@xxx Fri Dec 01 07:05:27 +0000 2017 X-GM-THRID: 1585564276592951405 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread