Message-ID: <77170715-30fd-32ff-f738-cea630fd702f@redhat.com>
Date:   Mon, 6 Mar 2017 11:14:48 -0800
From:   Laura Abbott <labbott@...hat.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        dri-devel@...ts.freedesktop.org,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Riley Andrews <riandrews@...roid.com>, arve@...roid.com,
        devel@...verdev.osuosl.org, romlem@...gle.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linaro-mm-sig@...ts.linaro.org,
        linux-mm@...ck.org, Mark Brown <broonie@...nel.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org
Subject: Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

On 03/06/2017 07:52 AM, Daniel Vetter wrote:
> On Mon, Mar 06, 2017 at 03:43:53PM +0200, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote:
>>> On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote:
>>>> On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
>>>>> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
>>>>>> When CMA was first introduced, its primary use was for DMA allocation
>>>>>> and the only way to get CMA memory was to call dma_alloc_coherent. This
>>>>>> put Ion in an awkward position since there was no device structure
>>>>>> readily available and setting one up messed up the coherency model.
>>>>>> These days, CMA can be allocated directly from the APIs. Switch to
>>>>>> using this model to avoid needing a dummy device. This also avoids
>>>>>> awkward caching questions.
>>>>>
>>>>> If the DMA mapping API isn't suitable for today's requirements anymore,
>>>>> I believe that's what needs to be fixed, instead of working around the
>>>>> problem by introducing another use-case-specific API.
>>>>
>>>> I don't think this is a usecase specific API. CMA has been decoupled from
>>>> DMA already because it's used in other places. The trying to go through
>>>> DMA was just another layer of abstraction, especially since there isn't
>>>> a device available for allocation.
>>>
>>> Also, we've had separation of allocation and dma-mapping since forever,
>>> that's how it works almost everywhere. Not exactly sure why/how arm-soc
>>> ecosystem ended up focused so much on dma_alloc_coherent.
>>
>> I believe because that was the easy way to specify memory constraints. The API 
>> receives a device pointer and will allocate memory suitable for DMA for that 
>> device. The fact that it maps it to the device is a side-effect in my opinion.
>>

Agreed. The device Ion wanted to use was never a real device though
so any constraints it satisfied were making assumptions about what
memory would be allocated.


>>> I think separating allocation from dma mapping/coherency is perfectly
>>> fine, and the way to go.
>>
>> Especially given that in many cases we'll want to share buffers between 
>> multiple devices, so we'll need to map them multiple times.
>>
>> My point still stands though, if we want to move towards a model where 
>> allocation and mapping are decoupled, we need an allocation function that 
>> takes constraints (possibly implemented with two layers, a constraint 
>> resolution layer on top of a pool/heap/type/foo-based allocator), and a 
>> mapping API. IOMMU handling being integrated in the DMA mapping API we're 
>> currently stuck with it, which might call for brushing up that API.
> 
> Hm, maybe I wasn't clear, but that's exactly what I assume will happen:
> 
> The constraint resolver is the unix device memory allocation thing, which
> happens entirely in userspace. There's a lot more than just "where to
> allocate" to negotiate, e.g. pixel format, stride/size
> limits/requirements, tiling formats. A lot of it the kernel doesn't even
> know.
> 
> Allocation then needs to happen through the kernel ofc, but that doesn't
> mean we need to have all the constraint resolving in the kernel. As long
> as the kernel exposes the device /dev node -> ion heap stuff, userspace
> can figure this out. Or an alternative way would be to have a cascade of
> ion heaps to keep things a notch more opaque. Either way, no actaul
> constraint resolving in the kernel itself, and except for a bunch more
> stuff in sysfs maybe, also no other uapi changes. Once we have a place to
> allocate stuff which isn't the device driver at least, aka ION.
> 
> And then once allocated you use the dma apis to instantiate the iommus
> mappings.
> 
> Anyway, at least from my understanding I think there's 0 risk with merging
> ION wrt the constraint resolving side (at least as discussed around XDC
> last year), and for setups that need cma, it might finally enable to get
> things moving forward.
> 
> Or do I miss something big here?
> -Daniel
> 

This all sounds like what I was thinking. I think some of the concerns
may be that the details of constraint solving are mostly handwaving
right now.

Thanks,
Laura

Powered by blists - more mailing lists