[PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie <airlied at gmail.com> wrote:
>>>
>>> That makes the driver just be a dumb scanout only driver.  Sorry,
>>> that *really* does not interest me one bit, because the CPU doing
>>> framebuffer accesses is pig slow.
>>
>> Well, yes that is basically what I am saying, unless we can find a
>> different way (dmabuf? if there is some way to pass it through the
>> blob bits you don't have src code for?)
>>
>> The problem is that we really can't merge something upstream that lets
>> you dma to arbitrary physical address.  Maybe in staging, perhaps?  Or
>> otherwise if there is no other way, I hope someone will at least pick
>> up the modesetting parts of it and get that merged upstream.  The rest
>> of the driver is looking pretty good, and I think it would be useful
>> to have upstream.
>
> Totally what he said.
>
> upstream shouldn't be restricted by the bad decisions of others, and
> adding security bypasses is one of them.
>
> I'd like to see all the ARM based drivers based on CMA if it can meet
> their requirements

afaiu CMA has issues w/ changing cache attributes of pages on older
architectures like Russell is using.  Although perhaps on older arm
CMA should just be a straight carveout pool and not try to recycle the
unused pages.  At least then it would be the same API for the drivers.

BR,
-R

> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> come an unmaintainable
> nightmare for everyone, but mostly for me.
>
> Merging the base dumb KMS driver, then working out acceptable ways to
> provide the extra
> features is definitely the nicest way to do things.
>
> Dave.