On Fri, 26 Jun 2020, Dave Airlie <airl...@gmail.com> wrote: > WTUF? > > How did this ever land in my tree, there is no ACK on this from anyone > in core dma-buf, > > Intel team, clean your house up here, I'm going to have to ask you to > stop Chris merging stuff without oversight, if this sort of thing > happens, this is totally unacceptable.
There's no argument, an ack is required. In fairness to the i915 maintainers, though, this particular commit was merged via drm-misc-next [1]. As a side note, there seem to be extra checks in place for acks when applying non-i915 patches to drm-intel; there are no such checks for drm-misc. BR, Jani. [1] http://lore.kernel.org/r/20200414090738.GA16827@linux-uq9g > > Dave. > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Tested-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalak...@intel.com> > Reviewed-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalak...@intel.com> > > > On Thu, 25 Jun 2020 at 22:43, Christian König <christian.koe...@amd.com> > wrote: >> >> Am 25.06.20 um 14:34 schrieb Lionel Landwerlin: >> > This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d. >> > >> > This change breaks synchronization of a timeline. >> > dma_fence_chain_find_seqno() might be a bit of a confusing name but >> > this function is not trying to find a particular seqno, is supposed to >> > give a fence to wait on for a particular point in the timeline. >> > >> > In a timeline, a particular value is reached when all the points up to >> > and including that value have signaled. >> > >> > Signed-off-by: Lionel Landwerlin <lionel.g.landwer...@intel.com> >> >> Reviewed-by: Christian König <christian.koe...@amd.com> >> >> > --- >> > drivers/dma-buf/dma-fence-chain.c | 7 ------- >> > 1 file changed, 7 deletions(-) >> > >> > diff --git a/drivers/dma-buf/dma-fence-chain.c >> > b/drivers/dma-buf/dma-fence-chain.c >> > index c435bbba851c..3d123502ff12 100644 >> > --- a/drivers/dma-buf/dma-fence-chain.c >> > +++ b/drivers/dma-buf/dma-fence-chain.c >> > @@ -99,12 +99,6 @@ int dma_fence_chain_find_seqno(struct dma_fence >> > **pfence, uint64_t seqno) >> > return -EINVAL; >> > >> > dma_fence_chain_for_each(*pfence, &chain->base) { >> > - if ((*pfence)->seqno < seqno) { /* already signaled */ >> > - dma_fence_put(*pfence); >> > - *pfence = NULL; >> > - break; >> > - } >> > - >> > if ((*pfence)->context != chain->base.context || >> > to_dma_fence_chain(*pfence)->prev_seqno < seqno) >> > break; >> > @@ -228,7 +222,6 @@ EXPORT_SYMBOL(dma_fence_chain_ops); >> > * @chain: the chain node to initialize >> > * @prev: the previous fence >> > * @fence: the current fence >> > - * @seqno: the sequence number (syncpt) of the fence within the chain >> > * >> > * Initialize a new chain node and either start a new chain or add the >> > node to >> > * the existing chain of the previous fence. >> >> _______________________________________________ >> Intel-gfx mailing list >> intel-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
