Re: [PATCH] reservation: don't wait when timeout=0

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > Quoting Rob Clark (2017-11-21 14:08:46) >> If we are testing if a reservation object's fences have been >> signaled with timeout=0 (non-blocking), we need to pass 0 for >> timeou

[PATCH] reservation: don't wait when timeout=0

If we are testing if a reservation object's fences have been signaled with timeout=0 (non-blocking), we need to pass 0 for timeout to dma_fence_wait_timeout(). Plus bonus spelling correction. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/dma-buf/reservation.c | 11

Re: DRM Format Modifiers in v4l2

On Fri, Sep 1, 2017 at 3:13 AM, Laurent Pinchart wrote: > Hi Nicolas, > > On Thursday, 31 August 2017 19:12:58 EEST Nicolas Dufresne wrote: >> Le jeudi 31 août 2017 à 17:28 +0300, Laurent Pinchart a écrit : >> >> e.g. if I have two devices which support

Re: [PATCH] media: venus: hfi: fix error handling in hfi_sys_init_done()

On Sun, Jul 9, 2017 at 3:49 PM, Stanimir Varbanov <stanimir.varba...@linaro.org> wrote: > Hi Rob, > > On 07/09/2017 04:19 PM, Rob Clark wrote: >> Not entirely sure what triggers it, but with venus build as kernel >> module and in initrd, we hit this crash: >

[PATCH] media: venus: hfi: fix error handling in hfi_sys_init_done()

just bailing seems like a reasonable solution. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/media/platform/qcom/venus/hfi_msgs.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c b/drivers/media/platfor

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

On Mon, Mar 13, 2017 at 5:09 PM, Laura Abbott wrote: >> Hm, we might want to expose all the heaps as individual >> /dev/ion_$heapname nodes? Should we do this from the start, since >> we're massively revamping the uapi anyway (imo not needed, current >> state seems to work

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

On Fri, Mar 10, 2017 at 7:40 AM, Daniel Vetter wrote: > On Fri, Mar 10, 2017 at 10:31:13AM +, Brian Starkey wrote: >> Hi, >> >> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote: >> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >> >> [snip] >> >> > > >> > >

Re: [RFC 0/6] Module for tracking/accounting shared memory buffers

On Tue, Oct 11, 2016 at 7:50 PM, Ruchi Kandoi wrote: > This patchstack introduces a new "memtrack" module for tracking and accounting > memory exported to userspace as shared buffers, like dma-buf fds or GEM > handles. btw, I wouldn't care much about the non-dmabuf

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

how do you know which devices are concerned when listing the constraints ? > Does combine_capabilities is done from each allocation or can it be cached ? > > Regards, > Benjmain > > 2016-10-06 18:54 GMT+02:00 Rob Clark <robdcl...@gmail.com>: >> so there is discussion ab

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

so there is discussion about a "central userspace allocator" (ie. more like a common userspace API that could be implemented on top of various devices/APIs) to decide in a generic way which device could allocate. https://github.com/cubanismo/allocator and I wrote up some rough

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

gt;> which drm_fourcc.h formats EGL supports or if just failing with >> EGL_BAD_MATCH when the >> application >> has use one EGL doesn't support is sufficient. Any thoughts? >> >> >> Cheers, >> >> Tom >> >> >> 8<--

Re: DRM device memory writeback (Mali-DP)

On Mon, Jul 18, 2016 at 11:01 AM, Daniel Vetter wrote: > On Mon, Jul 18, 2016 at 12:47:38PM +0200, Hans Verkuil wrote: >> On 07/18/2016 12:29 PM, Brian Starkey wrote: >> > OK, so let's talk about using connectors instead then :-) >> > >> > We can attach a generic fixed_mode

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 17 Jun 2016 11:44:34 -0400 > Rob Clark <robdcl...@gmail.com> wrote: > >> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: >> > On Fri,

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 17 Jun 2016 08:26:04 -0400 > Rob Clark <robdcl...@gmail.com> wrote: > >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: >> > On Thu,

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Thu, 16 Jun 2016 10:40:51 -0400 > Rob Clark <robdcl...@gmail.com> wrote: > >> So, if we wanted to extend this to support the fourcc-modifiers that >> we have on the kernel side for c

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

the >> application >> has use one EGL doesn't support is sufficient. Any thoughts? >> >> >> Cheers, >> >> Tom >> >> >> 8< >> >> >> Name >> >> EXT_image

Re: gstreamer: v4l2videodec plugin

On Thu, Apr 28, 2016 at 7:33 AM, Stanimir Varbanov <stanimir.varba...@linaro.org> wrote: > On 04/15/2016 07:09 PM, Nicolas Dufresne wrote: >> Le vendredi 15 avril 2016 à 11:58 -0400, Rob Clark a écrit : >>> The issue is probably the YUV format, which we cannot really de

Re: gstreamer: v4l2videodec plugin

On Fri, Apr 15, 2016 at 12:09 PM, Nicolas Dufresne <nico...@ndufresne.ca> wrote: > Le vendredi 15 avril 2016 à 11:58 -0400, Rob Clark a écrit : >> The issue is probably the YUV format, which we cannot really deal >> with >> properly in gallium.. it's a similar

Re: gstreamer: v4l2videodec plugin

On Tue, Apr 12, 2016 at 4:57 AM, Stanimir Varbanov wrote: > Hi Nicolas, > > On 04/11/2016 07:25 PM, Nicolas Dufresne wrote: >> Le lundi 11 avril 2016 à 15:11 +0300, Stanimir Varbanov a écrit : >>> adding gstreamer-devel >>> >>> On 04/11/2016 03:03 PM, Stanimir

Re: [RFC] How implement Secure Data Path ?

On Wed, May 6, 2015 at 4:35 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, May 05, 2015 at 05:54:05PM +0100, One Thousand Gnomes wrote: First what is Secure Data Path ? SDP is a set of hardware features to garanty that some memories regions could only be read and/or write by specific

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

attached devices for the 'paranoid' ones amongst us. The idea of this patch is largely taken from Rob Clark's RFC at https://lkml.org/lkml/2012/7/19/285, and the comments received on it. Cc: Rob Clark robdcl...@gmail.com Signed-off-by: Sumit Semwal sumit.sem...@linaro.org The code looks okay

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Wed, Feb 11, 2015 at 7:56 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Feb 11, 2015 at 06:23:52AM -0500, Rob Clark wrote: On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: As I've already pointed out, there's a major problem if you have already

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Tue, Feb 3, 2015 at 9:37 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote: Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to drop use of dma-mapping entirely (incl the current call to dma_map_sg, which I

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Tue, Feb 3, 2015 at 9:41 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote: On Tuesday 03 February 2015 09:04:03 Rob Clark wrote: Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to drop use of dma

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Tue, Feb 3, 2015 at 9:52 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote: On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote: On Tuesday 03 February 2015 09:04:03 Rob Clark wrote: Since I'm stuck w/ an iommu, instead

Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann a...@arndb.de wrote: I agree for the case you are describing here. From what I understood from Rob was that he is looking at something more like: Fig 3 CPU--L1cache--L2cache--Memory--IOMMU---iobus--device where the IOMMU controls one or more

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Tue, Feb 3, 2015 at 7:28 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote: On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Tue, Feb 3, 2015 at 2:48 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial thought is for dma-buf to not try to prevent something than an exporter can

Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Tue, Feb 3, 2015 at 11:58 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Okay, but switching contexts is not something which the DMA API has any knowledge of (so it can't know which context to associate with which mapping.) While it knows which device, it has no knowledge (nor

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial thought is for dma-buf to not try to prevent something than an exporter can actually do.. I think the scenario you describe could be handled by two sg-lists, if the exporter was clever enough. That's already

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Mon, Feb 2, 2015 at 4:46 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial thought is for dma-buf to not try to prevent something than

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Thu, Jan 29, 2015 at 10:47 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote: So, short answer is, it is left to the exporter to decide. The dma-buf framework should not even attempt to decide or enforce any of the above.

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote: Quite possibly for some of these edge some of cases, some of the dma-buf exporters are going to need to get more clever (ie. hand off different

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Thu, Jan 29, 2015 at 5:31 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote: On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Now, if we're going to do the more clever thing you

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

for asynchronous dma access + * + * Copyright (C) 2012 Canonical Ltd + * Copyright (C) 2012 Texas Instruments + * + * Authors: + * Rob Clark robdcl...@gmail.com + * Maarten Lankhorst maarten.lankho...@canonical.com + * + * This program is free software; you can redistribute it and/or modify it + * under

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 1:00 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: On Wed, Jun 18, 2014 at 9:13 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote: +#define

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 2:19 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote: On Thu, Jun 19, 2014 at 1:00 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: On Wed, Jun 18, 2014

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Thu, Jun 19, 2014 at 5:50 PM, Dave Airlie airl...@gmail.com wrote: On 20 June 2014 04:19, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote: On Thu, Jun 19, 2014 at 1:00 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jun 19, 2014

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

: + * Rob Clark robdcl...@gmail.com + * Maarten Lankhorst maarten.lankho...@canonical.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

. Explicitly include linux/atomic.h. v16: Add trace events. Import changes required by android syncpoints. v17: Use wake_up_state instead of try_to_wake_up. (Colin Cross) Fix up commit description for seqno_fence. (Rob Clark) Signed-off-by: Maarten Lankhorst

Re: [PATCH 6/6] dma-buf: add poll support, v2

-by: Rob Clark robdcl...@gmail.com + dma_buf_poll_cb(NULL, dcb-cb); + } + } + + if ((events POLLOUT) resv-fence_shared_count 0) { + struct dma_buf_poll_cb_t *dcb = dmabuf-cb_shared; + int i

Re: [PATCH 3/6] dma-buf: use reservation objects

can have a common get_prime_res_obj fxn for everyone using GEM? Anyways, that only matters within drivers/gpu/drm so easy enough to change it later.. so for the drm/fence/reservation/dmabuf bits: Reviewed-by: Rob Clark robdcl...@gmail.com + + return dma_buf_export(obj

Re: [PATCH 5/6] reservation: add support for fences to enable cross-device synchronisation

On Mon, Feb 17, 2014 at 10:58 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Reviewed-by: Rob Clark robdcl...@gmail.com --- include/linux/reservation.h | 18 +- 1 file changed, 17 insertions

Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)

the original patch by Rob Clark. v1: Original v2: Renamed from bikeshed to seqno, moved into dma-fence.c since not much was left of the file. Lots of documentation added. v3: Use fence_ops instead of custom callbacks. Moved to own file to avoid circular dependency between dma-buf.h

Re: [PATCH 1/6] fence: dma-buf cross-device synchronization (v17)

: Add trace events. Import changes required by android syncpoints. v17: Use wake_up_state instead of try_to_wake_up. (Colin Cross) Fix up commit description for seqno_fence. (Rob Clark) Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Reviewed-by: Rob Clark robdcl

Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)

that doesn't support this mechanism. It is useful to expose this for graphics cards that have an op to support this. Some cards like i915 can export those, but don't have an option to wait, so they need the software fallback. I extended the original patch by Rob Clark. v1: Original v2: Renamed

Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)

On Mon, Feb 17, 2014 at 12:36 PM, Christian König deathsim...@vodafone.de wrote: Am 17.02.2014 18:27, schrieb Rob Clark: On Mon, Feb 17, 2014 at 11:56 AM, Christian König deathsim...@vodafone.de wrote: Am 17.02.2014 16:56, schrieb Maarten Lankhorst: This type of fence can be used

Re: [PATCH] dma-buf: avoid using IS_ERR_OR_NULL

that. But either way: Reviewed-by: Rob Clark robdcl...@gmail.com + ptr = NULL; + if (!ptr) goto out_unlock; dmabuf-vmap_ptr = ptr; diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 56805c39c906..bb516fdd195d 100644

Re: [RFC PATCH] fence: dma-buf cross-device synchronization (v12)

On Thu, Aug 15, 2013 at 7:16 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Op 12-08-13 17:43, Rob Clark schreef: On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: + [snip] +/** + * fence_add_callback - add a callback to be called when

Re: [RFC PATCH] fence: dma-buf cross-device synchronization (v12)

/most of the earlier versions of this too) Reviewed-by: Rob Clark robdcl...@gmail.com --- Documentation/DocBook/device-drivers.tmpl |2 drivers/base/Kconfig | 10 + drivers/base/Makefile |2 drivers/base/fence.c | 286

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey tom.cook...@arm.com wrote: Turning to DRM/KMS, it seems the supported formats of a plane can be queried using drm_mode_get_plane. However, there doesn't seem to be a way to query the supported formats of a crtc? If display HW only supports

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Wed, Aug 7, 2013 at 12:23 AM, John Stultz john.stu...@linaro.org wrote: On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark robdcl...@gmail.com wrote: well, let's divide things up into two categories: 1) the arrangement and format of pixels.. ie. what userspace would need to know if it mmap's

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey tom.cook...@arm.com wrote: Didn't you say that programmatically describing device placement constraints was an unbounded problem? I guess we would have to accept that it's not possible to describe all possible constraints and instead find a

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey tom.cook...@arm.com wrote: So in some respects, there is a constraint on how buffers which will be drawn to using the GPU are allocated. I don't really like the idea of teaching the display controller DRM driver about the GPU buffer constraints,

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach l.st...@pengutronix.de wrote: Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey: Hi Rob, +lkml On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com wrote: * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Tue, Aug 6, 2013 at 10:03 AM, Tom Cooksey tom.cook...@arm.com wrote: Hi Rob, We may also then have additional constraints when sharing buffers between the display HW and video decode or even camera ISP HW. Programmatically describing buffer allocation constraints is very difficult

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Tue, Aug 6, 2013 at 10:36 AM, Lucas Stach l.st...@pengutronix.de wrote: Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark: On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach l.st...@pengutronix.de wrote: Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey: Hi Rob, +lkml

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Tue, Aug 6, 2013 at 1:38 PM, Tom Cooksey tom.cook...@arm.com wrote: ... This is the purpose of the attach step, so you know all the devices involved in sharing up front before allocating the backing pages. (Or in the worst case, if you have a late attacher you at least know when no

Re: [PATCH V2] drm/exynos: Add fallback option to get non physically continous memory for fb

allocation fails. Reviewed-by: Rob Clark robdcl...@gmail.com Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org Signed-off-by: Arun Kumar arun...@samsung.com --- changes since v1: - Modified to add the fallback patch if CONTIG alloc fails as suggested by Rob Clark robdcl

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey tom.cook...@arm.com wrote: Hi Rob, +linux-media, +linaro-mm-sig for discussion of video/camera buffer constraints... On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com wrote: * It abuses flags parameter of

Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Vikas, On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote: While trying to get boot-logo up on exynos5420 SMDK which has eDP panel connected with resolution 2560x1600, following error occured even with IOMMU

Re: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework

On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae daei...@gmail.com wrote: that should be the role of kernel memory management which of course needs synchronization btw A and B. But in no case this should be done using dma-buf. dma-buf is for sharing content btw different devices not sharing

Re: Introduce a new helper framework for buffer synchronization

On Mon, May 27, 2013 at 11:56 PM, Inki Dae inki@samsung.com wrote: -Original Message- From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev- ow...@vger.kernel.org] On Behalf Of Rob Clark Sent: Tuesday, May 28, 2013 12:48 AM To: Inki Dae Cc: Maarten Lankhorst; Daniel

Re: Introduce a new helper framework for buffer synchronization

On Mon, May 27, 2013 at 6:38 AM, Inki Dae inki@samsung.com wrote: Hi all, I have been removed previous branch and added new one with more cleanup. This time, the fence helper doesn't include user side interfaces and cache operation relevant codes anymore because not only we are not sure

Re: Introduce a new helper framework for buffer synchronization

On Wed, May 15, 2013 at 1:19 AM, Inki Dae inki@samsung.com wrote: -Original Message- From: Rob Clark [mailto:robdcl...@gmail.com] Sent: Tuesday, May 14, 2013 10:39 PM To: Inki Dae Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun Cho; linux-arm-ker

Re: Introduce a new helper framework for buffer synchronization

On Mon, May 13, 2013 at 10:52 PM, Inki Dae inki@samsung.com wrote: well, for cache management, I think it is a better idea.. I didn't really catch that this was the motivation from the initial patch, but maybe I read it too quickly. But cache can be decoupled from synchronization, because

Re: Introduce a new helper framework for buffer synchronization

On Mon, May 13, 2013 at 8:21 AM, Inki Dae inki@samsung.com wrote: In that case you still wouldn't give userspace control over the fences. I don't see any way that can end well. What if userspace never signals? What if userspace gets killed by oom killer. Who keeps track of that? In all

Re: Introduce a new helper framework for buffer synchronization

On Mon, May 13, 2013 at 1:18 PM, Inki Dae inki@samsung.com wrote: 2013/5/13 Rob Clark robdcl...@gmail.com On Mon, May 13, 2013 at 8:21 AM, Inki Dae inki@samsung.com wrote: In that case you still wouldn't give userspace control over the fences. I don't see any way that can end

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

an mmap interface in the dma_buf thing for that, and iirc Rob Clark even bothered to implement the gem-dma_buf mmap forwarding somewhere. And iirc android's ion-on-dma_buf stuff is even using the mmap interface stuff. fwiw, what I did was dma_buf - gem mmap fwding, ie. implement mmap for the dmabuf

Re: [RFC v2 0/5] Common Display Framework

On Fri, Feb 1, 2013 at 5:42 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Rahul, On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote: Hi Laurent, CDF will also be helpful in supporting Panels with integrated audio (HDMI/DP) if we can add audio related control

Re: [PATCH 2/7] mutex: add support for reservation style locks

On Wed, Jan 30, 2013 at 5:52 AM, Rob Clark robdcl...@gmail.com wrote: On Wed, Jan 30, 2013 at 5:08 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark robdcl...@gmail.com wrote: == Basic problem statement: - --- - GPU's

Re: [PATCH 2/7] mutex: add support for reservation style locks

On Wed, Jan 30, 2013 at 5:08 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark robdcl...@gmail.com wrote: == Basic problem statement: - --- - GPU's do operations that commonly involve many buffers. Those buffers can

Re: [PATCH 2/7] mutex: add support for reservation style locks

On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Hi Maarten, This is a nice looking extension to avoid re-implementing a mutex in TTM/reservation code.. ofc, probably someone more familiar with mutex code should probably review, but probably a bit of

Re: [RFC v2 0/5] Common Display Framework

On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Rob, On Thursday 27 December 2012 09:54:55 Rob Clark wrote: What I've done to avoid that so far is that the master device registers the drivers for it's output sub-devices before registering it's own

Re: [PATCHv16 5/7] fbmon: add of_videomode helpers

On Mon, Jan 7, 2013 at 2:46 AM, Mohammed, Afzal af...@ti.com wrote: Hi Steffen, On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote: On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote: This breaks DaVinci (da8xx_omapl_defconfig), following change was required to get it

Re: [RFC v2 0/5] Common Display Framework

On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Rob, On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie airl...@gmail.com wrote: Many developers showed interest in the first RFC, and I've had

Re: [RFC v2 0/5] Common Display Framework

On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On the topic of discussions, would anyone be interested in a BoF/brainstorming/whatever session during the FOSDEM ? I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it looks like at least

Re: [RFC v2 0/5] Common Display Framework

On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: It just seems to me that, at least from a DRM/KMS perspective, adding another layer (=CDF) for HDMI or DP (or legacy outputs) would be

Re: [RFC v2 0/5] Common Display Framework

On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Wednesday 19 December 2012 09:26:40 Rob Clark wrote: And, there are also external HDMI encoders (for example connected over i2c) that can also be shared between boards. So I think

Re: [RFC v2 0/5] Common Display Framework

On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer s.ha...@pengutronix.de wrote: On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Rob, On Tuesday 18 December 2012 00:21:32 Rob Clark wrote

Re: [PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

be able to do something better when reservations land Signed-off-by: Rob Clark r...@ti.com Cc: Aaron Plattner aplatt...@nvidia.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- Documentation/dma-buf-sharing.txt | 6 +- drivers/base/dma-buf.c| 43

Re: [PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

On Thu, Dec 20, 2012 at 10:50 AM, Rob Clark robdcl...@gmail.com wrote: On Thu, Dec 20, 2012 at 7:14 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: All drivers which implement this need to have some sort of refcount to allow concurrent vmap usage. Hence implement this in the dma-buf core

Re: [RFC v2 0/5] Common Display Framework

On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula jani.nik...@linux.intel.com wrote: Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jani, On Monday 17 December 2012 18:53:37 Jani Nikula wrote: I can see the need for a framework for DSI panels

Re: [RFC v2 0/5] Common Display Framework

On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 2012-12-19 17:26, Rob Clark wrote: And, there are also external HDMI encoders (for example connected over i2c) that can also be shared between boards. So I think there will be a number of cases where CDF

Re: [RFC v2 0/5] Common Display Framework

On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie airl...@gmail.com wrote: Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Op 14-12-12 10:36, sumit.sem...@ti.com schreef: From: Sumit Semwal sumit.sem...@linaro.org Add debugfs support to make it easier to print debug information about the dma-buf buffers. I like the idea, I don't

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 11 Oct 2012 09:20:12 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is

Re: [Linaro-mm-sig] [RFC] New dma_buf - EGLImage EGL extension

On Tue, Oct 2, 2012 at 2:10 PM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: How do you want to deal with the case where Y' and CbCr are different hardware buffers? Could some support for 2d arrays be added in case Y' and CbCr are separated into top/bottom fields? How are

[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()

From: Rob Clark r...@ti.com We never really clarified if unmap could be done in atomic context. But since mapping might require sleeping, this implies mutex in use to synchronize mapping/unmapping, so unmap could sleep as well. Add a might_sleep() to clarify this. Signed-off-by: Rob Clark r

Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )

/dma-fence.c new file mode 100644 index 000..93448e4 --- /dev/null +++ b/drivers/base/dma-fence.c @@ -0,0 +1,268 @@ +/* + * Fence mechanism for dma-buf to allow for asynchronous dma access + * + * Copyright (C) 2012 Texas Instruments + * Author: Rob Clark rob.cl...@linaro.org

Re: [Linaro-mm-sig] [PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

back to when it was a user configurable option, rather than something select'd by drivers using dmabuf, and we just never went back to clean up. Let's drop the fallbacks. Reviewed-by: Rob Clark rob.cl...@linaro.org -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48

Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )

On Sat, Aug 11, 2012 at 2:22 PM, Daniel Vetter dan...@ffwll.ch wrote: + +/** + * dma_fence_wait - wait for a fence to be signaled + * + * @fence: [in]The fence to wait on + * @intr:[in]if true, do an interruptible wait + * @timeout: [in]absolute time for timeout, in

Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf

On Tue, Jul 31, 2012 at 7:11 AM, Hans Verkuil hverk...@xs4all.nl wrote: For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? Why? It's perfectly fine to use it and

Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf

On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged

Re: [PATCH 2/2] dma-buf: add helpers for attacher dma-parms

to the cleanup of moving dma_mask/coherent_dma_mask into dma_parms, I'll do this first. So anyways, don't consider this patch yet for inclusion, I'll make an updated one based on dma_parms.. BR, -R On Thu, Jul 19, 2012 at 11:23 AM, Rob Clark rob.cl...@linaro.org wrote: From: Rob Clark r

[PATCH 0/2] dma-parms and helpers for dma-buf

From: Rob Clark r...@ti.com Re-sending first patch, with a wider audience. Apparently I didn't spam enough inboxes the first time. And, at Daniel Vetter's suggestion, adding some helper functions in dma-buf to get the most restrictive parameters of all the attached devices. Rob Clark (2

[PATCH 2/2] dma-buf: add helpers for attacher dma-parms

From: Rob Clark r...@ti.com Add some helpers to iterate through all attachers and get the most restrictive segment size/count/boundary. Signed-off-by: Rob Clark r...@ti.com --- drivers/base/dma-buf.c | 63 +++ include/linux/dma-buf.h | 19

[PATCH 1/2] device: add dma_params-max_segment_count

From: Rob Clark r...@ti.com For devices which have constraints about maximum number of segments in an sglist. For example, a device which could only deal with contiguous buffers would set max_segment_count to 1. The initial motivation is for devices sharing buffers via dma-buf, to allow

Re: [PATCH] Documentation: DocBook DRM framework documentation

will as usual be appreciated, and acks will be even more welcome (I've been working on this document for longer than I feel comfortable with). btw, thanks for this! One minor typo below.. with that, Reviewed-by: Rob Clark rob.cl...@linaro.org diff --git a/Documentation/DocBook/drm.tmpl b

  1   2   >