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 E02B7CA0EEB for ; Sat, 23 Aug 2025 01:57:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8688710E06C; Sat, 23 Aug 2025 01:57:43 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="Plhl8mOH"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by gabe.freedesktop.org (Postfix) with ESMTPS id D87D810E06C for ; Sat, 23 Aug 2025 01:57:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1755914262; x=1787450262; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=vSf0uW17vfkEY0kucSAEJ7avUz4U8RhqmnPhGYAHoNg=; b=Plhl8mOHYk9YsbFUdaFhRz+asxDzLZZw+vaSAOjMXuiEsaxECrGzvgxM 5zESMUHqw8wyrPbi6hv+ok+dbYn9PwYf1K7zwNof2TIW21iDMugDruhSs ElcSFf9KYW7ZWCFYKHPGLl5R/BvpYomVw3wpmKoGiIPenF2F2g3vaUH67 3SnhhfeYxP2LAs1yCYpUksp3WL8YpdFPh1dj1clY7+zKHeL3kbEo+//oc vO6I31pB5qGy6HRnJmBnz06fgVPx/8hafM5/bJg8+pp/mn1QqW4rGLVaK HVLKXORrCLiMWvOjOZyE7ONm5VR75tuPfilRmd7h53OZLNxj+7ZnObyUk A==; X-CSE-ConnectionGUID: ojnU3bFkTrm21u3JXPT1qA== X-CSE-MsgGUID: 0bxpsYY0RSyYnjZM4WOaAg== X-IronPort-AV: E=McAfee;i="6800,10657,11529"; a="58172649" X-IronPort-AV: E=Sophos;i="6.17,312,1747724400"; d="scan'208";a="58172649" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2025 18:57:41 -0700 X-CSE-ConnectionGUID: EXhYLXYPQKOf/T0YVF26Cg== X-CSE-MsgGUID: WOZEtO1YThiZfyxmANIw9w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,312,1747724400"; d="scan'208";a="192503855" Received: from robingup-mobl1.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.124.81.58]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2025 18:57:41 -0700 Date: Fri, 22 Aug 2025 18:57:40 -0700 Message-ID: <87v7meyf3f.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Rodrigo Vivi Cc: Matthew Brost , Aakash Deep Sarkar , , , Subject: Re: [PATCH v2 1/8] [ANDROID]: Add a new xe_user structure In-Reply-To: References: <20250822085932.2221054-1-aakash.deep.sarkar@intel.com> <20250822085932.2221054-2-aakash.deep.sarkar@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/29.4 (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 Fri, 22 Aug 2025 13:09:51 -0700, Rodrigo Vivi wrote: > > On Fri, Aug 22, 2025 at 10:01:25AM -0700, Matthew Brost wrote: > > On Fri, Aug 22, 2025 at 11:48:54AM -0400, Rodrigo Vivi wrote: > > > On Fri, Aug 22, 2025 at 08:59:23AM +0000, Aakash Deep Sarkar wrote: > > > > For Android GPU work period event we need to track the runtime > > > > on the GPU for each user id. This means we can have multiple > > > > xe files opened by different processes/threads belonging to > > > > the same user id. All these xe files need to be grouped together > > > > so that one can easily identify these while calculating the > > > > run time for the given user id. > > > > > > > > Currently, the xe driver doesn't record the user id of the > > > > calling process. Also, all the xe files created using open > > > > call are clubbed together inside the xe device structure > > > > with no way to distinguish between them based on the user id > > > > of the calling process. > > > > > > I thought I had already given this feedback, but I'm not sure if > > > I forgot or if I was just ignored. I'm sorry either way. > > > > > > Android is not a justification. Please keep 'Android' mentions > > > and ralated 'Android' justifications in the cover letter ONLY! > > > > > > The patch needs to make sense by itself. The patch needs to make > > > sense in the currently linux upstream. > > > > > > > So what are the rules here? There is another series [1] floating around > > with a justification that Android needs this. Does that mean we can't > > accept any Andriod only code upstream? > > I'm sorry for not being clear. Of course we can accept Android code > upstream. I wish we had more (all?) Android code upstream ;) > > But we cannot add in xe, for instance, something with the namespace > /sys/kernel/tracing/events/power/gpu_work_period where > gpu_work_period is a definition in the Android tree only. > > We could add xe_work_period. If Android user space consumes gpu_work_period, shouldn't gpu_work_period be added at the drm level (rather than at xe level)? I had a similar comment about gpu_frequency ftrace event here: https://lore.kernel.org/intel-xe/87wm6vxedi.wl-ashutosh.dixit@intel.com/T/#me6005d00c09bf2198cc2a7465e780f50bd1ff291 Thanks. -- Ashutosh