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 9F38AFED2D1 for ; Thu, 12 Mar 2026 06:52:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 42C9D10E13B; Thu, 12 Mar 2026 06:52:41 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="ASONHl7d"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by gabe.freedesktop.org (Postfix) with ESMTPS id D818210E13B for ; Thu, 12 Mar 2026 06:52:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773298360; x=1804834360; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=4Xd6YsgbDyRtaCT67+cPF6yycln/OAzYaCyx56RQ2Tw=; b=ASONHl7dAt2SnplG99kjL7wy7bumwRgZpAksJXphVJfyltgLwfZ0QvKn vM/yqVduOCpm43UzP6VO/WiGpHHMhnLmyPPJnNVt/ceHNYB3YDphGqO1U Nrc35BndbnOrDIYyYa0bURmRsziN2OCWgvcHFfCicJtvCx5iX6b1Lasur 8y+FhMg8u0zPtRyL7hhKJ9TgtgQEn6DsURFpHcL7XHowsC5RWhGdQjUtq VUchD+SmaUfqTOZ7c3945uZN6xh7UrIB0PMrCIpZ9i/4GkX1foPDFAZve +pWSykK+Iq8dXol+hGvi5cRHyLT3FFaJREsYWLsU/y4Tn8j33U+1CHqzg g==; X-CSE-ConnectionGUID: aKRPge8GRX+YmDRFTpvH9A== X-CSE-MsgGUID: zEJpLlEoTOSGrAKewr6Weg== X-IronPort-AV: E=McAfee;i="6800,10657,11726"; a="85467603" X-IronPort-AV: E=Sophos;i="6.23,115,1770624000"; d="scan'208";a="85467603" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2026 23:52:40 -0700 X-CSE-ConnectionGUID: uidB+LbeQUaMm3uVa/RfkQ== X-CSE-MsgGUID: ketiIVmzSlies/Xc1wc54g== X-ExtLoop1: 1 Received: from dschmi2x-mobl.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.124.49.53]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2026 23:52:39 -0700 Date: Wed, 11 Mar 2026 23:52:38 -0700 Message-ID: <87wlzhwnd5.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Cc: , Robert Krzemien Subject: Re: [PATCH] drm/xe/oa: Allow reading after disabling OA stream In-Reply-To: References: <20260311210107.3112353-1-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/30.2 (x86_64-pc-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 Wed, 11 Mar 2026 21:24:14 -0700, Umesh Nerlige Ramappa wrote: > Hi Umesh, > On Wed, Mar 11, 2026 at 02:01:07PM -0700, Ashutosh Dixit wrote: > > Some OA data might be present in the OA buffer when OA stream is > > disabled. Allow UMD's to retrieve this data, so that all data till the > > point when OA stream is disabled can be retrieved. > > > > Signed-off-by: Ashutosh Dixit > > --- > > drivers/gpu/drm/xe/xe_oa.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c > > index 72fc4424017bf..f840827960eab 100644 > > --- a/drivers/gpu/drm/xe/xe_oa.c > > +++ b/drivers/gpu/drm/xe/xe_oa.c > > @@ -543,8 +543,7 @@ static ssize_t xe_oa_read(struct file *file, char __user *buf, > > size_t offset = 0; > > int ret; > > > > - /* Can't read from disabled streams */ > > - if (!stream->enabled || !stream->sample) > > + if (!stream->sample) > > return -EINVAL; > > What if there is no data to be read when the stream was disabled? In polled > mode, we are probably fine, but in blocking mode, we may just wait forever > here. Yes, correct. There is no problem in non-blocking read() (it will return -EAGAIN if no data). But poll() or blocking read() can block. However, as far as I see, the responsibility of unblocking the blocked thread (e.g. by means of a signal) rests with UMD. Note: blocking read() cannot return 0 (it can, only on EOF, see 'man 2 read' but I don't want to do it because "what is EOF"). Similarly poll() cannot return if there's no data, UMD will need to specify a timeout in poll(). Note, KMD release() method will not get called if UMD thread is blocked in read(). So stream cannot be closed till the blocked thread is unblocked. I would imagine UMD will use non-blocking read()'s to retrieve data after stream is disabled, till non-blocking read() returns -EAGAIN. If they don't use non-blocking read(), they will have to handle the blocked thread using one of the methods above. There's nothing KMD can do. Unless you or Robert (Cc'd) can prove otherwise :-) > > > > if (!(file->f_flags & O_NONBLOCK)) { > > -- > > 2.48.1 > >