From mboxrd@z Thu Jan 1 00:00:00 1970 From: robdclark@gmail.com (Rob Clark) Date: Mon, 10 Jun 2013 19:17:22 -0400 Subject: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver In-Reply-To: <20130610225607.GE18614@n2100.arm.linux.org.uk> References: <20130609190612.GM18614@n2100.arm.linux.org.uk> <20130610170648.GX18614@n2100.arm.linux.org.uk> <20130610200839.GY18614@n2100.arm.linux.org.uk> <20130610211516.GZ18614@n2100.arm.linux.org.uk> <20130610225607.GE18614@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Subject: Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver Date: Mon, 10 Jun 2013 19:17:22 -0400 Message-ID: References: <20130609190612.GM18614@n2100.arm.linux.org.uk> <20130610170648.GX18614@n2100.arm.linux.org.uk> <20130610200839.GY18614@n2100.arm.linux.org.uk> <20130610211516.GZ18614@n2100.arm.linux.org.uk> <20130610225607.GE18614@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by gabe.freedesktop.org (Postfix) with ESMTP id 849A6E5CF6 for ; Mon, 10 Jun 2013 16:17:22 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so12761664iea.25 for ; Mon, 10 Jun 2013 16:17:22 -0700 (PDT) In-Reply-To: <20130610225607.GE18614@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Russell King - ARM Linux Cc: Jason Cooper , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth List-Id: dri-devel@lists.freedesktop.org On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux 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.