On Fri, Nov 29, 2024 at 10:05:55PM +0530, Manivannan Sadhasivam wrote:
On Fri, Nov 29, 2024 at 02:51:26PM +0100, Niklas Cassel wrote:
Hello Mani,
On Fri, Nov 29, 2024 at 02:54:15PM +0530, Manivannan Sadhasivam wrote:
Migrate the PCI endpoint test to Kselftest framework. All the tests that were part of the previous pcitest.sh file were migrated.
Below is the exclusive list of tests:
- BAR Tests (BAR0 to BAR5)
- Legacy IRQ Tests
- MSI Interrupt Tests (MSI1 to MSI32)
- MSI-X Interrupt Tests (MSI-X1 to MSI-X2048)
- Read Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Write Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Copy Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Read Tests - DMA (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Write Tests - DMA (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Copy Tests - DMA (For 1, 1024, 1025, 1024000, 1024001 Bytes)
I'm not sure if it is a great idea to add test case number 10.
While it will work if you use the "dummy memcpy" DMA channel which uses MMIO under the hood, if you actually enable a real DMA controller (which often sets the DMA_PRIVATE cap in the DMA controller driver (e.g. if you are using a DWC based PCIe EP controller and select CONFIG_DW_EDMA=y)), pci_epf_test_copy() will fail with: [ 93.779444] pci_epf_test pci_epf_test.0: Cannot transfer data using DMA
So the idea is to exercise all the options provided by the epf-test driver. In that sense, we need to have the DMA COPY test. However, I do agree that the common DMA controllers will fail this case. So how about just simulating the DMA COPY for controllers implementing DMA_PRIVATE cap? I don't think it hurts to have this feature in test driver.
I guess you could modify pci-epf-test to simply do MMIO in test_copy(), if USE_DMA && DMA_PRIVATE is set, as you suggest.
We should probably print a warning/info that we are falling back to MMIO in that case though.
Kind regards, Niklas