All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomeu Vizoso <tomeu.vizoso@collabora.com>
To: Mark yao <mark.yao@rock-chips.com>
Cc: "open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] drm/rockchip: vop: Do check if an update is pending during disable
Date: Thu, 2 Jun 2016 07:57:36 +0200	[thread overview]
Message-ID: <CAAObsKC=kSbWkBgTgcYnkiudSH=xez3N1+OipT33vZ0YkMSPQQ@mail.gmail.com> (raw)
In-Reply-To: <574500FE.4050708@rock-chips.com>

On 25 May 2016 at 03:33, Mark yao <mark.yao@rock-chips.com> wrote:
> On 2016年05月25日 09:06, Mark yao wrote:
>
> On 2016年05月24日 18:11, Tomeu Vizoso wrote:
>
> Hi Tomeu
>>
>> Sorry for reply late.
>> I don't agree the changes:
>>
>> - if (!state->enable)
>> - return VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0;
>> + if (!state->enable &&
>> +    VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0)
>> + return true;
>>
>> This changes actually would lead a bug.
>> when we disable a plane, the vop_win_pending_is_complete would always
>> return
>> true, That is not allowed, would cause fb free too early.
>
> Ok, maybe I need to ask you first what the original block of code
> intended to achieve. The TRM I have is very terse and I don't find any
> explanation there. The battery of tests I have pass just fine without
> it.
>
>> Does this patch is needed for "[PATCH 2/2] drm/rockchip: vop: Wait for
>> pending events when disabling a CRTC"
>
> Yes, this function is currently returning false when the pageflip has
> been completed but the plan has been already disabled.
>
> If you have any different idea of how to fix this bug, please share.
>
> Thanks,
>
> Tomeu
>
>
>
> Hi Tomeu
>
> @@ -504,6 +506,9 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
>   if (!vop->is_enabled)
>   return;
>
> + if (crtc->state->event || vop->event)
> + vop_crtc_wait_for_update(crtc);
> +
>
> I think above change has some problem,
>
> the function stack:
> ->drm swap state
> ->vop_crtc_disable
> ->vop_atomic_begin
> ->vop_atomic_flush
>
> on vop_crtc_disable, crtc->state is new state, the crtc->state->event not
> yet update to vop, wait for  crtc->state->event here is wrong.
>
> So I think the patch should be:
> + if (vop->event)
> + vop_crtc_wait_for_update(crtc);
> +
>
>
> call vop_crtc_wait_for_update(crtc) here also is unsafe, it will reinit the
> vop->wait_update_complete.
>
> I doubt that, since use the serialize outstanding nonblocking commits, only
> one process can run into the update stack, old vop->event should be free on
> last time, if we get vop->event here, that should be a bug.
>
>
> Then the patch "drm/rockchip: vop: Do check if an update is pending during
> disable" should be no needed.

Hi Mark,

with Daniel's series linked below this and the other issues I found in
the Rockchip driver are fixed:

http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/91023/focus=91053

Thanks,

Tomeu

> Thanks.
>
> -- Mark Yao
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Mark Yao
>
>
> _______________________________________________
> 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: Tomeu Vizoso <tomeu.vizoso@collabora.com>
To: Mark yao <mark.yao@rock-chips.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/rockchip: vop: Do check if an update is pending during disable
Date: Thu, 2 Jun 2016 07:57:36 +0200	[thread overview]
Message-ID: <CAAObsKC=kSbWkBgTgcYnkiudSH=xez3N1+OipT33vZ0YkMSPQQ@mail.gmail.com> (raw)
In-Reply-To: <574500FE.4050708@rock-chips.com>

On 25 May 2016 at 03:33, Mark yao <mark.yao@rock-chips.com> wrote:
> On 2016年05月25日 09:06, Mark yao wrote:
>
> On 2016年05月24日 18:11, Tomeu Vizoso wrote:
>
> Hi Tomeu
>>
>> Sorry for reply late.
>> I don't agree the changes:
>>
>> - if (!state->enable)
>> - return VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0;
>> + if (!state->enable &&
>> +    VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0)
>> + return true;
>>
>> This changes actually would lead a bug.
>> when we disable a plane, the vop_win_pending_is_complete would always
>> return
>> true, That is not allowed, would cause fb free too early.
>
> Ok, maybe I need to ask you first what the original block of code
> intended to achieve. The TRM I have is very terse and I don't find any
> explanation there. The battery of tests I have pass just fine without
> it.
>
>> Does this patch is needed for "[PATCH 2/2] drm/rockchip: vop: Wait for
>> pending events when disabling a CRTC"
>
> Yes, this function is currently returning false when the pageflip has
> been completed but the plan has been already disabled.
>
> If you have any different idea of how to fix this bug, please share.
>
> Thanks,
>
> Tomeu
>
>
>
> Hi Tomeu
>
> @@ -504,6 +506,9 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
>   if (!vop->is_enabled)
>   return;
>
> + if (crtc->state->event || vop->event)
> + vop_crtc_wait_for_update(crtc);
> +
>
> I think above change has some problem,
>
> the function stack:
> ->drm swap state
> ->vop_crtc_disable
> ->vop_atomic_begin
> ->vop_atomic_flush
>
> on vop_crtc_disable, crtc->state is new state, the crtc->state->event not
> yet update to vop, wait for  crtc->state->event here is wrong.
>
> So I think the patch should be:
> + if (vop->event)
> + vop_crtc_wait_for_update(crtc);
> +
>
>
> call vop_crtc_wait_for_update(crtc) here also is unsafe, it will reinit the
> vop->wait_update_complete.
>
> I doubt that, since use the serialize outstanding nonblocking commits, only
> one process can run into the update stack, old vop->event should be free on
> last time, if we get vop->event here, that should be a bug.
>
>
> Then the patch "drm/rockchip: vop: Do check if an update is pending during
> disable" should be no needed.

Hi Mark,

with Daniel's series linked below this and the other issues I found in
the Rockchip driver are fixed:

http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/91023/focus=91053

Thanks,

Tomeu

> Thanks.
>
> -- Mark Yao
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Mark Yao
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
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: tomeu.vizoso@collabora.com (Tomeu Vizoso)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] drm/rockchip: vop: Do check if an update is pending during disable
Date: Thu, 2 Jun 2016 07:57:36 +0200	[thread overview]
Message-ID: <CAAObsKC=kSbWkBgTgcYnkiudSH=xez3N1+OipT33vZ0YkMSPQQ@mail.gmail.com> (raw)
In-Reply-To: <574500FE.4050708@rock-chips.com>

On 25 May 2016 at 03:33, Mark yao <mark.yao@rock-chips.com> wrote:
> On 2016?05?25? 09:06, Mark yao wrote:
>
> On 2016?05?24? 18:11, Tomeu Vizoso wrote:
>
> Hi Tomeu
>>
>> Sorry for reply late.
>> I don't agree the changes:
>>
>> - if (!state->enable)
>> - return VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0;
>> + if (!state->enable &&
>> +    VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0)
>> + return true;
>>
>> This changes actually would lead a bug.
>> when we disable a plane, the vop_win_pending_is_complete would always
>> return
>> true, That is not allowed, would cause fb free too early.
>
> Ok, maybe I need to ask you first what the original block of code
> intended to achieve. The TRM I have is very terse and I don't find any
> explanation there. The battery of tests I have pass just fine without
> it.
>
>> Does this patch is needed for "[PATCH 2/2] drm/rockchip: vop: Wait for
>> pending events when disabling a CRTC"
>
> Yes, this function is currently returning false when the pageflip has
> been completed but the plan has been already disabled.
>
> If you have any different idea of how to fix this bug, please share.
>
> Thanks,
>
> Tomeu
>
>
>
> Hi Tomeu
>
> @@ -504,6 +506,9 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
>   if (!vop->is_enabled)
>   return;
>
> + if (crtc->state->event || vop->event)
> + vop_crtc_wait_for_update(crtc);
> +
>
> I think above change has some problem,
>
> the function stack:
> ->drm swap state
> ->vop_crtc_disable
> ->vop_atomic_begin
> ->vop_atomic_flush
>
> on vop_crtc_disable, crtc->state is new state, the crtc->state->event not
> yet update to vop, wait for  crtc->state->event here is wrong.
>
> So I think the patch should be:
> + if (vop->event)
> + vop_crtc_wait_for_update(crtc);
> +
>
>
> call vop_crtc_wait_for_update(crtc) here also is unsafe, it will reinit the
> vop->wait_update_complete.
>
> I doubt that, since use the serialize outstanding nonblocking commits, only
> one process can run into the update stack, old vop->event should be free on
> last time, if we get vop->event here, that should be a bug.
>
>
> Then the patch "drm/rockchip: vop: Do check if an update is pending during
> disable" should be no needed.

Hi Mark,

with Daniel's series linked below this and the other issues I found in
the Rockchip driver are fixed:

http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/91023/focus=91053

Thanks,

Tomeu

> Thanks.
>
> -- ?ark Yao
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> ?ark Yao
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

  reply	other threads:[~2016-06-02  5:57 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06 10:14 [PATCH 1/2] drm/rockchip: vop: Do check if an update is pending during disable Tomeu Vizoso
2016-04-06 10:14 ` Tomeu Vizoso
2016-04-06 10:14 ` Tomeu Vizoso
2016-04-06 10:14 ` [PATCH 2/2] drm/rockchip: vop: Wait for pending events when disabling a CRTC Tomeu Vizoso
2016-04-06 10:14   ` Tomeu Vizoso
2016-04-06 10:14   ` Tomeu Vizoso
2016-04-08  1:07 ` [PATCH 1/2] drm/rockchip: vop: Do check if an update is pending during disable Mark yao
2016-04-08 10:54   ` Tomeu Vizoso
2016-04-08 10:54     ` Tomeu Vizoso
2016-04-08 10:54     ` Tomeu Vizoso
2016-04-11  1:15     ` Mark yao
2016-04-11  1:15       ` Mark yao
2016-04-11  1:15       ` Mark yao
2016-04-20 14:23       ` Tomeu Vizoso
2016-04-20 14:23         ` Tomeu Vizoso
2016-04-20 14:23         ` Tomeu Vizoso
2016-05-05  9:34         ` Tomeu Vizoso
2016-05-05  9:34           ` Tomeu Vizoso
2016-05-05  9:34           ` Tomeu Vizoso
2016-05-23  6:32           ` Mark yao
2016-05-23  6:32             ` Mark yao
2016-05-23  6:32             ` Mark yao
2016-05-24 10:11             ` Tomeu Vizoso
2016-05-24 10:11               ` Tomeu Vizoso
2016-05-24 10:11               ` Tomeu Vizoso
2016-05-25  1:06               ` Mark yao
2016-05-25  1:33                 ` Mark yao
2016-06-02  5:57                   ` Tomeu Vizoso [this message]
2016-06-02  5:57                     ` Tomeu Vizoso
2016-06-02  5:57                     ` Tomeu Vizoso
2016-06-02  6:25                     ` Mark yao
2016-06-02  6:25                       ` Mark yao
2016-06-02  6:25                       ` Mark yao
2016-06-02  6:35                       ` Tomeu Vizoso
2016-06-02  6:35                         ` Tomeu Vizoso
2016-06-02  6:35                         ` Tomeu Vizoso

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='CAAObsKC=kSbWkBgTgcYnkiudSH=xez3N1+OipT33vZ0YkMSPQQ@mail.gmail.com' \
    --to=tomeu.vizoso@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.yao@rock-chips.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.