lkml.org 
[lkml]   [2019]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] swiotlb: sync buffer when mapping FROM_DEVICE
    From
    Date
    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.

    \
     
     \ /
      Last update: 2019-05-22 15:57    [W:4.758 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site