From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932340AbbDHOkZ (ORCPT ); Wed, 8 Apr 2015 10:40:25 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:38022 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932313AbbDHOkD (ORCPT ); Wed, 8 Apr 2015 10:40:03 -0400 Message-ID: <6f5bcdfa44daaf8fc78ea3510963094a.squirrel@www.codeaurora.org> In-Reply-To: <20150408080707.GN6354@phenom.ffwll.local> References: <1427922770-13721-1-git-send-email-jilaiw@codeaurora.org> <20150407055949.GI6354@phenom.ffwll.local> <93d3802305fa348738dae7f458c3fb56.squirrel@www.codeaurora.org> <20150408080707.GN6354@phenom.ffwll.local> Date: Wed, 8 Apr 2015 14:40:01 -0000 Subject: Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support From: jilaiw@codeaurora.org To: jilaiw@codeaurora.org, "Rob Clark" , "linux-arm-msm" , "Linux Kernel Mailing List" , "dri-devel@lists.freedesktop.org" User-Agent: SquirrelMail/1.4.22-4.el6 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Priority: 3 (Normal) Importance: Normal Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Tue, Apr 07, 2015 at 03:55:45PM -0000, jilaiw@codeaurora.org wrote: >> > On Thu, Apr 02, 2015 at 10:29:52AM -0400, Rob Clark wrote: >> >> So, from a quick look, it seems like there is a lot of potential to >> >> split the v4l part out into some drm helpers.. it looks pretty >> >> generic(ish), or at least it could be with some strategically placed >> >> vfuncs in drm_v4l2_helper_funcs. >> >> >> >> I do think we need to figure out the auth/security situation. We >> >> probably don't want to let arbitrary processes open a v4l device and >> >> snoop on the screen contents. We perhaps could re-use the dri2 drm >> >> auth stuff (v4l2_drm_get_magic ioctl?). Or, well, it would be nice >> if >> >> the wb device could be made to not exist in /dev at all, and >> >> pre-open'd fd returned from an ioctl on the drm device, but not >> really >> >> sure if that is possible (or too weird). Once the compositor process >> >> has the v4l device open and authenticated somehow, I expect it would >> >> use fd passing to pass the fd off to a trusted helper process. >> > >> > Please don't resurrect the magic stuff ;-) >> > >> > Anyway I discussed this a bit with Laurent and we figured the best way >> to >> > wire up writeback support is by using drm framebuffers. Then you can >> use >> > atomic flips to create a new snapshot. Of course that won't work with >> hw >> > where writeback is continuous, there v4l is a much better fit. And we >> also >> > have hardware where some v4l pipeline could directly feed into a drm >> > output pipeline, so we need a generic way to connect v4l and drm >> anyway. >> > For that I think we should add a new flag to addfb2 (or a new >> addfbv4l) >> > which creates a magic framebuffer from a v4l input/output. Some values >> > like stride don't make sense in such a virtual framebuffer, but pixel >> > format and size are all needed. >> > >> > This way we don't need parallel abis for single-shot writeback >> directly >> > into framebuffers and for continuous writeback through v4l, we can >> reuse >> > the same drm framebuffer ones. And this also solves the security >> issues >> > since no one can start writeback without the drm device owner's >> consent, >> > so no need to reinvent anything there. And with atomic we already have >> > almost everything there: For the writeback framebuffer we only need a >> new >> > "WRITEBACK" property (which takes an fb id) and the small extension to >> > create v4l-backed framebuffers. >> > >> > Cheers, Daniel >> > -- >> > Daniel Vetter >> > Software Engineer, Intel Corporation >> > http://blog.ffwll.ch >> > >> Hi Daniel, >> >> 1. This change is to implement a continuous writeback. >> 2. As you said, we need "a generic way to connect v4l and drm". >> Especially how to share the buffer information between v4l and drm for >> writeback output. >> >> Below are just some details of this change: >> >> In current implementation, I expect the output buffer is dma buffer >> which could be from GEM object (drm) or from video encoder (V4l). Once >> the buffer is queued into V4l driver, it will be converted into a GEM >> object and then pass it to drm as writeback output buffer. Once the >> buffer is captured, it will notify V4l driver to let user dequeue >> buffer. >> >> Drm will notice there is a Virtual Connector (maybe a new type WRITEBACK >> can be added), but it will only be "connected" until V4l >> starts streaming. > > Yes we definitely should add a new connector type WRITEBACK. And just the > connector kinda works for your hw design where writeback works like a > separate encoder. But there's also hw out there where any crtc can be > written back, and for those cases we need explicit properties. Then > there's also the one-shot vs. continuous issues. yes, this change is specific for msm chip. In order to cover the other writeback use cases, new properties and framework changes are required. > > Given all that I still think you want an explicit drm framebuffer to > connect the kms and the v4l side of things. That would also help a bit > with making it clear which v4l connects to which drm device. yes, it will help. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch >