On Wed, Jan 16, 2019 at 11:49 AM Thomas Hellstrom wrote:
>
> Hi,
>
> On Wed, 2019-01-16 at 09:24 -0500, Rob Clark wrote:
> > So, I guess this is to do w/ the magic of merge commits, but it looks
> > like the hunk changing the crtc_ww_class got lost:
>
> So what hap
So, I guess this is to do w/ the magic of merge commits, but it looks
like the hunk changing the crtc_ww_class got lost:
~/src/linux master git show --pretty=short
08295b3b5beec9aac0f7a9db86f0fc3792039da3
drivers/gpu/drm/drm_modeset_lock.c
commit 08295b3b5beec9aac0f7a9db86f0fc3792039da3
Au
On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson 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
>> timeout to dma_fence_wait_timeout().
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
---
drivers/dma-buf/reservation.c | 11 +--
1 file chang
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 MODIFIER_FOO, I could attempt
>> >> to share
On Sun, Jul 9, 2017 at 3:49 PM, Stanimir Varbanov
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:
>
> Is it happens occasionally or everyt
uffer. So just bailing seems
like a reasonable solution.
Signed-off-by: Rob Clark
---
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/platform/qcom/venus/
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 too)?
>> -Daniel
>>
>
>
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]
>>
>> > >
>> > > For me those patches
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 case.. dri2/flink is
kind of l
vices 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 :
>> so there is discussion about a "central userspace allocator" (
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 thoughts/proposal
t;> query
>> 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<-
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 property which can repr
On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen wrote:
> On Fri, 17 Jun 2016 11:44:34 -0400
> Rob Clark wrote:
>
>> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen wrote:
>> > On Fri, 17 Jun 2016 08:26:04 -0400
>> > Rob Clark wrote:
>> >
>> &g
On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen wrote:
> On Fri, 17 Jun 2016 08:26:04 -0400
> Rob Clark wrote:
>
>> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen wrote:
>> > On Thu, 16 Jun 2016 10:40:51 -0400
>> > Rob Clark wrote:
>> >
>> &
On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen wrote:
> On Thu, 16 Jun 2016 10:40:51 -0400
> Rob Clark wrote:
>
>> So, if we wanted to extend this to support the fourcc-modifiers that
>> we have on the kernel side for compressed/tiled/etc formats, what
>> would be
t; application
>> has use one EGL doesn't support is sufficient. Any thoughts?
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>> 8<
>>
>>
>> Name
>>
>> EXT_image_dma_buf_import
On Thu, Apr 28, 2016 at 7:33 AM, Stanimir Varbanov
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 deal
>>> with
>>> p
On Fri, Apr 15, 2016 at 12: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 deal
>> with
>> properly in gallium.. it's a similar issue to multi-planer even
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 Varbanov wrote:
Hi,
>>
On Wed, May 6, 2015 at 4:35 AM, Daniel Vetter 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
>> > har
On Wed, Feb 11, 2015 at 7:56 AM, Daniel Vetter 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
>> wrote:
>> > As I've already pointed out, there's a major problem if you have a
e current constraints as
>> >calculated
>> > during each attach on the buffer till the time,
>> >- dma_buf_recalc_constraints - which recalculates the constraints for all
>> > currently attached devices for the 'paranoid' ones amongst us.
>> &
On Tue, Feb 3, 2015 at 11:58 AM, Russell King - ARM Linux
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 is there any way
On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann 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-device
>
> where the IOMMU controls one or more contexts per d
On Tue, Feb 3, 2015 at 9:52 AM, Arnd Bergmann 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&#
On Tue, Feb 3, 2015 at 9:41 AM, 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 of built in mmu, my plan was to
>> >
On Tue, Feb 3, 2015 at 9:37 AM, Russell King - ARM Linux
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,
>&g
On Tue, Feb 3, 2015 at 7:28 AM, Russell King - ARM Linux
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 wrote:
>> > >> My
On Tue, Feb 3, 2015 at 2:48 AM, 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 wrote:
>> >> My initial thought is for dma-buf to not try to prevent something than
>> >> an expor
On Mon, Feb 2, 2015 at 4:46 PM, Russell King - ARM Linux
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 wrote:
>> >> My initial thought is for dma-buf to not try to prevent something than
>> >>
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter 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 needed, each
On Thu, Jan 29, 2015 at 5:31 PM, Russell King - ARM Linux
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
>> wrote:
>> > Now, if we're going to do the "more clever" thing you
On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
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
>> diff
On Thu, Jan 29, 2015 at 10:47 AM, Russell King - ARM Linux
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.
>>
>> At each d
On Thu, Jun 19, 2014 at 5:50 PM, Dave Airlie wrote:
> On 20 June 2014 04:19, Greg KH 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 wrote:
>>> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clar
On Thu, Jun 19, 2014 at 2:19 PM, Greg KH 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 wrote:
>> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote:
>> >> On Wed, Jun 18, 2014 at 9:13 PM, Gre
On Thu, Jun 19, 2014 at 1:00 PM, Greg KH 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 wrote:
>> > On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
>> >> +#define CREAT
s.enable_signaling gets called. This can
>> + * be used for other implementing other types of fence.
>> + *
>> + * context and seqno are used for easy comparison between fences, allowing
>> + * to check which fence is later by simply using fence_later.
>> + */
>&
n. This allows you
>> to wait for less fences, by testing for seqno + signaled, and then only
>> wait on the later fence.
>>
>> Add FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
>> An CONFIG_DEBUG_FENCE will be added to turn off the FENC
ear increasing sequence number for this context
>> + *
>> + * Initializes an allocated fence, the caller doesn't have to keep its
>> + * refcount after committing with this fence, but it will need to hold a
>> + * refcount again if fence_ops.enable_signaling gets called. This c
On Mon, Feb 17, 2014 at 12:36 PM, Christian König
wrote:
> Am 17.02.2014 18:27, schrieb Rob Clark:
>
>> On Mon, Feb 17, 2014 at 11:56 AM, Christian König
>> wrote:
>>>
>>> Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
>>>
>>>> This ty
worker if
needed.
BR,
-R
> Christian.
>
>>
>> A software fallback still has to be provided in case the fence is used
>> with a device that doesn't support this mechanism. It is useful to expose
>> this for graphics cards that have an op to support this.
>
ig description.
> Move fence_context_alloc to fence.
> Simplify fence_later.
> Kill priv member to fence_cb.
> v14:
> Remove priv argument from fence_add_callback, oops!
> v15:
> Remove priv from documentation.
> Explicitly includ
lback.
>
> I extended 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
>
On Mon, Feb 17, 2014 at 10:58 AM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark
> ---
> include/linux/reservation.h | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/reservation
t; + if (dev->driver->gem_prime_res_obj)
> + robj = dev->driver->gem_prime_res_obj(obj);
well, you could hook up msm_gem_prime_res_obj too (since I already
have a resv obj in 'struct msm_gem_object' ;-)
That said, I wonder if maybe we just want to pr
if (!fence_add_callback(resv->fence_excl,
> + &dcb->cb, dma_buf_poll_cb))
> + events &= ~pevents;
> + else
> + // No cal
mabuf);
> - if (IS_ERR_OR_NULL(ptr))
> + if (WARN_ON_ONCE(IS_ERR(ptr)))
since vmap is optional, the WARN_ON might be a bit strong.. although
it would be a bit strange for an exporter to supply a vmap fxn which
always returned NULL, not sure about that. Just thought I'd mention
On Thu, Aug 15, 2013 at 7:16 AM, Maarten Lankhorst
wrote:
> Op 12-08-13 17:43, Rob Clark schreef:
>> On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
>> wrote:
>>> +
[snip]
>>> +/**
>>> + * fence_add_callback - add a callback to be called when th
FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
> An CONFIG_DEBUG_FENCE will be added to turn off the FENCE_TRACE
> spam, and another runtime option can turn it off at runtime.
> v12:
> Add CONFIG_FENCE_TRACE. Add missing document
On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey 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 scanning ou
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey 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
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz wrote:
> On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark 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
On Tue, Aug 6, 2013 at 1:38 PM, Tom Cooksey 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 devi
On Tue, Aug 6, 2013 at 10:36 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
>> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
>> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> >> Hi Rob,
>> >>
On Tue, Aug 6, 2013 at 10:03 AM, Tom Cooksey 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
>> >> > difficu
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach 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
>> > >> wrote:
>> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
>> > >> >> >
On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey 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, even i
On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey 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
>> wrote:
>> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >> >
G memory allocation
> fails.
Reviewed-by: Rob Clark
>
> Signed-off-by: Vikas Sajjan
> Signed-off-by: Arun Kumar
> ---
> changes since v1:
> - Modified to add the fallback patch if CONTIG alloc fails as
> suggested
> by Rob Clark robdcl...@gmail.com
On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa 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 enabled:
>> [0
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae 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 resources.
>>
>
On Mon, May 27, 2013 at 11:56 PM, Inki Dae 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
>
On Mon, May 27, 2013 at 6:38 AM, Inki Dae 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 that
> coupling t
On Wed, May 15, 2013 at 1:19 AM, Inki Dae 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
On Mon, May 13, 2013 at 10:52 PM, Inki Dae 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 CPU access i
On Mon, May 13, 2013 at 1:18 PM, Inki Dae wrote:
>
>
> 2013/5/13 Rob Clark
>>
>> On Mon, May 13, 2013 at 8:21 AM, Inki Dae wrote:
>> >
>> >> In that case you still wouldn't give userspace control over the fences.
>> >> I
>> >
On Mon, May 13, 2013 at 8:21 AM, Inki Dae 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 cases,
ore, and since I want to be able to
>>>> expose
>>>> shared objects as proper GEM objects from the import side I really
>>>> need that list of pages.
>>>
>>> Hm, what does "proper GEM object" mean in the context of udl?
>>
>>
On Fri, Feb 1, 2013 at 5:42 PM, Laurent Pinchart
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 operations to
>> display_entit
On Wed, Jan 30, 2013 at 5:52 AM, Rob Clark wrote:
> On Wed, Jan 30, 2013 at 5:08 AM, Daniel Vetter wrote:
>> On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark wrote:
>>> ==
>>> Basic problem statement:
>>> - --- -
>>&
On Wed, Jan 30, 2013 at 5:08 AM, Daniel Vetter wrote:
> On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark wrote:
>> ==
>> Basic problem statement:
>> - --- -
>> GPU's do operations that commonly involve many buffers. Those
On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst
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 explanation about
what and why wo
On Mon, Jan 21, 2013 at 5:07 AM, Steffen Trumtrar
wrote:
> Hi!
>
> There was still no maintainer, that commented, ack'd, nack'd, apply'd the
> series. So, this is just a resend.
> The patches were tested with:
>
> - v15 on Tegra by Thierry
> - sh-mobile-lcdcfb by Laurent
>
On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart
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
On Mon, Jan 7, 2013 at 2:46 AM, Mohammed, Afzal 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 bu
On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer 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
>> wrote:
>> > Hi Rob,
>> >
>> > On Tuesday 18 December 2012 00:21:32 Rob Clark wro
On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart
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 there will be
>> a number
On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart
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
>> overengineering it. They are pretty
On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart
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 Daniel will be there. If enoug
On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
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 wrote:
>> >> Many developers showed interest in the first RFC, and I've had the
>>
On Thu, Dec 20, 2012 at 10:50 AM, Rob Clark wrote:
> On Thu, Dec 20, 2012 at 7:14 AM, Daniel Vetter 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.
>>
>> To prote
Plattner.
yeah, I think the locking does worry me a bit but hopefully should be
able to do something better when reservations land
Signed-off-by: Rob Clark
> Cc: Aaron Plattner
> Signed-off-by: Daniel Vetter
> ---
> Documentation/dma-buf-sharing.txt | 6 +-
> drivers/base
On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen 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 w
On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula
wrote:
>
> Hi Laurent -
>
> On Tue, 18 Dec 2012, Laurent Pinchart
> 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 and such (in fact Tomi
>>> and I have talked abou
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie 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 v2,
>> M
On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
wrote:
> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
>> From: Sumit Semwal
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
> I like the idea, I don't know if it could be done in a free m
On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab
wrote:
> Em Thu, 11 Oct 2012 09:20:12 +0200
> Hans Verkuil escreveu:
>
>> > my understaning is
>> > that the drivers/media/ authors should also ack with this licensing
>> > (possible) change. I am one of the main contributors there. Alan also
On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox wrote:
> On Wed, 10 Oct 2012 08:56:32 -0700
> Robert Morell wrote:
>
>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> issue, and not really an interface". The dma-buf infrastructure is
>> explicitly intended as an interface
On Tue, Oct 2, 2012 at 2:10 PM, Maarten Lankhorst
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 semi-planar/planar formats handle
From: Rob Clark
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
Acked-by
On Sat, Aug 11, 2012 at 2:22 PM, Daniel Vetter 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
llbacks date 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
> --
> Daniel Vetter
> Mail: dan...@ffwll.ch
> Mobile: +41 (0)79 365 5
> !Edrivers/base/dma-coherent.c
>> !Edrivers/base/dma-mapping.c
>>
>> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
>> index 5aa2d70..6e9f217 100644
>> --- a/drivers/base/Makefile
>> +++ b/drivers/base/Makefile
>> @@ -10,7 +10,7 @
On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont 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 once
On Tue, Jul 31, 2012 at 7:11 AM, Hans Verkuil 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 it's
jects 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 wrote:
> From: Rob Clark
From: Rob Clark
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 the buffer
1 - 100 of 158 matches
Mail list logo
