lkml.org 
[lkml]   [2002]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] generic device DMA implementation
    Date
    From
    benh@kernel.crashing.org said:
    > actually, the device model defines a bus "type" structure rather than a
    > "bus instance" structure (well, at least it did last I looked a couple
    > of weeks ago). That's a problem I beleive here, as those functions are
    > really a property of a given bus instance. One solution would
    > eventually be to have the set of functions pointers in the generic
    > struct device and by default be copied from parent to child.

    Well, the bus in the generic device model is just a struct device as well.

    The parisc implementation I'm working on stores this type of conversion
    information in the platform_data field of the generic device (although the
    function pointers that make use of it are global).

    I did do an implementation which added a dma_accessors set of functions to the
    struct device (and also struct bus_type), but I eventually concluded they had
    to be so platform specific that there was no utility to exposing them.

    > Consistency of memory (or simply, in some cases, accessibility of
    > system memory by a given device) is really a property of the bus.
    > Tweaking magic bits in dma_addr_t and testing them later is a hack.
    > The proper implementation is to have the consistent_{alloc,free,map,unm
    > ap,sync,...) functions be function pointers in the generic bus
    > structure.

    actually, in parisc, the implementation is simple. The type of memory is
    determined globally per architecture (so it's not encoded in the dma_addr_t).
    As Adam said. The preferred platform implementation for a machine that did
    both (I believe this is the fabled parisc V class, which I've never seen)
    would be to implement a consistent region so you could tell if dma_addr_t fell
    in that region for whether it was consistent or not.

    I fully recognise that dma_addr_t actually has to be freely convertable to the
    physical address by simple casting, because that's the way the pci_ functions
    use it.

    James


    -
    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:31    [W:3.005 / U:0.212 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site