On Wed, Jan 04, 2017 at 06:06:42PM +0200, Ville Syrjälä wrote: > On Wed, Jan 04, 2017 at 04:00:49PM +0000, Chris Wilson wrote: > > If we are restoring the same plane_state, the old_plane_state will not > > be unpinned until after the swap. So prepare_fb will return the > > duplicate VMA with incremented pin_count. > > During suspend we throw away the old state, and resume will read in > the state from the hardware. So when we do the swap we won't have the > original old state in place anymore. But in this case, we should have a plane_config from HW readout that has a recovered VMA? I presume the same takeover code is run after resume as on init... On the other hand, if the plane_state was removed from the hardware, its VMA would be unpinned and we would be free to rebind it in a new location. Provided the obj itself wasn't freed, the VMA will be kept. However, we still risk a potential error on remapping (if the vma was unbound during suspend). That's not a huge risk though, and does require the VMA to be actually unbound on suspend. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
