linux-kernel - Re: [RFC][PATCH 00/30] staging: Android sync driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 03 Mar 2013 10:52:43 -0800 (PST)
From:	animelovin@...il.com
To:	Daniel Vetter <daniel.vetter@...ll.ch>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 00/30] staging: Android sync driver

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

> On Fri, Mar 1, 2013 at 1:42 AM, John Stultz <john.stultz@...aro.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/