On 11.09.25 09:55, 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. > > These are based on pci/main, there are two minor conflicts with the > work in pci/resource but I'm hesitant to base this on top of it as this > is otherwise entirely independent. If we end up having to pull the > bridge window select changes, there should be no reason why this does > have to become collateral damage (so my suggestion, if this is good to > go in this cycle, to take this into a separate branch than pci/resource > and deal with those small conflicts while merging into pci/next). > > I've tested sysfs resize, i915, and xe BAR resizing functionality. In > the case of xe, I did small hack patch as its resize is anyway broken > as is because BAR0 pins the bridge window so resizing BAR2 fails. My > hack caused other problems further down the road (likely because BAR0 > is in use by the driver so releasing it messed assumptions xe driver > has) but the BAR resize itself was working which was all I was > interested to know. I'm not planning to pursue fixing the pinning > problem within xe driver because the core changes to consider maximum > size of the resizable BARs should take care of the main problem by > different means. > > 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.
Yeah, sounds like a good idea to me. Before I answer each mail individually: Patches #1-#3, #8, #10 and #11 are Reviewed-by: Christian König <christian.koe...@amd.com>. Patches #6, #7 and #9 are Acked-by: Christian König <christian.koe...@amd.com>. Nit pick comments on patches #4 and #5, feel free to add my rb to them as well when those are fixed. Regards, Christian. > > > 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 | 318 ++++++++++++++++++++ > drivers/pci/setup-res.c | 78 ----- > include/linux/pci.h | 15 +- > 12 files changed, 354 insertions(+), 273 deletions(-) > create mode 100644 drivers/pci/rebar.c > > > base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
