From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC] drm: add flip-work helper Date: Mon, 5 Aug 2013 10:00:31 +0200 Message-ID: <20130805080031.GC22035@phenom.ffwll.local> References: <1375313000-10672-1-git-send-email-robdclark@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by gabe.freedesktop.org (Postfix) with ESMTP id 2F59AE66CB for ; Mon, 5 Aug 2013 01:00:25 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so2108855wgg.28 for ; Mon, 05 Aug 2013 01:00:24 -0700 (PDT) Content-Disposition: inline In-Reply-To: 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: Rob Clark Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org On Sun, Aug 04, 2013 at 10:20:54PM -0400, Rob Clark wrote: > On Sun, Aug 4, 2013 at 1:34 PM, Daniel Vetter wrote: > > On Thu, Aug 1, 2013 at 1:23 AM, Rob Clark wrote: > >> A small helper to queue up work to do, from workqueue context, after a > >> flip. Typically useful to defer unreffing buffers that may be read by > >> the display controller until vblank. > >> > >> Signed-off-by: Rob Clark > >> --- > >> I've re-inventing the same wheel three times in as many drivers (omapdrm, > >> tilcdc, and in upcoming msm driver I need two of 'em). I guess it is > >> time to helper-up. > >> > >> I'll update omapdrm and tilcdc to use this as well, but I figured I'd > >> send an RFC first in case anyone wants to get their bikeshed on. If > >> there are other drivers that could use this, and are straightforward > >> to convert over, let me know and I can update them as well. > > > > > > One thing drm/i915 needs is to be able to flush the workqueue (to make > > sure we don't pile up giant amounts of buffers waiting to be unpinned > > and so temporarily leak a bit of memory). So some way to synchronously > > flush out flip functions would be required (and make sure all that > > have been queued up to that point are really completed). But at that > > point a separate workqueue sounds simpler, so I wonder a bit what this > > gains us? At roughly 50Hz flip work functions aren't really that > > performance critical imo ... > > you could of course do separate or same workqueue from your main > render-complete workqueue, or flush the workqueue at whatever point > you want.. I suppose if you are queuing from a context that is safe > to sleep you could have a blocking-queue function. I haven't really > needed anything like that so far, but feel free to extend the > flip-work helper however you need to be useful for i915. (Or point me > at the bits in i915 that do something similar and I'll have a think > about how to convert that) queue_work in do_intel_finish_page_flip and flush_work in intel_crtc_page_flip is the relevant code. The former is called from irq context. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch