From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Tue, 11 Jun 2013 00:38:09 +0100 Subject: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver In-Reply-To: References: <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: <20130610233809.GL18614@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver Date: Tue, 11 Jun 2013 00:38:09 +0100 Message-ID: <20130610233809.GL18614@n2100.arm.linux.org.uk> References: <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: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Rob Clark Cc: Jason Cooper , David Airlie , dri-devel@lists.freedesktop.org, Darren Etheridge , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth List-Id: dri-devel@lists.freedesktop.org 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 > 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?