[PATCH v3 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU

[Felipe Contreras]

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
>>    enabled.
>
> 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.

-- 
Felipe Contreras