On Tue, Jul 13, 2010 at 03:03:25PM +0900, FUJITA Tomonori wrote: > On Mon, 12 Jul 2010 22:57:06 -0700 > Zach Pfeffer <zpfeffer@xxxxxxxxxxxxxx> wrote: > > > FUJITA Tomonori wrote: > > > On Thu, 08 Jul 2010 16:59:52 -0700 > > > Zach Pfeffer <zpfeffer@xxxxxxxxxxxxxx> wrote: > > > > > >> The problem I'm trying to solve boils down to this: map a set of > > >> contiguous physical buffers to an aligned IOMMU address. I need to > > >> allocate the set of physical buffers in a particular way: use 1 MB > > >> contiguous physical memory, then 64 KB, then 4 KB, etc. and I need to > > >> align the IOMMU address in a particular way. > > > > > > Sounds like the DMA API already supports what you want. > > > > > > You can set segment_boundary_mask in struct device_dma_parameters if > > > you want to align the IOMMU address. See IOMMU implementations that > > > support dma_get_seg_boundary() properly. > > > > That function takes the wrong argument in a VCM world: > > > > unsigned long dma_get_seg_boundary(struct device *dev); > > > > The boundary should be an attribute of the device side mapping, > > independent of the device. This would allow better code reuse. > > You mean that you want to specify this alignment attribute every time > you create an IOMMU mapping? Then you can set segment_boundary_mask > every time you create an IOMMU mapping. It's odd but it should work. Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to create a mapping that has the alignment I specify, regardless of the mapper. The mapping is created on a VCM and the VCM is associated with a mapper: a CPU, an IOMMU'd device or a direct mapped device. > > Another possible solution is extending struct dma_attrs. We could add > the alignment attribute to it. That may be useful, but in the current DMA-API may be seen as redundant info. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
