* Re: [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling
@ 2016-03-19 1:15 ` Mark yao
0 siblings, 0 replies; 8+ messages in thread
From: Mark yao @ 2016-03-19 1:15 UTC (permalink / raw)
To: Tomeu Vizoso, linux-kernel
Cc: David Airlie, Heiko Stuebner, dri-devel, linux-arm-kernel,
linux-rockchip
On 2016年03月18日 19:22, Tomeu Vizoso wrote:
> When the VOP is re-enabled, it will start scanning right away the
> framebuffers that were configured from the last time, even if those have
> been destroyed already. To prevent the VOP from trying to access freed
> memory, reset the registers that hold pointers to framebuffers right
> after we can write to them, but before the VOP is awaken from standby.
>
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Link: http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw@mail.gmail.com
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 5e57f5b2e4b0..0df91c28740b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -429,6 +429,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
> static void vop_enable(struct drm_crtc *crtc)
> {
> struct vop *vop = to_vop(crtc);
> + int i;
> int ret;
>
> if (vop->is_enabled)
> @@ -476,6 +477,18 @@ static void vop_enable(struct drm_crtc *crtc)
> */
> vop->is_enabled = true;
>
> + /*
> + * Before turning the VOP completely on, unset the registers
> + * containing FB addresses to avoid the HW start scanning old FBs.
> + */
> + for (i = 0; i < vop->data->win_size; i++) {
> + struct vop_win *vop_win = &vop->win[i];
> + const struct vop_win_data *win = vop_win->data;
> +
> + VOP_WIN_SET(vop, win, yrgb_mst, 0x0);
> + VOP_WIN_SET(vop, win, uv_mst, 0x0);
> + }
> +
Hi Tomeu
Thanks for your fix.
Set yrgb_mst and uv_mst is not a good idea, because 0x0 also is a memory
buffer address, ddr will access the 0x0 buffer.
I think you may enable DRM_FBDEV_EMULATION, the 0x0 address is iommu
mmaped address for fbdev, so your test can works.
but if DRM_FBDEV_EMULATION is not define, may be 0x0 address is
unmmaped, would get the iommu crash.
I think we can use atomic disable function like this:
for_each_plane_in_state(old_state, plane, old_plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
funcs = plane->helper_private;
funcs->atomic_disable(plane, old_plane_state);
}
But I think we'd better find why we need do this hack here.
Does the old FB address is ummaped when crtc disabling? why plane is not
disabled?
Thanks.
> spin_lock(&vop->reg_lock);
>
> VOP_CTRL_SET(vop, standby, 0);
--
Ｍark Yao
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling
@ 2016-03-19 1:15 ` Mark yao
0 siblings, 0 replies; 8+ messages in thread
From: Mark yao @ 2016-03-19 1:15 UTC (permalink / raw)
To: linux-arm-kernel
On 2016?03?18? 19:22, Tomeu Vizoso wrote:
> When the VOP is re-enabled, it will start scanning right away the
> framebuffers that were configured from the last time, even if those have
> been destroyed already. To prevent the VOP from trying to access freed
> memory, reset the registers that hold pointers to framebuffers right
> after we can write to them, but before the VOP is awaken from standby.
>
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Link: http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw at mail.gmail.com
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 5e57f5b2e4b0..0df91c28740b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -429,6 +429,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
> static void vop_enable(struct drm_crtc *crtc)
> {
> struct vop *vop = to_vop(crtc);
> + int i;
> int ret;
>
> if (vop->is_enabled)
> @@ -476,6 +477,18 @@ static void vop_enable(struct drm_crtc *crtc)
> */
> vop->is_enabled = true;
>
> + /*
> + * Before turning the VOP completely on, unset the registers
> + * containing FB addresses to avoid the HW start scanning old FBs.
> + */
> + for (i = 0; i < vop->data->win_size; i++) {
> + struct vop_win *vop_win = &vop->win[i];
> + const struct vop_win_data *win = vop_win->data;
> +
> + VOP_WIN_SET(vop, win, yrgb_mst, 0x0);
> + VOP_WIN_SET(vop, win, uv_mst, 0x0);
> + }
> +
Hi Tomeu
Thanks for your fix.
Set yrgb_mst and uv_mst is not a good idea, because 0x0 also is a memory
buffer address, ddr will access the 0x0 buffer.
I think you may enable DRM_FBDEV_EMULATION, the 0x0 address is iommu
mmaped address for fbdev, so your test can works.
but if DRM_FBDEV_EMULATION is not define, may be 0x0 address is
unmmaped, would get the iommu crash.
I think we can use atomic disable function like this:
for_each_plane_in_state(old_state, plane, old_plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
funcs = plane->helper_private;
funcs->atomic_disable(plane, old_plane_state);
}
But I think we'd better find why we need do this hack here.
Does the old FB address is ummaped when crtc disabling? why plane is not
disabled?
Thanks.
> spin_lock(&vop->reg_lock);
>
> VOP_CTRL_SET(vop, standby, 0);
--
?ark Yao
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling
2016-03-19 1:15 ` Mark yao
@ 2016-03-21 14:55 ` Tomeu Vizoso
-1 siblings, 0 replies; 8+ messages in thread
From: Tomeu Vizoso @ 2016-03-21 14:55 UTC (permalink / raw)
To: Mark yao
Cc: linux-kernel@vger.kernel.org, open list:ARM/Rockchip SoC...,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org
On 19 March 2016 at 02:15, Mark yao <mark.yao@rock-chips.com> wrote:
> On 2016年03月18日 19:22, Tomeu Vizoso wrote:
>>
>> When the VOP is re-enabled, it will start scanning right away the
>> framebuffers that were configured from the last time, even if those have
>> been destroyed already. To prevent the VOP from trying to access freed
>> memory, reset the registers that hold pointers to framebuffers right
>> after we can write to them, but before the VOP is awaken from standby.
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> Link:
>> http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw@mail.gmail.com
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index 5e57f5b2e4b0..0df91c28740b 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -429,6 +429,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop
>> *vop)
>> static void vop_enable(struct drm_crtc *crtc)
>> {
>> struct vop *vop = to_vop(crtc);
>> + int i;
>> int ret;
>> if (vop->is_enabled)
>> @@ -476,6 +477,18 @@ static void vop_enable(struct drm_crtc *crtc)
>> */
>> vop->is_enabled = true;
>> + /*
>> + * Before turning the VOP completely on, unset the registers
>> + * containing FB addresses to avoid the HW start scanning old FBs.
>> + */
>> + for (i = 0; i < vop->data->win_size; i++) {
>> + struct vop_win *vop_win = &vop->win[i];
>> + const struct vop_win_data *win = vop_win->data;
>> +
>> + VOP_WIN_SET(vop, win, yrgb_mst, 0x0);
>> + VOP_WIN_SET(vop, win, uv_mst, 0x0);
>> + }
>> +
>
> Hi Tomeu
>
> Thanks for your fix.
>
> Set yrgb_mst and uv_mst is not a good idea, because 0x0 also is a memory
> buffer address, ddr will access the 0x0 buffer.
> I think you may enable DRM_FBDEV_EMULATION, the 0x0 address is iommu mmaped
> address for fbdev, so your test can works.
> but if DRM_FBDEV_EMULATION is not define, may be 0x0 address is unmmaped,
> would get the iommu crash.
I have checked with DRM_FBDEV_EMULATION disabled and seems to work equally well.
> I think we can use atomic disable function like this:
> for_each_plane_in_state(old_state, plane, old_plane_state, i) {
> const struct drm_plane_helper_funcs *funcs;
> funcs = plane->helper_private;
> funcs->atomic_disable(plane, old_plane_state);
> }
>
> But I think we'd better find why we need do this hack here.
>
> Does the old FB address is ummaped when crtc disabling? why plane is not
> disabled?
Planes aren't being disabled because the CRTC is being disabled
already, see http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_atomic_helper.c#L1306
Exynos is already disabling all planes when a crtc is disabled:
http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_fimd.c#L782
I don't like it because there's state in the drm core and in the
drivers that is left inconsistent.
Regards,
Tomeu
> Thanks.
>
>> spin_lock(&vop->reg_lock);
>> VOP_CTRL_SET(vop, standby, 0);
>
>
>
> --
> Ｍark Yao
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling
@ 2016-03-21 14:55 ` Tomeu Vizoso
0 siblings, 0 replies; 8+ messages in thread
From: Tomeu Vizoso @ 2016-03-21 14:55 UTC (permalink / raw)
To: linux-arm-kernel
On 19 March 2016 at 02:15, Mark yao <mark.yao@rock-chips.com> wrote:
> On 2016?03?18? 19:22, Tomeu Vizoso wrote:
>>
>> When the VOP is re-enabled, it will start scanning right away the
>> framebuffers that were configured from the last time, even if those have
>> been destroyed already. To prevent the VOP from trying to access freed
>> memory, reset the registers that hold pointers to framebuffers right
>> after we can write to them, but before the VOP is awaken from standby.
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> Link:
>> http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw at mail.gmail.com
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index 5e57f5b2e4b0..0df91c28740b 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -429,6 +429,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop
>> *vop)
>> static void vop_enable(struct drm_crtc *crtc)
>> {
>> struct vop *vop = to_vop(crtc);
>> + int i;
>> int ret;
>> if (vop->is_enabled)
>> @@ -476,6 +477,18 @@ static void vop_enable(struct drm_crtc *crtc)
>> */
>> vop->is_enabled = true;
>> + /*
>> + * Before turning the VOP completely on, unset the registers
>> + * containing FB addresses to avoid the HW start scanning old FBs.
>> + */
>> + for (i = 0; i < vop->data->win_size; i++) {
>> + struct vop_win *vop_win = &vop->win[i];
>> + const struct vop_win_data *win = vop_win->data;
>> +
>> + VOP_WIN_SET(vop, win, yrgb_mst, 0x0);
>> + VOP_WIN_SET(vop, win, uv_mst, 0x0);
>> + }
>> +
>
> Hi Tomeu
>
> Thanks for your fix.
>
> Set yrgb_mst and uv_mst is not a good idea, because 0x0 also is a memory
> buffer address, ddr will access the 0x0 buffer.
> I think you may enable DRM_FBDEV_EMULATION, the 0x0 address is iommu mmaped
> address for fbdev, so your test can works.
> but if DRM_FBDEV_EMULATION is not define, may be 0x0 address is unmmaped,
> would get the iommu crash.
I have checked with DRM_FBDEV_EMULATION disabled and seems to work equally well.
> I think we can use atomic disable function like this:
> for_each_plane_in_state(old_state, plane, old_plane_state, i) {
> const struct drm_plane_helper_funcs *funcs;
> funcs = plane->helper_private;
> funcs->atomic_disable(plane, old_plane_state);
> }
>
> But I think we'd better find why we need do this hack here.
>
> Does the old FB address is ummaped when crtc disabling? why plane is not
> disabled?
Planes aren't being disabled because the CRTC is being disabled
already, see http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_atomic_helper.c#L1306
Exynos is already disabling all planes when a crtc is disabled:
http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_fimd.c#L782
I don't like it because there's state in the drm core and in the
drivers that is left inconsistent.
Regards,
Tomeu
> Thanks.
>
>> spin_lock(&vop->reg_lock);
>> VOP_CTRL_SET(vop, standby, 0);
>
>
>
> --
> ?ark Yao
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread