Op 04-01-17 om 17:19 schreef Chris Wilson: > 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... No, we only recover it during init. On resume we still have the old vma pinned and in plane_state. Which should be fine for our purpose, but even if we didn't resume should probably not fail. > 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. Not currently the case, but it's an implementation detail that might be changed. :) ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
