<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 5, 2012 at 5:33 PM, Eunchul Kim <span dir="ltr"><<a href="mailto:chulspro.kim@samsung.com" target="_blank">chulspro.kim@samsung.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Prathyush<br>
<br>
Thank's your clarification.<br>
<br>
I have one opinion about your [PATCH 1/3]<br>
How about to add atomic_read() condition in each irq_handler ?<br>
like this.<br>
<br>
e.g)<br></blockquote><div><br></div><div>Hi Eunchul,</div><div><br></div><div>Yes, I think this is better. I'll modify this in the next patch version and post tomorrow.</div><div><br></div><div>Thanks for reviewing.</div>
<div><br></div><div>Regards,</div><div>Prathyush</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+       if (atomic_read(&ctx->wait_vsync_<u></u>event)) {<br>
+               /* set wait vsync event to zero and wake up queue. */<br>
+               atomic_set(&ctx->wait_vsync_<u></u>event, 0);<br>
+               DRM_WAKEUP(&ctx->wait_vsync_<u></u>queue);<br>
+       }<br>
<br>
I lost your PATCH mail. so, I send my comment using this body mail.<br>
<br>
Thank's<br>
BR<span class="HOEnZb"><font color="#888888"><br>
<br>
Eunchul Kim.</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 12/05/2012 04:27 PM, Inki Dae wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2012/12/5 Inki Dae <<a href="mailto:inki.dae@samsung.com" target="_blank">inki.dae@samsung.com</a>><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2012/12/5 Inki Dae <<a href="mailto:inki.dae@samsung.com" target="_blank">inki.dae@samsung.com</a>><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2012/12/5 Prathyush K <<a href="mailto:prathyush@chromium.org" target="_blank">prathyush@chromium.org</a>><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae <<a href="mailto:inki.dae@samsung.com" target="_blank">inki.dae@samsung.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2012/12/5 Inki Dae <<a href="mailto:inki.dae@samsung.com" target="_blank">inki.dae@samsung.com</a>><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2012/12/5 Prathyush K <<a href="mailto:prathyush.k@samsung.com" target="_blank">prathyush.k@samsung.com</a>><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patchset fixes a few issues with use of wait for vblank in<br>
exynos drm.<br>
<br>
Please apply these three patches without "drm/exynos: release fb<br>
pended by page flip"<br>
patch.<br>
<br>
Patch 1: modify wait for vsync functions to use wait queues<br>
This modifies the wait_for_vblank functions to use wait queues<br>
thus ensuring that the current task goes to sleep without taking<br>
up CPU while waiting.<br>
<br>
Patch 2: move wait_for_vblank to manager_ops<br>
Currently, we do not call wait for vblank if encoder is in DPMS_OFF<br>
state inside exynos_drm_encoder_complete_<u></u>scanout function. This is<br>
because wait for vblank is treated as an overlay op.<br>
</blockquote>
<br>
This can be<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
modified to a manager_op thus removing the above check for DPMS_OFF.<br>
This fixes a crash while removing a fb.<br>
While removing the current fb (crtc->fb == fb) the encoder<br>
dpms off is called and then the framebuffer is removed. So in<br>
this case, the wait for vblank is not called thus leading to a crash<br>
(since fb might get removed before dma is finished)<br>
<br>
Patch 3: do not disable crtc if already off<br>
We should not disable the overlay if the crtc is in DPMS_OFF state.<br>
Also, the disable function should not call DPMS_OFF of the crtc.<br>
This is required to ensure we are able to wait for vblank<br>
before freeing any framebuffers after disabling the crtc.<br>
<br>
With these three patches and without "drm/exynos: release fb pended<br>
by page flip"<br>
I could not find any crash/page_fault in drm with fimd/hdmi during<br>
hotplug<br>
and page flips.<br>
<br>
<br>
</blockquote>
It seems better than old one and also including some exception codes,<br>
Patch 3 we did't consider. Ok, we will test these patches and merge them<br>
instead of old one if no problem.<br>
<br>
<br>
</blockquote>
<br>
Tested and worked fine. But with this patch and without "drm/exynos:<br>
release fb pended by page flip", we would still have potential issue to<br>
page fault like below,<br>
1. dma is accessing no current fb<br>
2. the fb to be released is not current fb so the fb would be released<br>
without disabling crtc when drm is released.<br>
3. but the memory region to no current fb is being accessed by the dma<br>
so the page fault would be induced. This is a rare case but possible issue.<br>
<br>
Hi Mr. Dae,<br>
</blockquote>
<br>
But we would not release the fb till we get a vblank (i.e. wait for<br>
vblank is called before removing every framebuffer).<br>
<br>
Taking your example itself:<br>
<br>
fb0 is current fb i.e. (crtc->fb = fb0).<br>
<br>
But the dma is accessing from fb1.<br>
<br>
We call remove fb1.<br>
<br>
In this case, as you said, crtc will not be disabled as fb1 is not<br>
current fb.<br>
<br>
But we wait for vblank before removing fb1. Thus we ensure that dma from<br>
fb1 is complete and dma from fb0 has started.<br>
So it is safe to remove fb1.<br>
<br>
</blockquote>
<br>
Please, see the below codes,<br>
<br>
drm_release()<br>
         drm_fb_release()<br>
                 drm_framebuffer_remove()<br>
                         /* assume that current fb is fb1 and dma is<br>
accessing fb0 but trying to release fb0 at here */<br>
                         /* this situation could be reproduced with<br>
pageflip test. */<br>
                         fb0 is not crtc->fb so the crtc isn't disabled<br>
                         ...<br>
                         drm_framebuffer_unreference(<u></u>fb0);  <- fb0 will be<br>
released without wait_for_vblank().<br>
<br>
The wait_for_vblank() is called by exynos_drm_encoder_complete_<u></u>scanout()<br>
when fb->func->destroy() is called so the wait_for_vblank() will be called<br>
after fb0 is released.<br>
Is there another place that wait_for_vblank() is called?<br>
<br>
<br>
</blockquote>
Ah, sorry~. exynos_drm_encoder_<u></u>completescanout() is called prior to gem<br>
releasing. Right, no problem. :)<br>
<br>
Thanks,<br>
Inki Dae<br>
<br>
<br>
</blockquote>
<br>
In addition,<br>
<br>
I had added exynos_drm_encoder_complete_<u></u>scanout() function to resolve this<br>
issue. but it seems like that previous patch didn't perform wait_for_vblank<br>
correctly. Anyway this is just exynos specific code. so I hope maybe<br>
Daniel's fixup can resolve this issue in drm core.<br>
<br>
Thanks,<br>
Inki Dae<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Inki Dae<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hope I correctly understood the issue you mentioned.<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway I removed the patch, "drm/exynos: release fb pended by page<br>
flip". And I hope this issue can be resolved by Daniel's fixup later.<br>
<br>
And I think it's better to separate your patch set into 4 patches like<br>
below,<br>
1. the patch including only exynos drm framework part.<br>
2. the patch including only fimd driver part.<br>
3. the patch including only hdmi driver part.<br>
4. the patch including exception code.(previous Patch 3)<br>
<br>
Please, re-send them.<br>
<br>
Sure. I'll post them again as requested.<br>
</blockquote>
<br>
Regards,<br>
Prathyush<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Inki Dae<br>
<br>
  Thanks,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Inki Dae<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Prathyush K (3)<br>
   drm/exynos: modify wait for vsync functions to use wait queues<br>
   drm/exynos: move wait_for_vblank to manager_ops<br>
   drm/exynos: do not disable crtc if already off<br>
<br>
  drivers/gpu/drm/exynos/exynos_<u></u>drm_crtc.c    |    6 +++-<br>
  drivers/gpu/drm/exynos/exynos_<u></u>drm_drv.h     |   20 ++------------<br>
  drivers/gpu/drm/exynos/exynos_<u></u>drm_encoder.c |   15 +++--------<br>
  drivers/gpu/drm/exynos/exynos_<u></u>drm_fimd.c    |   37<br>
++++++++++++++++++--------<br>
  drivers/gpu/drm/exynos/exynos_<u></u>drm_hdmi.c    |   22 ++++++++--------<br>
  drivers/gpu/drm/exynos/exynos_<u></u>drm_hdmi.h    |    2 +-<br>
  drivers/gpu/drm/exynos/exynos_<u></u>mixer.c       |   37<br>
+++++++++++++++++---------<br>
  7 files changed, 73 insertions(+), 66 deletions(-)<br>
<br>
______________________________<u></u>_________________<br>
dri-devel mailing list<br>
<a href="mailto:dri-devel@lists.freedesktop.org" target="_blank">dri-devel@lists.freedesktop.<u></u>org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/dri-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/dri-devel</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
dri-devel mailing list<br>
<a href="mailto:dri-devel@lists.freedesktop.org" target="_blank">dri-devel@lists.freedesktop.<u></u>org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/dri-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/dri-devel</a><br>
<br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
dri-devel mailing list<br>
<a href="mailto:dri-devel@lists.freedesktop.org" target="_blank">dri-devel@lists.freedesktop.<u></u>org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/dri-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/dri-devel</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
dri-devel mailing list<br>
<a href="mailto:dri-devel@lists.freedesktop.org" target="_blank">dri-devel@lists.freedesktop.<u></u>org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/dri-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/dri-devel</a><br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>