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

[Russell King - ARM Linux]

On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> >> I guess in the short term, the best I can think is keep those phys
> >> ioctls as a small patch on top of the upstream driver.  It is ok to
> >> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> >> #'s don't shift when you rebase.  And then try to get the vendor to
> >> add support for dmabuf so that the patch on top of upstream can
> >> eventually be dropped.  Maybe someone else has a better suggestion,
> >> but I don't think we can merge those phys ioctls upstream, and I'd
> >> really hate to 'throw the baby out with the bathwater' in this case
> >> and not at least get the modesetting part of the driver merged.
> >
> > What you're saying is basically:
> >
> > 1. Throw out DRM_ARMADA_GEM_CREATE_PHYS, which cripples video playback
> >    on existing gstreamer, xbmc and other implementations without someone
> >    rewriting all that code.
> >
> > 2. Throw out DRM_ARMADA_GEM_PROP, which prevents any form of passing
> >    the GEM objects to the GPU libraries in userspace, thereby preventing
> >    any kind of GPU based acceleration.
> >
> > 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

Which bit of "THIS DRIVER DOESN'T DMA _TO_ ANY ADDRESS" did you not yet?