On 02/10/15 13:00, H. Nikolaus Schaller wrote:
Hi,
Am 02.10.2015 um 09:03 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 01/10/15 18:55, H. Nikolaus Schaller wrote:
After thinking about this in a background task, there maybe an important difference to other panel drivers (I don't see this issue on the OMAP3 with SPI/DPI panel).
I still have the DSI panel you sent me a while ago, and I can run v4.2 on omap5 uevm with both HDMI and the DSI panel working, plus X on top. And I haven't seen a single warning about atomic complete.
Well, you might use the real panel driver (not the debug driver + shell script).
I'm not using any shell scripts. I'm using panel-r63311.c driver.
We don't call in->ops.dsi->set_config() and in->ops.dsi->enable_hs() in the probe function.
They are called much later by a shell script (through a /sys interface) so that we are able to configure / tweak the panel timings to different panel setups.
Is there an implicit assumption what must be called in the panel driver's probe function?
No. Probe is just for probing the device. But you must enable the video in enable(), and disable it in disable(). Otherwise DISPC will stay disabled after enable() call, and omapdrm expects to get vsync interrupts, which it never gets.
I'm not sure what kind of tweaks you do there, but if you want runtime hacking support, perhaps this is safer way:
xset dpms force off echo yourconf > /sys/panel/foobar xset dpms force on
That way the displays are turned off properly from X, then you reconfig the panel driver, and then enable it. Of course, if you change the resolution or such that way, things will surely get messy.
I will try. But the effect appears to be independent from using X and appears before X starts.
Yes, it will happen regardless of what you are running. The point is, the display should be turned off via the proper APIs, so that omapdrm is the one turning it off and on. If you turn it off by poking the panel driver directly, you'll have problems.
If that's "true", X uses a video overlay for mouse cursor. Which is kind of unusable, as the legacy DRM API for configuring overlays is synchronous, and will lag everything as there's a _lot_ mouse events coming in.
Now, it still shouldn't cause sync lost errors from the HDMI output. I need to look at it.
Also, the pre v4.2 omapdrm had hacks to make the overlay config asynchronous, which kind of solved the hwcursor issue. But then caused other issues. So, the v4.2 behavior is kind of a regression.
It almost works now. But there is still some "lag" of intensive mouse move events. I can also see it on the omap3 device. The effect is funny: if I drag a selection rectangle and then move the mouse very fast around (while pressed), the rectangle makes nice figures :)
I have now also fixed a DT entry on the OMAP3 device with OPA362 (did need a reg = <0> property) and now have the VENC running. But it is in a strange state ("unknown connection"):
Yes, there's no detection on VENC. So it reports the cable status as unknown. Are you saying it's not working?
Tomi