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 802FA106ACEA for ; Thu, 12 Mar 2026 21:16:12 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3EEBE10E305; Thu, 12 Mar 2026 21:16:12 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="a8FlQR9v"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id EAB9C10E305 for ; Thu, 12 Mar 2026 21:16:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773350171; x=1804886171; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=qySIWvuWMFx7sDGtdCLyfQpHTCMfSE2568QRpblzDNE=; b=a8FlQR9v3RKCrfkAkciQpdvyvBFvbkGdNNCOWRtBYxZuEJkvryRF1mpM kW10gMFBtcyMV3Y7zYTiYztE0PIW451jOaMho1UzLFzihvSqbUVMA8g/D K4td6wKndYPZzK2Apnb8p+sR+5QytF4a1ht69PrTQTUuZB52ulPOVaR5Z efNlqNavd/weiZ1IScVq//fy1MP9Axojbu1YFwMofKNp/Q73aRRO07/nk XuJ0G2LhJFg3cLAAupQP307uf16fHRoVEQSINOZNZ3+fVJNKUOAmbzgCn ast3+0J/N0dMOCCUrP92HJCoeeui78I9eVSBhEaOzK0bi9ROgq/fJAnaR g==; X-CSE-ConnectionGUID: rtmVbh9ySSSrnTxYFwB88Q== X-CSE-MsgGUID: ZU0wIsntQiaoS5ygrKaakA== X-IronPort-AV: E=McAfee;i="6800,10657,11727"; a="74158438" X-IronPort-AV: E=Sophos;i="6.23,116,1770624000"; d="scan'208";a="74158438" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2026 14:16:10 -0700 X-CSE-ConnectionGUID: QYtp+LdRQ5iA1Ndw6B9UAw== X-CSE-MsgGUID: ZX1LOcKlQ6O1p/tzc89nGg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,116,1770624000"; d="scan'208";a="225920253" Received: from unknown (HELO adixit-MOBL3.intel.com) ([10.241.243.126]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2026 14:16:09 -0700 Date: Thu, 12 Mar 2026 14:16:08 -0700 Message-ID: <87qzporbon.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> <87wlzhwnd5.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/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 Thu, 12 Mar 2026 05:25:58 -0700, Umesh Nerlige Ramappa wrote: > > On Wed, Mar 11, 2026 at 11:52:38PM -0700, Dixit, Ashutosh wrote: > > 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 :-) > > I guess you can argue both ways. I would think if the stream is disabled, > there is really no meaning in supporting the blocked mode, but then blocked > mode itself means that caller is blocked until data is available, so I > guess it's okay to leave it as is. Yes, today we never return 0 from read(). We either return a +ve number (num bytes read) or a -ve error. Or we block. So I strongly prefer not changing this behavior. Some UMD might be checking for >= 0, some only > 0, so if we change the 0 behavior we might also start breaking UMD/tests. > I noticed another thing - When you disable a stream, you also end up > disabling the hrtimer. Then who updates the software tail such that all the > remaining data is read? Note that the poll only waits on the poll_wq. It > does not check if new reports are available. Yeah, thanks for catching this, I think we need to do something here. Let me look some more into this and update the patch in the next couple of days. > > > >> > > >> > if (!(file->f_flags & O_NONBLOCK)) { > >> > -- > >> > 2.48.1 > >> >