On Fri, Nov 29, 2024 at 10:22:56PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Nov 29, 2024 at 05:42:26PM +0100, Niklas Cassel wrote:
> > 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:
> > > > >
> > > > > 1. BAR Tests (BAR0 to BAR5)
> > > > > 2. Legacy IRQ Tests
> > > > > 3. MSI Interrupt Tests (MSI1 to MSI32)
> > > > > 4. MSI-X Interrupt Tests (MSI-X1 to MSI-X2048)
> > > > > 5. Read Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
> > > > > 6. Write Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
> > > > > 7. Copy Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
> > > > > 8. Read Tests - DMA (For 1, 1024, 1025, 1024000, 1024001 Bytes)
> > > > > 9. Write Tests - DMA (For 1, 1024, 1025, 1024000, 1024001 Bytes)
> > > > > 10. 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.
> >
>
> No not memcpy, but using the DMA to copy from src to local buf and then local
> buf to dst. This way, we do not need to fallback and at the same time simulate
> DMA COPY.
Sounds very slow :)
What would be the value to add such code to pci-epf-test?
Sounds like we would just add a lot of extra code in pci-epf-test.c that
would not test anything new. (It would basically just be the DMA read test
followed by the DMA write test. If those tests pass, this new simulated
test should be guaranteed to pass.)
Wouldn't it make more sense to simply do something like:
if (use_dma && dma_prive) {
dev_warn(dev, "DEV_TO_DEV not supported with USE_DMA, falling back to MMIO\n");
use_dma = 0;
}
Kind regards,
Niklas
