Linaro-mm-sig May 2019

linaro-mm-sig@lists.linaro.org

6 participants
4 discussions

Re: [Linaro-mm-sig] [PATCH 02/12] dma-buf: add dma_buf_(un)map_attachment_locked variants v3

by Hillf Danton

On Mon, 27 May 2019 18:56:20 +0800 Christian Koenig wrote: > Thanks for the comments, but you are looking at a completely outdated patchset. > > If you are interested in the newest one please ping me and I'm going to CC you > when I send out the next version. > Ping... Thanks Hillf

5 years, 6 months

dynamic DMA-buf sharing between devices

by Christian König

Hi everybody, core idea in this patch set is that DMA-buf importers can now provide an optional invalidate callback. Using this callback and the reservation object exporters can now avoid pinning DMA-buf memory for a long time while sharing it between devices. I've already send out an older version roughly a year ago, but didn't had time to further look into cleaning this up. The last time a major problem was that we would had to fix up all drivers implementing DMA-buf at once. Now I avoid this by allowing mappings to be cached in the DMA-buf attachment and so driver can optionally move over to the new interface one by one. This is also a prerequisite to my patchset enabling sharing of device memory with DMA-buf. Please review and/or comment, Christian.

5 years, 6 months

Re: [Linaro-mm-sig] [EXTERNAL] Re: [PATCH] sync_file: Return reasonable timestamp when merging signaled fences

by Chris Wilson

Quoting Michael Yang (2019-05-14 08:55:37) > On Thu, May 09, 2019 at 12:46:05PM +0100, Chris Wilson wrote: > > Quoting Michael Yang (2019-05-09 05:34:11) > > > If all the sync points were signaled in both fences a and b, > > > there was only one sync point in merged fence which is a_fence[0]. > > > The Fence structure in android framework might be confused about > > > timestamp if there were any sync points which were signaled after > > > a_fence[0]. It might be more reasonable to use timestamp of last signaled > > > sync point to represent the merged fence. > > > The issue can be found from EGL extension ANDROID_get_frame_timestamps. > > > Sometimes the return value of EGL_READS_DONE_TIME_ANDROID is head of > > > the return value of EGL_RENDERING_COMPLETE_TIME_ANDROID. > > > That means display/composition had been completed before rendering > > > was completed that is incorrect. > > > > > > Some discussion can be found at: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__android-2Dreview.googl… > > > > > > Signed-off-by: Michael Yang <michael.yang(a)imgtec.com> > > > --- > > > Hi, > > > I didn't get response since I previously sent this a month ago. > > > Could someone have a chance to look at it please? > > > Thanks. > > > drivers/dma-buf/sync_file.c | 25 +++++++++++++++++++++++-- > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > > > index 4f6305c..d46bfe1 100644 > > > --- a/drivers/dma-buf/sync_file.c > > > +++ b/drivers/dma-buf/sync_file.c > > > @@ -274,8 +274,29 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a, > > > for (; i_b < b_num_fences; i_b++) > > > add_fence(fences, &i, b_fences[i_b]); > > > > > > - if (i == 0) > > > - fences[i++] = dma_fence_get(a_fences[0]); > > > + /* If all the sync pts were signaled, then adding the sync_pt who > > > + * was the last signaled to the fence. > > > + */ > > > + if (i == 0) { > > > + struct dma_fence *last_signaled_sync_pt = a_fences[0]; > > > + int iter; > > > + > > > + for (iter = 1; iter < a_num_fences; iter++) { > > > > If there is more than one fence, sync_file->fence is a fence_array and > > its timestamp is what you want. If there is one fence, sync_file->fence > > is a pointer to that fence, and naturally has the right timestamp. > > > > In short, this should be handled by dma_fence_array_create() when given > > a complete set of signaled fences, it too should inherit the signaled > > status with the timestamp being taken from the last fence. It should > > also be careful to inherit the error status. > > -Chris > Thanks Chris for the inputs. For this case, there will be only one fence > in sync_file->fence after doing sync_file_merge(). Regarding to the current > implementation, dma_fence_array_create() is not called as num_fences is equal > to 1. I was wondering do you suggest that we pass a complete set of signaled > fences to sync_file_set_fence() and handle it in dma_fence_array_create(). > Thanks. No, in the case there is only one fence, we just inherit its timestamp along with its fence status. (A single fence is the degenerate case of a fence array.) -Chris

5 years, 7 months

Re: [Linaro-mm-sig] [PATCH] sync_file: Return reasonable timestamp when merging signaled fences

by Chris Wilson

Quoting Michael Yang (2019-05-09 05:34:11) > If all the sync points were signaled in both fences a and b, > there was only one sync point in merged fence which is a_fence[0]. > The Fence structure in android framework might be confused about > timestamp if there were any sync points which were signaled after > a_fence[0]. It might be more reasonable to use timestamp of last signaled > sync point to represent the merged fence. > The issue can be found from EGL extension ANDROID_get_frame_timestamps. > Sometimes the return value of EGL_READS_DONE_TIME_ANDROID is head of > the return value of EGL_RENDERING_COMPLETE_TIME_ANDROID. > That means display/composition had been completed before rendering > was completed that is incorrect. > > Some discussion can be found at: > https://android-review.googlesource.com/c/kernel/common/+/907009 > > Signed-off-by: Michael Yang <michael.yang(a)imgtec.com> > --- > Hi, > I didn't get response since I previously sent this a month ago. > Could someone have a chance to look at it please? > Thanks. > drivers/dma-buf/sync_file.c | 25 +++++++++++++++++++++++-- > 1 file changed, 23 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > index 4f6305c..d46bfe1 100644 > --- a/drivers/dma-buf/sync_file.c > +++ b/drivers/dma-buf/sync_file.c > @@ -274,8 +274,29 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a, > for (; i_b < b_num_fences; i_b++) > add_fence(fences, &i, b_fences[i_b]); > > - if (i == 0) > - fences[i++] = dma_fence_get(a_fences[0]); > + /* If all the sync pts were signaled, then adding the sync_pt who > + * was the last signaled to the fence. > + */ > + if (i == 0) { > + struct dma_fence *last_signaled_sync_pt = a_fences[0]; > + int iter; > + > + for (iter = 1; iter < a_num_fences; iter++) { If there is more than one fence, sync_file->fence is a fence_array and its timestamp is what you want. If there is one fence, sync_file->fence is a pointer to that fence, and naturally has the right timestamp. In short, this should be handled by dma_fence_array_create() when given a complete set of signaled fences, it too should inherit the signaled status with the timestamp being taken from the last fence. It should also be careful to inherit the error status. -Chris

5 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig May 2019