Messages in this thread | | | Subject | Re: [RFC] generic device DMA implementation | Date | Thu, 05 Dec 2002 09:12:32 -0600 | From | James Bottomley <> |
| |
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/
| |