+2
−12
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
I was observing the following error messages on my OMAP1 based Amstrad Delta board when first changing from text to graphics mode or vice versa after the LCD display had been blanked: omapfb omapfb: timeout waiting for FRAME DONE with a followup error message while unblanking it back: omapfb omapfb: resetting (status 0xffffffb2,reset count 1) As a visible result, image pixels happened to be shifted by a few bits, giving wrong colors. Examining the code, I found that this problem occures when an OMAP1 internal LCD controller is disabled from omap_lcdc_suspend() and then a subsequent omap_lcdc_setup_plane() calls disable_controller() again. This potentially error provoking behaviour is triggered by the lcdc.update_mode flag being kept at OMAP_AUTO_UPDATE, regardless of the controller and panel being suspended. This patch tries to correct the problem by replacing both omap_lcdc_suspend() and omap_lcdc_resume() function bodies with single calls to omap_lcdc_set_update_mode() with a respective OMAP_UPDATE_DISABLE or OMAP_AUTO_UPDATE argument. As a result, exactly the same lower level operations are performed, with addition of changing the lcdc.update_mode flag to a value better suited for the controller state. This prevents any further calls to disable_controller() from omap_lcdc_setup_plane() while the display is suspended. Created against linux-2.6.34-rc7. Tested on Amstrad Delta. Signed-off-by:Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@nokia.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE