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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 1F70DE7717F for ; Tue, 17 Dec 2024 02:17:04 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E2A8310E837; Tue, 17 Dec 2024 02:17:03 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="mhU/WmE6"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8B05810E837 for ; Tue, 17 Dec 2024 02:17:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1734401823; x=1765937823; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=9Fkw6+hmngmdw7S7dhBSSvpIPK7FXelXJ7ki9qXgmoE=; b=mhU/WmE6WNiWLRzsTZgAIn9Fo+E9UCNjJ2XaVWU36/d3ZZ48/QPOVhfu XFPcC7sRs+B3LgC+Vy9adNHRyKWSX9nkYlZPJcXfF1kQmZqVdemJylT+f O0irxvaypY2UYhb2BuoDstNMEspWTowb2g5JeicSHsg4zpXX4joJyhJ2C mgQI9lVdc0P6FkgVcs5SYEBW6oec7eDg9xxYiTUwYc2wpZnV9PVm4f0iP VtkhZGLXSDQgiHjx1mRXG7JzoxibnsSDnlfosOI0XsLROUUvVEbT6pZj1 Z5HLIBhzXOceR2EuVzamWdpEaxcYUiaZOagxc4hm8kg5XCbrzBfw1lqsq w==; X-CSE-ConnectionGUID: xdby/osRQmKASaaki9RPJw== X-CSE-MsgGUID: 7zHi5/ODRtWC5KGI43l6wg== X-IronPort-AV: E=McAfee;i="6700,10204,11288"; a="34691759" X-IronPort-AV: E=Sophos;i="6.12,240,1728975600"; d="scan'208";a="34691759" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2024 18:17:03 -0800 X-CSE-ConnectionGUID: NfOCuBpqS8u9xGLNoSDHwg== X-CSE-MsgGUID: Q+5ZJV0+QdCzBY7Tr4fXNA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="101543735" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.142]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2024 18:17:02 -0800 Date: Mon, 16 Dec 2024 18:17:01 -0800 Message-ID: <858qsf2gv6.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Cc: intel-xe@lists.freedesktop.org Subject: Re: [PATCH] drm/xe/oa/uapi: Expose an unblock after N reports OA property In-Reply-To: References: <20241212224903.1853862-1-ashutosh.dixit@intel.com> <85a5cz2hrx.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Mon, 16 Dec 2024 14:48:06 -0800, Umesh Nerlige Ramappa wrote: > > >> > @@ -2156,6 +2170,14 @@ int xe_oa_stream_open_ioctl(struct drm_device *dev, u64 data, struct drm_file *f > >> > if (!param.oa_buffer_size) > >> > param.oa_buffer_size = DEFAULT_XE_OA_BUFFER_SIZE; > >> > > >> > + if (!param.wait_num_reports) > >> > + param.wait_num_reports = 1; > >> > + if (param.wait_num_reports > param.oa_buffer_size / f->size) { > >> > + drm_dbg(&oa->xe->drm, "wait_num_reports %d\n", param.wait_num_reports); > >> > + ret = -EINVAL; > >> > + goto err_exec_q; > >> > + } > >> > >> If possible, I think this check where wait_num_reports has an upper limit > >> should be moved to xe_oa_set_prop_wait_num_reports(). > > > > It's not possible since the properties can come in any order, so both the > > OA buffer size as well as the format might not be available when > > wait_num_reports property is parsed. So they could both still be 0 when > > xe_oa_set_prop_wait_num_reports() is called. > > > > That is why the code which checks for consistency between multiple > > properties comes after the code which parses individual properties. > > Oh, makes sense. Then this is: > > Reviewed-by: Umesh Nerlige Ramappa Thanks, now merged!