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=-3.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 476A2C3F2CD for ; Wed, 4 Mar 2020 05:48:00 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 24902214D8 for ; Wed, 4 Mar 2020 05:48:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24902214D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AEA416EAAA; Wed, 4 Mar 2020 05:47:59 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 657166EAAA for ; Wed, 4 Mar 2020 05:47:58 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2020 21:47:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,513,1574150400"; d="scan'208";a="319712462" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.251.157.237]) by orsmga001.jf.intel.com with ESMTP; 03 Mar 2020 21:47:57 -0800 Date: Tue, 03 Mar 2020 21:47:56 -0800 Message-ID: <87wo80u0vn.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: <20200303221905.25866-7-umesh.nerlige.ramappa@intel.com> References: <20200303221905.25866-1-umesh.nerlige.ramappa@intel.com> <20200303221905.25866-7-umesh.nerlige.ramappa@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Subject: Re: [Intel-gfx] [PATCH 6/7] drm/i915/perf: add interrupt enabling parameter X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 03 Mar 2020 14:19:04 -0800, Umesh Nerlige Ramappa wrote: > > From: Lionel Landwerlin > > This let's the application choose to be driven by the interrupt > mechanism of the HW. In conjuction with long periods for checks for > the availability of data on the CPU, this can reduce the CPU load when > doing capture of OA data. > > v2: Version the new parameter (Joonas) > v3: Rebase (Umesh) > > Signed-off-by: Lionel Landwerlin > Signed-off-by: Umesh Nerlige Ramappa [snip] > + /** > + * Specifying this property sets up the interrupt mechanism for the OA > + * buffer in i915. This option in conjuction with a long polling delay > + * for avaibility of OA data can reduce CPU load significantly if you > + * do not care about OA data being read as soon as it's available. > + * > + * This property is available in perf revision 5. > + */ > + DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT, What if we do not expose this parameter in the uapi at all and internally decide in i915 whether to leave the interrupt either always enabled or always disabled (and in that case always use the hrtimer)? This way we retain flexibility in i915 if hardware evolves in the future e.g. to use watermarks for the interrupt, without yielding control to userspace. Overall I feel we should avoid exposing unnecessary details of the internal implemenation to userspace, they would be neither interested in knowing internal details nor know how to properly use these parameters. Shouldn't the driver be able to make these kinds of decisions internally? At this point the only parameter which implicitly exposed to userspace is the hrtimer poll period, so perhaps all we need to do is to expose that in the uapi? Thoughts? _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx