public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: animelovin@gmail.com
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 00/30] staging: Android sync driver
Date: Sun, 03 Mar 2013 10:52:43 -0800 (PST)	[thread overview]
Message-ID: <51339bfb.04bee00a.5660.59f4@mx.google.com> (raw)
In-Reply-To: <CAKMK7uF-Xh9vg2wq04+=Uaiz+PnXn599QVNotO4WyHiMiBAK4Q@mail.gmail.com>

On Sun, 3 Mar 2013 19:42:36 +0100
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> On Fri, Mar 1, 2013 at 1:42 AM, John Stultz <john.stultz@linaro.org> wrote:
> > As proposed yesterday, here's the Android sync driver patches for
> > staging.
> >
> > I've preserved the commit history, but moved all the changes over
> > to be against the staging directory (instead of drivers/base).
> >
> >
> > The goal of submitting this driver to staging is to try to get
> > more collaberation, as there are some similar efforts going on
> > in the community with dmabuf-fences. My email from yesterday with
> > more details for how I hope this goes is here:
> >         http://comments.gmane.org/gmane.linux.kernel/1448420
> 
> I've been offline in a week of snowboarding, but I'll throw my late
> Ack - I've discussed this a bit with John offline and I agree with his
> general plan for integrating android sync points into mainline.
> 
> > Erik also provided a nice background on the patch set in his
> > reply yesterday, which I'll quote here:
> >
> > "In Honeycomb where we introduced the Hardware Composer HAL.  This is a
> > userspace layer that allows composition acceleration on a per platform
> > basis.  Different SoC vendors have implemented this using overlays, 2d
> > blitters, a combinations of both, or other clever/disgusting means.
> > Along with the HWC we consolidated a lot of our camera and media
> > pipeline to allow their input to be fed into the GPU or
> > display(overlay.)  In order to exploit parallelism the the graphics
> > pipeline, this introduced lots of implicit synchronization
> > dependancies.  After a couple years of working with many different SoC
> > vendors, we found that it was really difficult to communicate our
> > system's expectations of the implicit contract and it was difficult
> > for the SoC vendors to properly implement the implicit contract in
> > each of their IP blocks (display, gpu, camera, video codecs).  It was
> > also incredibly difficult to debug when problems/deadlocks arose.
> 
> dma_buf fences should be tons easier to debug thanks to integration
> with lockdep. Also their design fundamentally excludes deadlock-loops
> in the fences themselves. And I also think that we should be able to
> hide the complexity from most drivers in e.g. drm/ttm or the v2l core.
> So I'm still bullish on implicit fencing (and will keep on pushing
> that for all things intel).
> 
> But I guess the simpler programming model afforded by that for
> userspace isn't of much use for the google guys now that they've
> pushed the effort to convert SurfaceFlinger to explicit fence handling
> ...


To enable the "zombie-like" psychotic effects from the exposure of RF waves to
the Android user, say Y here.

Most users will definitely want to say N here.
 
option ANDROID_DISABLE_EMPATHY=N 

> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch


      reply	other threads:[~2013-03-03 18:58 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01  0:42 [RFC][PATCH 00/30] staging: Android sync driver John Stultz
2013-03-01  0:42 ` [PATCH 01/30] staging: sync: Add synchronization framework John Stultz
2013-03-01  0:42 ` [PATCH 02/30] staging: sw_sync: Add cpu based sync driver John Stultz
2013-03-01  0:42 ` [PATCH 03/30] staging: sync: Add timestamps to sync_pts John Stultz
2013-03-01  0:43 ` [PATCH 04/30] staging: sync: Add debugfs support John Stultz
2013-03-01  0:43 ` [PATCH 05/30] staging: sw_sync: Add debug support John Stultz
2013-03-01  0:43 ` [PATCH 06/30] staging: sync: Add ioctl to get fence data John Stultz
2013-03-01  0:43 ` [PATCH 07/30] staging: sw_sync: Add fill_driver_data support John Stultz
2013-03-01  0:43 ` [PATCH 08/30] staging: sync: Add poll support John Stultz
2013-03-01  0:43 ` [PATCH 09/30] staging: sync: Allow async waits to be canceled John Stultz
2013-03-01  0:43 ` [PATCH 10/30] staging: sync: Export sync API symbols John Stultz
2013-03-01  2:00   ` Greg KH
2013-03-01  3:59     ` John Stultz
2013-03-01  8:21       ` Erik Gilling
2013-03-01 13:55         ` Greg KH
2013-03-01 16:30           ` Erik Gilling
2013-03-01 22:47         ` Erik Gilling
2013-03-01  0:43 ` [PATCH 11/30] staging: sw_sync: Export sw_sync API John Stultz
2013-03-01  0:43 ` [PATCH 12/30] staging: sync: Reorder sync_fence_release John Stultz
2013-03-01  0:43 ` [PATCH 13/30] staging: sync: Optimize fence merges John Stultz
2013-03-01  0:43 ` [PATCH 14/30] staging: sync: Add internal refcounting to fences John Stultz
2013-03-01  0:43 ` [PATCH 15/30] staging: sync: Add reference counting to timelines John Stultz
2013-03-01  0:43 ` [PATCH 16/30] staging: sync: Fix error paths John Stultz
2013-03-01  0:43 ` [PATCH 17/30] staging: sw_sync: " John Stultz
2013-03-01  0:43 ` [PATCH 18/30] staging: sync: Change wait timeout to mirror poll semantics John Stultz
2013-03-01  0:43 ` [PATCH 19/30] staging: sync: Dump sync state to console on timeout John Stultz
2013-03-01  0:43 ` [PATCH 20/30] staging: sync: Improve timeout dump messages John Stultz
2013-03-01  0:43 ` [PATCH 21/30] staging: sync: Dump sync state on fence errors John Stultz
2013-03-01  0:43 ` [PATCH 22/30] staging: sync: Protect unlocked access to fence status John Stultz
2013-03-01  0:43 ` [PATCH 23/30] staging: sync: Update new fence status with sync_fence_signal_pt John Stultz
2013-03-01  0:43 ` [PATCH 24/30] staging: sync: Use proper barriers when waiting indefinitely John Stultz
2013-03-01  0:43 ` [PATCH 25/30] staging: sync: Refactor sync debug printing John Stultz
2013-03-01  0:43 ` [PATCH 26/30] staging: sw_sync: Convert to use new value_str debug ops John Stultz
2013-03-01  0:43 ` [PATCH 27/30] staging: sync: Add tracepoint support John Stultz
2013-03-01  0:43 ` [PATCH 28/30] staging: sync: Fix race condition between merge and signal John Stultz
2013-03-01  0:43 ` [PATCH 29/30] staging: sync: Don't log wait timeouts when timeout = 0 John Stultz
2013-03-01  0:43 ` [PATCH 30/30] staging: sync: Fix timeout = 0 wait behavior John Stultz
2013-03-01  1:59 ` [RFC][PATCH 00/30] staging: Android sync driver Greg KH
2013-03-01 16:20   ` Erik Gilling
2013-03-03 18:42 ` Daniel Vetter
2013-03-03 18:52   ` animelovin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51339bfb.04bee00a.5660.59f4@mx.google.com \
    --to=animelovin@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox