On 04/26/2016 01:05 PM, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote:
>> On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote:
>>> On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote:
>>> But really the reason for per-plane is hw compos
On 04/26/2016 11:39 PM, Daniel Vetter wrote:
>> A (per-CRTC?) array of fences would be more flexible. And even in the cases
>> where you could make a 1-to-1 mapping between planes and fences, it's not
>> that much more work for userspace to assemble those fences into an array
>> anyway.
>
> I'm ok
On 03/22/2017 02:48 PM, Rob Clark wrote:
On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
Quoting Rob Clark (2017-03-22 10:07:54)
I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, whi
On Tue, Jan 5, 2016 at 12:06 AM, vijay kumar wrote:
> Hii all,
> I want to know some information regarding DRI and DRM
> support in android.Does Android uses DRI drivers in MESA for Direct
> rendering.
>
The vendor needs to supply an EGL implementation at a well-known path (
https:
On 01/15/2016 10:02 AM, Gustavo Padovan wrote:
> Patches 27 and 28 are attempt to fix that. I assumed that if some code is
> calling fence_timeline_destroy() it wants to stop everything so I
> worked on a solution that stops any waiter and allows the timeline to be
> destroyed.
>
> No one is using
On 01/15/2016 06:55 AM, Gustavo Padovan wrote:
> /**
> + * fence_timeline_create - create a new fence_timeline
> + * @num: [in]amount of contexts to allocate
[...]
> + */
> +struct fence_timeline *fence_timeline_create(unsigned num,
> + struct fenc
On 01/27/2016 12:25 PM, Gustavo Padovan wrote:
Is there a value in keeping the abi unchanged?
If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read.
>>>
>>> None from me. I'll look where we can improve the ABI.
Android has existing clients of the current ABI. Thankfull
On 01/28/16 01:23, Daniel Vetter wrote:
> And I think driver_data really shouldn't be there, it makes things
> complicated with the array of variable-sized objects, and generic
> userspace can't really use it - for debug output we already have
> obj/driver_name per fence point, which I think is goo
ay_engine,interface,device}_ops, and are similar to the
equivalent DRM ops.
Greg Hackmann (3):
video: add atomic display framework
video: adf: add display core helper
video: adf: add memblock helper
Laurent Pinchart (1):
video: Add generic display entity core
drivers/video/Kconfig
From: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/video/Kconfig| 1 +
drivers/video/Makefile | 1 +
drivers/video/display/Kconfig| 4 +
drivers/video/display/Makefile | 1 +
drivers/video/display/display-core.c | 362 +
Optional helper which implements some ADF interface ops for displays
using the Display Core framework
Signed-off-by: Greg Hackmann
---
drivers/video/adf/Kconfig | 5 ++
drivers/video/adf/Makefile | 2 +
drivers/video/adf/adf.c | 28 -
drivers/video/adf/adf.h
Provides a dma-buf exporter for memblocks, mainly useful for ADF devices
to wrap their bootloader logos
Signed-off-by: Greg Hackmann
---
drivers/video/adf/Kconfig| 5 ++
drivers/video/adf/Makefile | 2 +
drivers/video/adf/adf_memblock.c | 150
On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> wrote:
>
> > 1. The API is geared toward updating one object at a
On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> I guess if you have multiple encoders + multiple connectors for the
> "ganging" case, then it probably just looks like 2x displays, and
> nothing more really needed?
>
> I'm a bit fuzzy on what the hw looks like in this "ganging" scenario,
> so
On 12/04/2015 11:23 AM, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
> wrote:
>> Hi Rob,
>>
>> I got the same problem today with sti drm/kms driver and dumb Bo.
>> The issue comes become hwcomposer because is the master and authenticated on
>> /dev/dri/cardX
>> Dumb allo
ay_engine,interface,device}_ops, and are similar to the
equivalent DRM ops.
Greg Hackmann (3):
video: add atomic display framework
video: adf: add display core helper
video: adf: add memblock helper
Laurent Pinchart (1):
video: Add generic display entity core
drivers/video/Kconfig
Signed-off-by: Greg Hackmann
---
drivers/video/Kconfig | 1 +
drivers/video/Makefile | 1 +
drivers/video/adf/Kconfig | 5 +
drivers/video/adf/Makefile | 10 +
drivers/video/adf/adf.c| 987 +
drivers/video/adf/adf.h
From: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/video/Kconfig| 1 +
drivers/video/Makefile | 1 +
drivers/video/display/Kconfig| 4 +
drivers/video/display/Makefile | 1 +
drivers/video/display/display-core.c | 362 +
Provides a dma-buf exporter for memblocks, mainly useful for ADF devices
to wrap their bootloader logos
Signed-off-by: Greg Hackmann
---
drivers/video/adf/Kconfig| 5 ++
drivers/video/adf/Makefile | 2 +
drivers/video/adf/adf_memblock.c | 150
Optional helper which implements some ADF interface ops for displays
using the Display Core framework
Signed-off-by: Greg Hackmann
---
drivers/video/adf/Kconfig | 5 ++
drivers/video/adf/Makefile | 2 +
drivers/video/adf/adf.c | 28 -
drivers/video/adf/adf.h
On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrj?l? <
ville.syrjala at linux.intel.com> wrote:
> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> wrote:
>
> > 1. The API is geared toward updating one o
On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> I guess if you have multiple encoders + multiple connectors for the
> "ganging" case, then it probably just looks like 2x displays, and
> nothing more really needed?
>
> I'm a bit fuzzy on what the hw looks like in this "ganging" scenario,
> so
l. But to echo what I said before, I'm
OK with the ABI break here if that's what's needed to get sync moved out
of staging.
Pragmatically speaking, this won't break ordinary Android apps, because
they don't get direct access to sync fence fds to begin with. Some
privileged system processes do, but they go through libsync, which can
be changed to deal with the ABI differences.
Anyway, for the whole series:
Acked-by: Greg Hackmann
> Signed-off-by: Gustavo Padovan
Acked-by: Greg Hackmann
On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark wrote:
> > Hm, do you have some pointers to read up on this? I still think a more
> > elaborate fail scheme is overkill, but maybe reading a bit of android
> code
> > convinces me differently ;-)
>
> sadly no pointers to anything to read (but ofc would b
On Thu, Mar 20, 2014 at 5:28 PM, Rob Clark wrote:
> oh, that's right.. I'm glad you reminded me, I do remember now talk of
> a field which drivers could use to return some opaque (to drm core)
> handle/value/token/whatever..
>
> hmm, for the non-vsync'd multi-display case, does it matter much one
On Wed, Mar 26, 2014 at 3:08 AM, Daniel Vetter wrote:
>
> - You have an explicit callback for vblank events (well, just the
> interrupt, afaics no support to get a vblank event for a specific frame
> in the future). Any reason not to use android syncpoint fences for this
> like everywhere el
On Fri, Nov 13, 2015 at 1:47 PM, Rob Clark wrote:
>
> I suppose the philosophy here is
> that on android, surfaceflinger (userspace) is the trusted one (which
> may well be correct on some vendor kernel branches), whereas upstream
> the kernel is the trusted one.
>
To clarify, this wasn't the phi
On 11/23/15 11:41 AM, Gustavo Padovan wrote:
> + - remove sw_sync, it is used only for testing/debugging and should not be
> +upstreamed.
> + - port sw_sync testcases to use debugfs somehow
A quick but important nitpick:
sw_sync itself is just an in-kernel helper for creating fences, when you
do
On 11/24/2015 12:53 AM, Daniel Vetter wrote:
> With all the effort going on around kselftest it'd be good to integrate
> the existing testsuite google has into upstream too. Should probably be
> listed here too.
> -Daniel
The test code's available in AOSP:
https://android.googlesource.com/platfor
A couple of files use ffs() without explicitly including strings.h.
Some systems will pull in ffs()'s declaration through another header
anyway, but not when compiling against bionic in AOSP master.
Signed-off-by: Greg Hackmann
---
nouveau/nouveau.c | 1 +
tests/modetest/modetest.
On Tue, Apr 21, 2015 at 11:31 AM, Emil Velikov
wrote:
>
> I'm not sure why I haven't hit this while building with Android-x86's
> bionic, although it's the right thing to do.
Maybe a difference in bionic versions? I know the bionic team made
some recent (post-5.1) changes that unintentionally e
32 matches
Mail list logo
