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.
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.
And touch screen is unuseable - looks as if something gets flooded by touch events:
[ 367.402778] omap_crtc_error_irq: 140957 callbacks suppressed [ 367.408760] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.415975] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.435473] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.442665] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.468852] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000
The effect is screen flicker and the X mouse cursor lagging 1-2 seconds behind.
Completely disappears in OMAPFB mode.
I see this also. In xorg config, "Device" section, do:
Option "HWcursor" "False"
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.
Tomi