On Sun, 3 Mar 2013 19:42:36 +0100 Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> On Fri, Mar 1, 2013 at 1:42 AM, John Stultz <john.stu...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
