[PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Tomeu Vizoso]

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);
+	}
+
 	spin_lock(&vop->reg_lock);
 
 	VOP_CTRL_SET(vop, standby, 0);
-- 
2.5.0

[PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Tomeu Vizoso]

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);
+	}
+
 	spin_lock(&vop->reg_lock);
 
 	VOP_CTRL_SET(vop, standby, 0);
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Tomeu Vizoso]

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);
+	}
+
 	spin_lock(&vop->reg_lock);
 
 	VOP_CTRL_SET(vop, standby, 0);
-- 
2.5.0

Re: [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Mark yao]

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

Re: [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Mark yao]

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


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Mark yao]

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

Re: [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Tomeu Vizoso]

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

Re: [PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Tomeu Vizoso]

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

[PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Tomeu Vizoso]

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