On Sun, Jun 2, 2019 at 9:43 PM Kishon Vijay Abraham I <kishon@xxxxxx> wrote: > Hi Alan, > On 31/05/19 11:46 PM, Alan Mikhak wrote: > > On Thu, May 30, 2019 at 10:08 PM Kishon Vijay Abraham I <kishon@xxxxxx> wrote: > >> Hi Alan, > >>> Hi Kishon, > >> > >> I still have to look closer into your DMA patch but linked-list mode or single > >> block mode shouldn't be an user select-able option but should be determined by > >> the size of transfer. > > > > Please consider the following when taking a closer look at this patch. > > After seeing comments from Vinod and Arnd, it looks like the better way of > adding DMA support would be to register DMA within PCI endpoint controller to > DMA subsystem (as dmaengine) and use only dmaengine APIs in pci_epf_test. Thanks Kishon. That makes it clear where these pieces should go. > > In my specific use case, I need to verify that any valid block size, > > including a one byte transfer, can be transferred across the PCIe bus > > by memcpy_toio/fromio() or by DMA either as a single block or as > > linked-list. That is why, instead of deciding based on transfer size, > > this patch introduces the '-L' flag for pcitest to communicate the > > user intent across the PCIe bus to pci-epf-test so the endpoint can > > initiate the DMA transfer using a single block or in linked-list mode. > The -L option seems to select an internal DMA configuration which might be > specific to one implementation. As Gustavo already pointed, we should have only > generic options in pcitest. This would no longer be applicable when we move to > dmaengine. Single-block DMA seemed as generic as linked-list DMA and memcpy_toio/fromio. It remains unclear how else to communicate that intent to pci_epf_test each time I invoke pcitest. Regards, Alan
