Hi Krzysztof, Le Fri 03 Apr 26, 06:36, Krzysztof Hałasa a écrit : > Paul Kocialkowski writes: > > Interestingly I tried to keep the clocks always on as an experiment and it > > had the opposite effect: the DMA engine would get confused every time after the > > first mode set and disable. So for some reason the disabling of the clocks seems > > to mitigate the issue rather than aggravate it. > > Interesting. Fortunately we have a workaround. > > >> > + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5, > >> > + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN), > >> > + 0, 36000); /* Wait ~2 frame times max */ > >> > >> I guess this comment is not necessarily correct - at 2160p30 one frame = > >> ca. 33 ms. Still works, though (I guess anything more than one frame is > >> enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can > >> take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p60. > > > > Honestly I think we're good assuming 30 fps (33 ms) is a lower bound. > > And the current 36 ms goes even beyond, so I think it's fine. > > Right. It is just the comment in the code which is not exactly true. > I.e., we "wait for at least 1 complete frame time". I guess. > Also, the 25 ms in the patch (commit) message is no longer accurate. In the end I made it 50 ms, which should be fine for all modes, and adapted the comment in v2. > >> Also, found an issue. Perhaps unrelated? Powered the board without HDMI > >> connected. Then connected 1080p60 display. It came in 1024x768, console > >> 64x24 :-) > > > > That looks more related to a failure to fetch the EDID from the monitor. > > 1024x768 is the default fallback that is used in this situation. > > Maybe check if there is something wrong with the DDC lines from the hdmi > > controller, maybe pinmux etc. > > No no no, I did that on purpose - the monitor was really disconnected at > the boot time. Only then (but before starting weston) i reconnected it. > But it indeed appears to be a separate issue, a software one - a mutex > deadlock on access to clocks and power management. Both enable and > disable paths interfere there. "I will post a patch when I have a patch > to post" :-) Okay good to know, I'll get back to you if I also see this in the future :) All the best, Paul -- Paul Kocialkowski, Independent contractor - sys-base - https://www.sys-base.io/ Free software developer - https://www.paulk.fr/ Expert in multimedia, graphics and embedded hardware support with Linux.