tag:blogger.com,1999:blog-6487105202596390783.post231656822801652976..comments2023-05-22T10:39:14.072+02:00Comments on Hardware & Software Useful bits: Doubts over Rockchip FB Vsync fixUnknownnoreply@blogger.comBlogger12125tag:blogger.com,1999:blog-6487105202596390783.post-9361431543532978102013-10-17T18:03:54.069+02:002013-10-17T18:03:54.069+02:00Absolutely agree! It should be mandatory that, aft...Absolutely agree! It should be mandatory that, after a forum thread reaches some conclusion, to write that solution in a place apart in stone (or a wiki for that matter), imho :)Gallandhttps://www.blogger.com/profile/01766730761074080091noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-56662804472056346842013-10-17T17:31:45.658+02:002013-10-17T17:31:45.658+02:00Personally, I'm not such a big fan of forums a...Personally, I'm not such a big fan of forums as information is scattered over zillions of pages in between loads of irrelevant posts. I'm often annoyed myself how difficult it is to find good information. It's better than nothing though ;-)Anonymoushttps://www.blogger.com/profile/07620964751338039657noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-54463057090265636632013-10-15T14:42:27.232+02:002013-10-15T14:42:27.232+02:00Thank you! leolas told me about sam321's solut...Thank you! leolas told me about sam321's solution but I couldn't find what it was :)Gallandhttps://www.blogger.com/profile/01766730761074080091noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-65350321498835163662013-10-15T08:03:53.565+02:002013-10-15T08:03:53.565+02:00The URL should be:
https://github.com/phjanderson/...The URL should be:<br />https://github.com/phjanderson/Kernel-3188/blob/master/drivers/video/rockchip/rk_fb.c#L388Anonymoushttps://www.blogger.com/profile/07620964751338039657noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-29816076816090844882013-10-15T07:59:11.378+02:002013-10-15T07:59:11.378+02:00Hi guys,
Thanks for the analysis, but.... It'...Hi guys,<br /><br />Thanks for the analysis, but.... It's a bit outdated though, we already ditched the phjanderson fix for sam321's fix, removing the ability to disable vsync through rk_fb_ioctl:<br />https://github.com/phjanderson/Kerne...p/rk_fb.c#L388<br /><br />I do not think such fixes are necessary when running Linux on the RK3188 as the problem seems to be in a part of the android system (hwcomposer/surfaceflinger) that keeps disabling the vsync, even while playing video (probably for power saving reasons).<br /><br />PeterAnonymoushttps://www.blogger.com/profile/07620964751338039657noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-86529312609014315762013-10-15T01:25:59.527+02:002013-10-15T01:25:59.527+02:00No offense at all :)
However my fix is for a diff...No offense at all :)<br /><br />However my fix is for a different problem (lack of framebuffer console on Linux), not for the video vsync.Gallandhttps://www.blogger.com/profile/01766730761074080091noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-7345859055885752582013-10-15T01:23:15.954+02:002013-10-15T01:23:15.954+02:00I did not want to offend you in any way and you di...I did not want to offend you in any way and you did not mention in your post that you made a different fix for that problem.<br /><br />Sorry for the comments, you could delete it.Anonymoushttps://www.blogger.com/profile/03689808118500268784noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-60703789942193931762013-10-15T01:22:18.607+02:002013-10-15T01:22:18.607+02:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/03689808118500268784noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-87835073295153145232013-10-15T00:28:03.975+02:002013-10-15T00:28:03.975+02:00I've updated the post since you seem to be mis...I've updated the post since you seem to be missing the meaning of ISRs and the wait_event you're talking about. It's all kernel stuff.Gallandhttps://www.blogger.com/profile/01766730761074080091noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-72254035738050388922013-10-14T23:52:58.457+02:002013-10-14T23:52:58.457+02:00I'll try to explain..
look at https://github.c...I'll try to explain..<br />look at https://github.com/Galland/Linux3188.../rk3188_lcdc.c<br />There you find the following:<br />static irqreturn_t rk3188_lcdc_isr(intirq,void*dev_id)<br />{<br /> struct rk3188_lcdc_device *lcdc_dev = <br /> (struct rk3188_lcdc_device *)dev_id;<br /> <b>ktime_t timestamp = ktime_get();</b><br /><br /> lcdc_msk_reg(lcdc_dev, INT_STATUS, m_FS_INT_CLEAR, v_FS_INT_CLEAR(1));<br /><br /> if(lcdc_dev->driver.wait_fs) //three buffer ,no need to wait for sync<br /> {<br /> spin_lock(&(lcdc_dev->driver.cpl_lock));<br /> complete(&(lcdc_dev->driver.frame_done));<br /> spin_unlock(&(lcdc_dev->driver.cpl_lock));<br /> }<br /> <b>lcdc_dev->driver.vsync_info.timestamp = timestamp;</b><br /> wake_up_interruptible_all(&lcdc_dev->driver.vsync_info.wait);<br /><br /> return IRQ_HANDLED;<br />}<br /><br />If this runs, driver.vsync_info.timestamp is set to ktime_get() (the current timestamp)<br /><br />in rk_fb.c<br />ktime_t timestamp = dev_drv->vsync_info.timestamp;<br /> int ret = wait_event_interruptible(dev_drv->vsync_info.wait,<br /> !ktime_equal(timestamp, dev_drv->vsync_info.timestamp) &&<br /> dev_drv->vsync_info.active);<br /><br />That can not work.<br />!ktime_equal(timestamp, dev_drv->vsync_info.timestamp) <br />compares timestamp to dev_drv->vsync_info.timestamp. Both are the same.<br />This can only work if timestamp is set to current timestamp, if not, the comparison would be senseless.<br />The comparison is made to prevent to trigger the event every time the loop is run, it should only be run if timestamp has changed.<br /><br />I hope you understand the point?Anonymoushttps://www.blogger.com/profile/03689808118500268784noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-52220883935865615362013-10-14T23:37:02.649+02:002013-10-14T23:37:02.649+02:00Thanks very much for the advanced insight! however...Thanks very much for the advanced insight! however I'm not sure I follow your thought.<br /><br />From my point of view, since timestamp is a "constant" (doesn't change) in that comparison, whereas "dev_drv->vsync_info.timestamp" is a device variable that changes (it holds the last Vsync time every time it's checked), the condition may indeed become true: upon next Vsync, as apparently expected :S<br />Gallandhttps://www.blogger.com/profile/01766730761074080091noreply@blogger.comtag:blogger.com,1999:blog-6487105202596390783.post-28759504675495619442013-10-14T22:35:19.812+02:002013-10-14T22:35:19.812+02:00Hi Galland,
I think I have found the problem with ...Hi Galland,<br />I think I have found the problem with the vsync and the mentioned fix of phjanderson.<br />The fix of phjanderson was to remove <b>!ktime_equal(timestamp, dev_drv->vsync_info.timestamp) &&</b> in rk_fb.c.<br />Cause this is part of a while loop, it leads to permanently vsyncs, every loop. The reason for the deleted part was, to prevent exactly this, by comparing last vsync timestamp with current timestamp, and only if timestamps are not equal to trigger the vsync.<br />After looking at the code, I think the problem has to be fixed another way. Look 2 lines above the if statement in rk_fb.c.<br /><b>ktime_t timestamp = dev_drv->vsync_info.timestamp;</b><br /><br />This leads to <b>!ktime_equal(timestamp, dev_drv->vsync_info.timestamp)</b> never to be true.<br /><br />I think it should be more like this:<br /><br /><b>ktime_t timestamp = ktime_get(); //This should set the timestamp on a correct value for comparison</b><br /><br />I hope that it helps, cause I don't have a RK3188 to test it on my own.<br /><br />Best Regards<br />JochenKauz<br />Anonymoushttps://www.blogger.com/profile/03689808118500268784noreply@blogger.com