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 6A0ABC74A5B for ; Wed, 29 Mar 2023 07:43:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0773510E4D5; Wed, 29 Mar 2023 07:43:40 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 24B9810E4D5; Wed, 29 Mar 2023 07:43:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680075818; x=1711611818; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=teJX4UjNTy0Lep0ahaCy0XDVc43fT1FYcbF85MQWYN8=; b=WPz85PrC4HyyJU9tvxY3LrhTI0/PlOuGaBF4YfhRsEexM45hgx6YKzaa xzV4pSl9tcXGf3o8K+UVB/fc61j0R+qoSim8Wn/2ZC/wHh5CDK+QnA6ic ciRIenbGtczvQXJynwDhzOsmklPmUWYPdxrr3mOsoYXp4Bh87XYg+Nrpt 7UDGSI92akZADw/rIv4aV9tDQ3btcdW8vCAIkPa7Qv9rAuWQ9qqNJIEQp Gd0OZQMrtX+naJzW4+h3DTLtaMKm99sxmesnRUuDddH80zJX4rHpvDjzf Tv6uPhsEl4u5JiimA8aCLZ8xZ5cKqW7zrk3YbSA4dCyxMGnewghI9w8dB w==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="329272070" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="329272070" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:43:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="686734053" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="686734053" Received: from jabolger-mobl2.ger.corp.intel.com (HELO [10.213.199.158]) ([10.213.199.158]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:43:25 -0700 Message-ID: <118981ef-260d-4c1a-5ca5-ad435d5edbc7@linux.intel.com> Date: Wed, 29 Mar 2023 08:43:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US To: Rodrigo Vivi , "Teres Alexis, Alan Previn" References: <20230228022150.1657843-1-alan.previn.teres.alexis@intel.com> <20230228022150.1657843-6-alan.previn.teres.alexis@intel.com> <3b8091c51677878b968d1d275b9b16e5088d913d.camel@intel.com> <3359c9d371a25710891352061693637b37679734.camel@intel.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Intel-gfx] [PATCH v6 5/8] drm/i915/pxp: Add ARB session creation and cleanup 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" , "dri-devel@lists.freedesktop.org" , "Lahtinen, Joonas" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 28/03/2023 18:52, Rodrigo Vivi wrote: > On Tue, Mar 28, 2023 at 05:01:36PM +0000, Teres Alexis, Alan Previn wrote: >> On Mon, 2023-03-27 at 17:15 +0100, Tvrtko Ursulin wrote: >>> These two: >>> e6177ec586d1 ("drm/i915/huc: stall media submission until HuC is loaded") >>> b76c14c8fb2a ("drm/i915/huc: better define HuC status getparam possible return values.") >>> They do not help here? It is not possible to use or extend the refined I915_PARAM_HUC_STATUS return values combined with huc load fence for this all to keep working? >> Checking is-huc-loaded won't reflect is-pxp-available (in case fw/fusing isn't allowing it). But the connection between them is hw-internal so i915 asking PXP-fw to attempt a PXP >> session depends on HuC (and the 3 other things i mentioned). However, Tvrtko's point on using fences-or-equivalent is the same thing John Harrison brought up offline with Daniele >> as the proper kernel way to do this type of dependency checking. However, any form of dependency-checking won't improve UMD's experience. We still need to decide if i915-PXP should >> wait-in-kernel or return some-new-spec-error. A useful data point: we are debugging a related issue on actual customer stack. The compositor using mesa is hitting this code path >> very early.. even before gsc-proxy component is loaded and we are trying to figure out why delaying inside intel_pxp_start is not helping (more delays causes the gsc-proxy >> component to also get delayed) but that is a different conversation. I'm only mentioning this because we have a strict requirement to get the desktop login window up within 1-2 >> seconds of bootloader->kernel handoff. That said, if use -EAGAIN, I'm not sure if that would work as it would delay the compositor startup beyond the typical end user experience >> unless MESA has a timeout to give up on a cap-testing when seeing repeated -EAGAIN (doubt mesa folks like this?). Perhaps we could just immediately return with a different error >> (instead of current PXP-UAPI spec of -EINVAL or -ENODEV)... perhaps use -ENXIO which apparently is already part of the original pxp code but was never mentioned in UAPI - but we >> return this immediately and document it in UAPI as "hw/fw insfratructure is not yet ready to create pxp arb session, user space can retry but may need delays of up to x-seconds on >> ADl/TGL or y-seconds on MTL, before getting a SUCCESS or one of the other errors). > > fair enough. It looks like we need a new get_param! :) To check I understood this - new parameter would be like "is pxp support present"? And then later it can still fail to initialize due some parameters not easily detectable during boot/probe? How will the context create path look like on those platforms: 1. Block, then potentially error out if the full initialization failed. 2. Error out "in progress" while initializing, error out "something else" if initialization failed. ? Regards, Tvrtko