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.
There's really no point in such a driver; people might as well just use the standard fbdev driver instead.