[lkml]   [2004]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] on-chip coherent memory API for DMA
    James Bottomley wrote:
    > On Thu, 2004-07-01 at 15:14, David Brownell wrote:
    >>That can work when the scope of "DMA" knowledge is just
    >>one driver ... but when that driver is plugging into a
    >>framework, it's as likely to be some other code (maybe
    >>a higher level driver) that just wants RAM address space
    >>which, for whatever reasons, is DMA-coherent. And hey,
    >>the way to get this is dma_alloc_coherent ... or in some
    >>cases, pci_alloc_consistent.
    > If the driver can't cope then you *only* use DMA_MEMORY_MAP

    That would be the norm for all those low-level drivers,
    certainly. Except maybe on that one mysterious box,
    where the CPU can't access that memory directly ... ;)

    >>Which is why my comment was that the new feature of
    >>returning some kind of memory cookie usable on that one
    >>IBM box (etc) should just use a different allocator API.
    >>It doesn't allocate RAM "similarly to __get_free_pages";
    >>it'd be returning something drivers can't treat as RAM.
    > Well, I don't believe it will be necessary. However, when an actual
    > user comes along, we'll find out.

    OK, I can easily view DMA_MEMORY_IO as an API experiment.

    > It is no-longer real memory once you use this API. Even if the
    > processor can treat DMA_MEMORY_MAP memory as "real", you'll probably
    > find that a device off on another bus cannot even see it. However, as
    > long as you keep the memory between the processor and the device then
    > you can treat it identical to RAM.

    I'm not sure I see what you're saying. The only guarantees on
    the memory are that "the" CPU and the device can both access
    it like memory. Other devices are out-of-scope, as is location
    (anywhere both can access it like normal memory, not just stuff
    that's "between" the two on some bus). It's DMA_MEMORY_IO that
    you said would not be RAM-like ("directly writable"), and would
    need I/O memory accessors like readl/writel/etc ... to the
    device it looks like normal RAM, but not to the host.

    > The intention of the flags option for dma_alloc_coherent() was only for
    > memory allocation instructions; the allocation can fail for other
    > reasons that unavailability of memory depending on how the API is
    > implemented, so __GFP_NOFAIL doesn't actually work now in every case.

    I personally think __GFP_WAIT is the most important one, but
    some folk have other priorities. Regardless, I _was_ talking
    about passing flags down to the memory allocator, so it sounds
    like it was just an oversight in this initial version.

    - Dave

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.045 / U:15.064 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site