2016-11-16 19:00 GMT+01:00 Jyri Sarha <jsarha@xxxxxx>: > On 11/16/16 17:18, Bartosz Golaszewski wrote: >> 2016-11-16 13:40 GMT+01:00 Jyri Sarha <jsarha@xxxxxx>: >>> Changes since first version of the series: >>> >>> - Move tilcdc_regs.h changes from "drm/tilcdc: Enable palette loading >>> for revision 2 LCDC too" to "drm/tilcdc: Add tilcdc_write_mask() to >>> tilcdc_regs.h" >>> >>> These patches are inspired by this series form Bartosz Golaszewski: >>> https://www.spinics.net/lists/arm-kernel/msg539629.html >>> >>> The patches are based on drm-next plus the earlier patches that I plan >>> to send in a pull request for 4.10. The base + these patches are >>> pushed here: >>> >>> https://github.com/jsarha/linux drm-next-tilcdc-for-4.10-wip >>> >>> Bartosz, please test if this branch works for rev1 LCDC, with your dts >>> file! >>> >> >> Hi Jyri, >> >> with your changes I'm getting the following warning on initialization: >> >> [drm] Initialized >> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [drm] No driver support for vblank timestamp query. >> ------------[ cut here ]------------ >> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1141 >> drm_atomic_helper_wait_for_vblanks+0x23c/0x24c >> [CRTC:24] vblank wait timed out >> Modules linked in: >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc4-00939-ge79af2c #60 >> Hardware name: Generic DA850/OMAP-L138/AM18x >> Backtrace: >> [snip] >> >> and the same when running simple modetest (no vsynced page flipping). >> > > Weird. I have never seen that warning. Are you receiving > LCDC_END_OF_FRAME0 interrupts at all? > I'm only getting three right after drm initialization and then, something seems to be disabling them (maybe as the result of vblank timeout?). > Am I missing some interrupt enable bit for rev 1 LCDC? > Rather the interrupt is disabled after being enabled first. > AFAIK the drm_crtc_send_vblank_event() should get called for the drm > atomic state even when the LCDC_END_OF_FRAME0 interrupt is received and > the (mandatory) framebuffer is on the screen. > I'll investigate that, thanks for the hint. >> The default resolution still works and I can start a graphical environment. >> > > Was this with the panel hack or using dumb-vga-dac bridge? > Yes, still the panel hack. I'll test the vga-dac after I can sort out this issue. Thanks, Bartosz _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
