Hi, > > https://lists.freedesktop.org/archives/dri-devel/2016-May/108772.html > > Hm, smells more like virtio isn't too happy with the default ordering of > the commit operation. The default is: > > - Disable any crtc/encoders that need to be disabled/change. > - Bash new plane setup into hw. > - Enable all crtcs/encoders that need to be enabled/have changed. > > There's two problems: > - some hw gets real grumpy if you bash in plane state without the crtc > state yet matching. > - if you do runtime pm nothing is enabled and the writes get lost at best, > or hang your interconnect at worst. > > That's why you can overwrite atomic_commit_tail, and use something more > sensible. See for example what it looks like for rockchip. I have a gut > feeling that should also take care of your troubles. Using the old crtc is > definitely not what you want. > Another option is that virtio isn't happy about bashing in plane state for > disabled crtc. Again helpers have you covered, look at the active_only > parameter for drm_atomic_helper_commit_planes(). virtio-gpu is a bit simplified compared to real hardware, so there isn't really separate plane/crtc state. Right now the virtual outputs are linked to drm_crtc. To apply any changes I need to lookup the crtc to figure which virtual output should be updated. So, setting active_only should make sure I have a valid crtc pointer on plane updates, right? It probably also skips the disable + enable crtc steps on commit? What happens when outputs are disabled? Maybe it makes sense to link our virtual outputs to (primary) planes not crtcs? cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
