Re: [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx