[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAObsKC-4hFP63AHS_Xw07bWQAXHYkwjNQ0Y_ocGw_-i1jTW2Q@mail.gmail.com>
Date: Thu, 2 Jun 2016 08:35:09 +0200
From: Tomeu Vizoso <tomeu.vizoso@...labora.com>
To: Mark yao <mark.yao@...k-chips.com>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/rockchip: vop: Do check if an update is pending
during disable
On 2 June 2016 at 08:25, Mark yao <mark.yao@...k-chips.com> wrote:
> On 2016年06月02日 13:57, Tomeu Vizoso wrote:
>>
>> On 25 May 2016 at 03:33, Mark yao <mark.yao@...k-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
>
>
> Good news, I also see the Daniel's series patches, wonderful update.
>
> You can add a Tested-by for Daniel's rockchip patches, and I add a Acked-by
> for those rockchip patches.
Yup, should be already there.
Regards,
Tomeu
> Thanks
>
>
>> Thanks,
>>
>> Tomeu
>>
>>> Thanks.
>>>
>>> -- Mark Yao
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@...ts.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>>
>>>
>>> --
>>> Mark Yao
>>>
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@...ts.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>>
>
>
> --
> Mark Yao
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Powered by blists - more mailing lists