[PATCH v3 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
felipe.contreras at gmail.com
Fri Jun 3 05:39:27 EDT 2011
On Fri, Jun 3, 2011 at 3:12 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> Hi Russell,
> On Wednesday 01 June 2011 16:03:06 Russell King - ARM Linux wrote:
>> On Wed, Jun 01, 2011 at 03:50:50PM +0200, Laurent Pinchart wrote:
>> > In the specific iovmm case, the driver uses the sglist API to build a
>> > list of page-size sg entries, and then process it in software. Is that
>> > considered as an abuse of the sglist API, or valid usage ?
>> > Anyway, sglist chaining is not needed by iovmm. As iovmm just walks the
>> > sglist manually, it's easier to allocate it in one go rather than using
>> > sglist chaining. This of course doesn't make your patch unneeded or
>> > wrong.
>> Well, there's a two issues here:
>> 1. Should iovmm use sg_phys(sg) with sg_dma_len(sg) ?
>> Probably not, because a scatterlist before DMA API mapping is defined
>> by sg_page(sg), sg->offset, sg->length and has N entries. After DMA
>> API mapping (n = dma_map_sg(dev, sg, N, dir)), it has n entries where
>> n <= N, and the DMA address/lengths are sg_dma_address(sg) and
>> sg_dma_len(sg). Both these are undefined for unmapped scatterlists.
>> Getting this wrong means breakage when CONFIG_NEED_SG_DMA_LENGTH is
> iovmm abuses the sglist API, there's no doubt on that. It will break when
> CONFIG_NEED_SG_DMA_LENGTH is enabled. iovmm should probably not use the sglist
> API, and it should probably not even exist in the first place. I know that TI
> is working on moving the OMAP-specific iommu/iovmm implementation to the
> generic IOMMU API, but that will take time. In the meantime, I'd like to fix
> iovmm to avoid the userspace-triggerable BUG_ON().
This would also allow the tidspbridge driver to use iommu.
More information about the linux-arm-kernel