lkml.org 
[lkml]   [2002]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Possible discrepancy regarding streaming DMA mappings in DMA-mapping.txt?
    On Fri, May 24, 2002 at 10:42:09AM -0700, David S. Miller wrote:
    > I see what your problem is, the interfaces were designed such
    > that the CPU could read the data. It did not consider writes.
    >
    > It was designed to handle a case like a networking driver where
    > a receive packet is inspected before we decide whether we accept the
    > packet or just give it back to the card.

    I was thinking about whether we could keep the same API but change the
    semantics such that, for a cpu-writes-and-gives-to-driver operation, a
    pci_dma_sync_*() called with PCI_DMA_TODEVICE would occur between the
    write and the DMA:

    1) driver gets buffer from pool and writes into it
    2) driver calls pci_dma_sync_single(..., PCI_DMA_TODEVICE) which
    in turn copies to a bounce buffer, flushes cache and write
    buffers (whichever are relevant per architecture)
    3) driver sets up DMA
    4) controller DMAs the packet
    5) driver acknowledges DMA completion, implicitly "takes back"
    buffer and puts into pool
    6) goto 1)

    The problem concerns the meaning of the driver or controller "owning" a
    buffer. Should there be a call between steps 4) and 5) where the driver
    "reclaims" the buffer? Yet, by this point, nothing should have changed
    in the buffer, so there's no reason to copy from the bounce-buffer or
    write-back/invalidate cache lines.

    So the question is: After having written to a buffer, called
    pci_dma_sync_*(), and DMAed the buffer, is there anything left to do
    (for certain architectures) before the driver can re-claim it and begin
    writing into the buffer again? If the answer is no, then I propose we
    keep the API the way it is and change the semantics such that, for
    writing streaming buffers to a driver, pci_dma_sync_*() must be called
    after all driver writes have completed and before the DMA occurs, thus
    transferring "ownership" to the driver.

    But to contradict myself and say how I think the API should change...

    The pci_(un)map_*() routines provide a convenient model for maintaining
    cache coherency in situations where one maps a buffer, does DMA, and
    unmaps it once again. For streaming DMA where a set of buffers stay
    mapped, however, using pci_dma_sync_*() to handle two different problems
    (providing a mapping that the controller can view and maintaining
    cache/write-buffer coherency) is, IMHO, somewhat confusing. Having an
    API where separate calls are used for these problems allows the driver
    writer to more explicitly say things such as:

    [write into buffer]
    pci_dma_sync(buffer, TO_DEVICE) // -Does writeback and wbflush
    pci_dma_controller_owns(buffer, TO_DEVICE) // -Bounce-buffer copy, etc
    [dma to controller]
    pci_dma_driver_owns(buffer, TO_DEVICE) // -Prepare for CPU write...
    (no need to sync - the buffer couldn't have changed)

    I have a more complex example that could affect this design, but I'm
    going to sit on it for a short while instead of making this e-mail even
    longer. :o)

    Thanks,
    William
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:26    [W:0.026 / U:0.708 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site