Re: dma_addr_t: which comment is correct?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Grant Grundler wrote:
On Sat, Dec 22, 2007 at 12:15:31PM +0000, rubisher wrote:
Hello *,

Continuing my blind investigation on ccio-dma stuff, I read those 2 different comments: in include/asm-parisc/scatterlist.h, scartterlist structure is defined like this:
struct scatterlist {
#ifdef CONFIG_DEBUG_SG
        unsigned long sg_magic;
#endif
        unsigned long page_link;
        unsigned int offset;

        unsigned int length;

        /* an IOVA can be 64-bits on some PA-Risc platforms. */
        dma_addr_t iova;        /* I/O Virtual Address */
        __u32      iova_length; /* bytes mapped */
};

in absolute the comment "an IOVA can be 64-bits on some PA-Risc platforms." seems ok.

Yes, it's correct. pa8800 allows 64-bit capabale devices to bypass the IOMMU.
But I don't think we allow it yet since we would need to add code that stuffs
the Virtual Index (for DMA to be cache coherent) into the high bits of the IOVA.


but otoh, include/asm-parisc/types.h, defined dma_addr_t like this:

/* Dma addresses are 32-bits wide.  */

typedef u32 dma_addr_t;
typedef u64 dma64_addr_t;

#endif /* __ASSEMBLY__ */

Yes, this matches the current implementation.
Adding support for "bypass" on zx1 chipsets (pa8800/pa8900 CPUs) will
require something more clever.

OK it's just a comment but imho there is interesting matter in x86:

typedef u64 dma64_addr_t;
#if defined(CONFIG_X86_64) || defined(CONFIG_HIGHMEM64G)
/* DMA addresses come in 32-bit and 64-bit flavours. */
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif

But I simply have no idea which "#if defined" would be the most relevant for parisc, any idea?

u32 is correct now. u64 could be used for 64-bit builds when someone decides
we should bypass the IOMMU to improve DMA mapping/unmapping performance.

3-4 years ago I saw about 3% better performance for Storage Devices
_with_ the IOMMU enabled. IIRC, it was because of coalescing the longer
SG lists into a single IOMMU entry was more efficient for the PCI device.
Smaller, non-contiguous IOs would benefit from IOMMU bypass - e.g. NIC
workloads.

hth,
grant

Ok,

btw do you notice how much way are there (in so few lines) to use a unsigned 32bits integer: u32, __u32 but also uint32_t, u_int32_t, ...

Is there some advise om the best pratice?

Ah also related to ccio-dma patch test on my c110, it seems that removing DELAYED_RESOURCE_CNT code help a bit this system with few ram (64Mb only) to survive a bit longer (enough to debootstrap and download 800Mb to be installed) but that didn't make the drill: there are still fs corruption from time to time and some reset on the lasi disk ;-(.
This test just seems to confirm an issue of i/o coherency somewhere but where those rules could be broken???

Merry Xmas,
	r.
-
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux