On Mon, Jun 10, 2013 at 7:38 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > 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@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 > > Which bit of "THIS DRIVER DOESN'T DMA _TO_ ANY ADDRESS" did you not yet? ok, I see the 'put_image' ioctl is a non-destructive overlay (ie. not a blit to memory). In which case it is limited to letting you just scan out arbitrary memory. Which is still not awesome, but not nearly as bad. And fwiw, CMA is not a blocker point for me. Although it seems like a good idea into trying to talk someone into making CMA do something sane on older arm's so that at some point armada driver can use it. You probably can't use the drm cma helpers (since that wouldn't let you do cached buffers), so the change to use dma_alloc_* from your driver at a later date would be pretty small. Fwiw, omapdrm and I think also exynos both use CMA for some buffers (for example, omap3 or anything without dmm/tiler would use cma for scanout buffers). BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
