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 67219C021B2 for ; Tue, 25 Feb 2025 20:30:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 91B8C10E69A; Tue, 25 Feb 2025 20:30:28 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="iHf0cPdM"; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6D2B110E69A for ; Tue, 25 Feb 2025 20:30:27 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 86A1F5C70FD; Tue, 25 Feb 2025 20:29:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2324C4CEDD; Tue, 25 Feb 2025 20:30:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740515426; bh=rovhXK4tfCJIYykPC7TY04RQpYyM+0gQ2VvPGXE/Yuk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=iHf0cPdMNyr+SfdTQ6MirU675NOHmGp9hQvw4v9c5KCbQi8bWOgY7K5VioqSQkCn6 YPjReAOaSs66s3suFj25s4dVLkI4oThna0W5oIdOQX80PLiieLT56N/V/hkjnGy7UC vlHgD4LcQyvuapnKabZ7dqhJVXRH+Xo7S8Ywm/UJIaIi8KbITp8d5g6iFpHbDZwLaj c4FR09tBO7po8pcmcOsZne2DKCYshzVOyigxMIjibSYAAAVNleD3w5USJ/oIvZYSCv sZMaapDJOXvte1BJHIIpL5xPiDGtMr37t4K7rdfc72kN7wdMrIDZxSj2G5/J6oDcQ3 jdFcnp6LkMuNg== Date: Tue, 25 Feb 2025 14:30:24 -0600 From: Bjorn Helgaas To: "Gupta, Anshuman" Cc: "intel-xe@lists.freedesktop.org" , "linux-acpi@vger.kernel.org" , "linux-pci@vger.kernel.org" , "rafael@kernel.org" , "lenb@kernel.org" , "bhelgaas@google.com" , "ilpo.jarvinen@linux.intel.com" , "De Marchi, Lucas" , "Vivi, Rodrigo" , "Nilawar, Badal" , "Nasim, Kam" , "Gupta, Varun" Subject: Re: [RFC 1/6] PCI/ACPI: Implement PCI FW _DSM method Message-ID: <20250225203024.GA516174@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Feb 25, 2025 at 06:25:52PM +0000, Gupta, Anshuman wrote: > > -----Original Message----- > > From: Bjorn Helgaas > ... redundant headers snipped > > On Mon, Feb 24, 2025 at 10:18:44PM +0530, Anshuman Gupta wrote: > > > Implement _DSM method 10 and _DSM Method 11 as per PCI firmware > > specs > > > section 4.6.10 and 4.6.11. > > > > Please split into two patches, one for each _DSM. Include spec > > citations, e.g., PCI Firmware r3.3, sec 4.6.10. Section numbers > > are not guaranteed to stay consistent across spec revisions, so we > > need both the revision and section number. > > > > Include some descriptive words about the DSM in each subject line, > > e.g., "D3cold Aux Power Limit", "PERST# Assertion Delay". > > > > > Current assumption is only one PCIe Endpoint driver (XeKMD for > > > Battlemage GPU) will request for Aux Power Limit under a given Root > > > Port but theoretically it is possible that other Non-Intel GPU or > > > Non-GPU PCIe Endpoint driver can also request for Aux Power Limit and > > > request to block the core power removal under same Root Port. > > > That will disrupt the Battlemage GPU VRAM Self Refresh. > > > > I guess this is sort of an acknowledgement of the r3.3, sec 4.6.10 spec text > > about system software being responsible for tracking and aggregating > > requests when there are multiple functions below the Downstream Port? > AFAIU apart from multiple function below the Downstream Port (from > same PCIe Card), there can be possibility of another PCie card > connected via a switch to same root port like below topology. > > |-> PCIe PCIe Downstream Port -> End Point Device > Root Port -> PCIe Upstream Port |-> PCIe PCIe Downstream Port -> End Point Device > |-> PCIe PCIe Downstream Port -> PCIe Upstream Port -> PCIe Downstream Port -> *EndPoint Device > > *Endpoint Device from different PCIe card can also request to block the core power removal under same Root Port ? Of course. > How to document such limitation ? > > If so, remove the Battlemage-specific language and just say something about > > the fact that this implementation doesn't do any of that tracking and > > aggregation. ^^ Here's a hint about how to document this. My point is that this has nothing to do with Battlemage in particular, so the text about Battlemage-specific things is a distraction from the real point, which IIUC is this: Note that this implementation assumes only a single device below the Downstream Port because it does not track and aggregate requests from all child devices below the Downstream Port as required by sec 4.6.10. > > > One possible mitigation would be only allowing only first PCIe > > > Non-Bridge Endpoint Function 0 driver to call_DSM method 10.