On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> 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 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. BR, -R > There's really no point in such a driver; people might as well just > use the standard fbdev driver instead. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
