Hi Prabhakar-san, > From: Lad, Prabhakar, Sent: Monday, March 30, 2020 10:47 PM <snip> > > > Agreed. But we don't flush in SW when -d option is not specified I am > > > assuming when we us > > > -d dma engine takes care of flushing it. > > > > The -d option switch doesn't change anything on the SW that runs on the host > > side (misc/pci-endpoint-test.c). That only tells the EP to use DMA. > > > > When you use streaming APIs, dma_map_single(), dmap_unmap_single() takes care > > of flushing or invalidating memory based on the platform. (Platforms which have > > coherent memory will have dma-coherent property, > > dma_map_single()/dmap_unmap_single() will not do flush or invalidate. > > > My bad, I thought dma_sync*() calls did it. > > Shimoda-san do you see any platform restrictions while using streaming DMA api > instead of coherent memory. Note I tried this enabling/disabling ipmmu > too but the > results are the same. (Un)fortunately, I have never replaced coherent memory API with stream DMA API. > > Did you try to probe the failure further by comparing the hexdumps? Where does > > the mismatch happen? > > > I shall dump the memory and check the values, but basically crc is failing. I'm also interesting about comparing the hexdump between host and ep. This is my gut feeling though, I'm guessing this is a timing issue because using coherent memory API will be on non-cache even if CPU access, but using steaming DMA API will be on cache if CPU access by dma_unmap_single(DMA_FROM_DEVICE) and get_random_bytes() in pci_endpoint_test_write(). If my guess is correct, almost all hexdumps are the same, but last some bytes (I'm not sure how much bytes though) are not match. Best regards, Yoshihiro Shimoda
