On 11/16/15 18:06, Daniel Vetter wrote: > On Thu, Nov 05, 2015 at 05:03:09PM +0200, Jyri Sarha wrote: >> Disable planes if they are on to be blanked CRTC and enable them when >> the CRTC is turned back on by DMPS. >> >> This is desirable on HW that loses its context on blanking. When >> planes are enabled and disabled with the associated CRTCs, there is no >> need to restore the plane context in runtime_resume callback. >> >> Signed-off-by: Jyri Sarha <jsarha at ti.com> >> --- >> We would need something like this to get rid off OMAPDSS somewhat >> messy runtime_resume code. How does this look, could this generic >> solution be refined to be acceptable to mainline, or should we start >> looking a local solution to omapdrm? >> >> BTW, with this patch the planes are sometimes disabled multiple >> times. So probably a boolean (or maybe two like on crtc) should be >> added to drm_plane_state to track and avoid multiple shutdowns. > > The recommended way to do this is to call drm_atomic_add_affected_planes > from your crtc's atomic_check callback when active_changed is set. This > will also take care of enabling all planes again. For disabling we don't > yet have a helper yet, but it would be easy to create a > drm_atomic_helper_disable_planes(crtc) which just walks over all planes in > an atomic update that are currently using the given crtc and disables it > using plane_helper_funcs->atomic_disable. That would again require > drm_atomic_add_affected_planes to be called first. > > This way current helper behaviour is unchanged, but it'd be easy to > construct the behaviour you want using helpers with > drm_atomic_add_affected_planes called from the crtc->disable hook. > > I thought there was an rfc patch somewhere for this, but I can't find it > any more.
It appears that in the end these instructions were really all I needed. There is only one thing that still bothers me. When implementing the feature you described above, I had a print in the code to see if it actually did anything. At first - because of my mistake - it did not, but the plane context was still restored just fine on drm_next and mainline linux. However the same omapdrm code did not restore the plane context on our 4.1 based Linux branch. So something similar to what I tried to accomplish has been implemented some where between Linux 4.1 and 4.3? Anyway, after back-porting the above fix works perfectly on our 4.1 based branch. Thanks, Jyri
