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 562CBCCD1BF for ; Thu, 23 Oct 2025 22:13:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E2EB710E964; Thu, 23 Oct 2025 22:13:26 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="iLgMzwRw"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5E25010E964; Thu, 23 Oct 2025 22:13:26 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 8C8BA64168; Thu, 23 Oct 2025 22:13:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D307C4CEE7; Thu, 23 Oct 2025 22:13:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761257605; bh=hTBrDKVoeskq+MifAVXcmfFHC4o+oZ5r7Ay9n1/z9nM=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=iLgMzwRwqOy7sXJZ/cj7mFF4anpc72L+LOLPSOst+38/v7JsCdFZIWnetBjui1OZp yN9rhy18xXZFkMpJvT3bCqAxi3fO+pkh+MOmaEAMU2w73RWUHGkiSwoHDvolqgHifO laPHaAbteCJg3k/b1htoXUTJp5NAAji1iY4F576yFl0w0NQYjIgpclFc9+tOGmnT+4 e8jP+OrOXoPfmaDh+HaT1WKhHadjTfdYLaX3ULIsY5VgsyZXqNPTKerWKaJ0kqWB1B N+0zaF4mRsDvn68jOb99Z3vIwQv/JhMqiP622akyX0d/1RuJGj9Nu4QkURbt7NFlvh N6Fr/s7aGkeRA== Date: Thu, 23 Oct 2025 17:13:23 -0500 From: Bjorn Helgaas To: Lucas De Marchi Cc: Ilpo =?utf-8?B?SsOkcnZpbmVu?= , linux-pci@vger.kernel.org, Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Christian =?utf-8?B?S8O2bmln?= , =?utf-8?Q?Micha=C5=82?= Winiarski , Alex Deucher , amd-gfx@lists.freedesktop.org, David Airlie , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Simona Vetter , Tvrtko Ursulin , "Michael J . Ruhl" , Andi Shyti , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 00/11] PCI: Resizable BAR improvements Message-ID: <20251023221323.GA1325049@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Thu, Oct 23, 2025 at 05:02:42PM -0500, Lucas De Marchi wrote: > On Thu, Oct 23, 2025 at 04:29:43PM -0500, Bjorn Helgaas wrote: > > On Wed, Oct 22, 2025 at 04:33:20PM +0300, Ilpo Järvinen wrote: > > > pci.c has been used as catch everything that doesn't fits elsewhere > > > within PCI core and thus resizable BAR code has been placed there as > > > well. Move Resizable BAR related code to a newly introduced rebar.c to > > > reduce size of pci.c. After move, there are no pci_rebar_*() calls from > > > pci.c indicating this is indeed well-defined subset of PCI core. > > > > > > Endpoint drivers perform Resizable BAR related operations which could > > > well be performed by PCI core to simplify driver-side code. This > > > series adds a few new API functions to that effect and converts the > > > drivers to use the new APIs (in separate patches). > > > > > > While at it, also convert BAR sizes bitmask to u64 as PCIe spec already > > > specifies more sizes than what will fit u32 to make the API typing more > > > future-proof. The extra sizes beyond 128TB are not added at this point. > > > > > > Some parts of this are to be used by the resizable BAR changes into the > > > resource fitting/assingment logic but these seem to stand on their own > > > so sending these out now to reduce the size of the other patch series. > > > > > > v3: > > > - Rebased to solve minor conflicts > > > > > > v2: https://lore.kernel.org/linux-pci/20250915091358.9203-1-ilpo.jarvinen@linux.intel.com/ > > > - Kerneldoc: > > > - Improve formatting of errno returns > > > - Open "ctrl" -> "control" > > > - Removed mislead "bit" words (when referring to BAR size) > > > - Rewrote pci_rebar_get_possible_sizes() kernel doc to not claim the > > > returned bitmask is defined in PCIe spec as the capability bits now > > > span across two registers in the spec and are not continuous (we > > > don't support the second block of bits yet, but this API is expected > > > to return the bits without the hole so it will not be matching with > > > the spec layout). > > > - Dropped superfluous zero check from pci_rebar_size_supported() > > > - Small improvement to changelog of patch 7 > > > > > > Ilpo Järvinen (11): > > > PCI: Move Resizable BAR code into rebar.c > > > PCI: Cleanup pci_rebar_bytes_to_size() and move into rebar.c > > > PCI: Move pci_rebar_size_to_bytes() and export it > > > PCI: Improve Resizable BAR functions kernel doc > > > PCI: Add pci_rebar_size_supported() helper > > > drm/i915/gt: Use pci_rebar_size_supported() > > > drm/xe/vram: Use PCI rebar helpers in resize_vram_bar() > > > PCI: Add pci_rebar_get_max_size() > > > drm/xe/vram: Use pci_rebar_get_max_size() > > > drm/amdgpu: Use pci_rebar_get_max_size() > > > PCI: Convert BAR sizes bitmasks to u64 > > > > > > Documentation/driver-api/pci/pci.rst | 3 + > > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +- > > > drivers/gpu/drm/i915/gt/intel_region_lmem.c | 10 +- > > > drivers/gpu/drm/xe/xe_vram.c | 32 +- > > > drivers/pci/Makefile | 2 +- > > > drivers/pci/iov.c | 9 +- > > > drivers/pci/pci-sysfs.c | 2 +- > > > drivers/pci/pci.c | 145 --------- > > > drivers/pci/pci.h | 5 +- > > > drivers/pci/rebar.c | 314 ++++++++++++++++++++ > > > drivers/pci/setup-res.c | 78 ----- > > > include/linux/pci.h | 15 +- > > > 12 files changed, 350 insertions(+), 273 deletions(-) > > > create mode 100644 drivers/pci/rebar.c > > > > Applied to pci/rebar for v6.18, thanks, Ilpo! > > is this for v6.18 or it's a typo and it's going to v6.19? Oops, sorry, I meant v6.19! I still have v6.18 regressions top of mind :) > > If we have follow-on resource assignment changes that depend on these, > > maybe I'll rename the branch to be more generic before applying them. > > > > Also applied the drivers/gpu changes based on the acks. I see the CI > > merge failures since this series is based on v6.18-rc1; I assume the > > CI applies to current linux-next or similar. I'll check the conflicts > > it tries on drm-tip that contains drm-xe-next going to v6.19. We have > some changes there that conflict, but shouldn't be hard. > > We also need https://lore.kernel.org/linux-pci/20250918-xe-pci-rebar-2-v1-1-6c094702a074@intel.com/ > to actually fix the rebar in some cases. Could you take a look? Will do. Remind me again if I forget! Bjorn