Messages in this thread | | | Subject | Re: [PATCH] swiotlb: sync buffer when mapping FROM_DEVICE | From | Robin Murphy <> | Date | Wed, 22 May 2019 14:55:50 +0100 |
| |
On 22/05/2019 14:34, Christoph Hellwig wrote: > On Wed, May 22, 2019 at 02:25:38PM +0100, Robin Murphy wrote: >> Sure, but that should be irrelevant since the effective problem here is in >> the sync_*_for_cpu direction, and it's the unmap which nobbles the buffer. >> If the driver does this: >> >> dma_map_single(whole buffer); >> <device writes to part of buffer> >> dma_unmap_single(whole buffer); >> <contents of rest of buffer now undefined> >> >> then it could instead do this and be happy: >> >> dma_map_single(whole buffer, SKIP_CPU_SYNC); >> <device writes to part of buffer> >> dma_sync_single_for_cpu(updated part of buffer); >> dma_unmap_single(whole buffer, SKIP_CPU_SYNC); >> <contents of rest of buffer still valid> > > Assuming the driver knows how much was actually DMAed this would > solve the issue. Horia, does this work for you?
Ohhh, and now I've just twigged what you were suggesting - your DMA_ATTR_PARTIAL flag would mean "treat this as a read-modify-write of the buffer because we *don't* know exactly which parts the device may write to". So indeed if we did go down that route we wouldn't need any of the sync stuff I was worrying about (but I might suggest naming it DMA_ATTR_UPDATE instead). Apologies for being slow :)
Robin.
| |