lkml.org 
[lkml]   [2013]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 00/30] staging: Android sync driver
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



\
 
 \ /
  Last update: 2013-03-03 20:21    [W:0.116 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site