All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Dave Airlie" <airlied@gmail.com>,
	"Christian König" <christian.koenig@amd.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	venkata.s.dhanalakota@intel.com,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
Date: Thu, 25 Jun 2020 22:27:52 +0300	[thread overview]
Message-ID: <874kqzndxj.fsf@intel.com> (raw)
In-Reply-To: <CAPM=9txhX5TVUdWibRFc1C+ip5a8-c07jZawds=k5T5pBTPASA@mail.gmail.com>

On Fri, 26 Jun 2020, Dave Airlie <airlied@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 <chris@chris-wilson.co.uk>
>     Tested-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
>     Reviewed-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
>
>
> On Thu, 25 Jun 2020 at 22:43, Christian König <christian.koenig@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.landwerlin@intel.com>
>>
>> Reviewed-by: Christian König <christian.koenig@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-gfx@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

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Dave Airlie" <airlied@gmail.com>,
	"Christian König" <christian.koenig@amd.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
Date: Thu, 25 Jun 2020 22:27:52 +0300	[thread overview]
Message-ID: <874kqzndxj.fsf@intel.com> (raw)
In-Reply-To: <CAPM=9txhX5TVUdWibRFc1C+ip5a8-c07jZawds=k5T5pBTPASA@mail.gmail.com>

On Fri, 26 Jun 2020, Dave Airlie <airlied@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 <chris@chris-wilson.co.uk>
>     Tested-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
>     Reviewed-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
>
>
> On Thu, 25 Jun 2020 at 22:43, Christian König <christian.koenig@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.landwerlin@intel.com>
>>
>> Reviewed-by: Christian König <christian.koenig@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-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-06-25 19:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 12:34 [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain" Lionel Landwerlin
2020-06-25 12:34 ` [Intel-gfx] " Lionel Landwerlin
2020-06-25 12:34 ` [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test Lionel Landwerlin
2020-06-25 12:34   ` [Intel-gfx] " Lionel Landwerlin
2020-06-25 12:44   ` Christian König
2020-06-25 12:44     ` [Intel-gfx] " Christian König
2020-06-25 13:18   ` Chris Wilson
2020-06-25 13:18     ` Chris Wilson
2020-06-25 13:23     ` Lionel Landwerlin
2020-06-25 13:23       ` Lionel Landwerlin
2020-06-25 13:47       ` Chris Wilson
2020-06-25 13:47         ` Chris Wilson
2020-06-25 13:56         ` Lionel Landwerlin
2020-06-25 13:56           ` Lionel Landwerlin
2020-06-25 13:59       ` Daniel Vetter
2020-06-25 13:59         ` Daniel Vetter
2020-07-02 12:57         ` Christian König
2020-07-02 12:57           ` Christian König
2020-06-25 12:43 ` [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain" Christian König
2020-06-25 12:43   ` [Intel-gfx] " Christian König
2020-06-25 17:13   ` Dave Airlie
2020-06-25 17:13     ` Dave Airlie
2020-06-25 19:27     ` Jani Nikula [this message]
2020-06-25 19:27       ` Jani Nikula
2020-06-25 19:54       ` Daniel Vetter
2020-06-25 19:54         ` Daniel Vetter
2020-06-26  4:43         ` Sumit Semwal
2020-06-26  4:43           ` Sumit Semwal
2020-06-26  7:03           ` Christian König
2020-06-26  7:03             ` Christian König
2020-06-26 12:39             ` Daniel Vetter
2020-06-26 12:39               ` Daniel Vetter
2020-06-26 15:34               ` Sumit Semwal
2020-06-26 15:34                 ` Sumit Semwal
2020-06-26  1:36       ` Dave Airlie
2020-06-26  1:36         ` Dave Airlie
2020-07-02  8:26   ` Lionel Landwerlin
2020-07-02  8:26     ` [Intel-gfx] " Lionel Landwerlin
2020-07-02  8:28     ` Christian König
2020-07-02  8:28       ` [Intel-gfx] " Christian König
2020-06-26 14:15 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kqzndxj.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tzimmermann@suse.de \
    --cc=venkata.s.dhanalakota@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.