[Intel-gfx] [PATCH 09/10] drm/i915: Migrate stolen objects before hibernation

[Chris Wilson]

On Tue, Jan 26, 2016 at 01:13:35AM +0530, ankitprasad.r.sharma at intel.com wrote:
> +	for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
> +		struct page *page;
> +		void *__iomem src;
> +		void *dst;
> +
> +		i915->gtt.base.insert_page(&i915->gtt.base,
> +					   i915_gem_object_get_dma_address(obj, i),
> +					   node.start,
> +					   I915_CACHE_NONE,
> +					   0);
> +
> +		page = shmem_read_mapping_page(mapping, i);
> +		if (IS_ERR(page)) {
> +			ret = PTR_ERR(page);
> +			break;
> +		}
> +
> +		src = io_mapping_map_atomic_wc(i915->gtt.mappable, node.start);
> +		dst = kmap_atomic(page);
> +		wmb();
> +		memcpy_fromio(dst, src, PAGE_SIZE);
> +		wmb();

I've had the unfortunate pleasure of having to review WC rules. It
should be that the current WC buffer is flushed before the next WC
access outside of the current window, but that only applies to the
current cpu (aiui).

At any rate, we should document our barriers;

wmb(); /* flush modifications to the GGTT (insert_page) */
memcpy();
wmb(); /* flush the write before we modify the GGTT */

Whether we want to explain that these should be paranoia, I'm not sure.
I like being explicit about the games we are playing with WC memory, and
putting the reasons down why we inserted a barrier will help us review
them again in future. (One of the questions in mind is where is the best
place to put the barriers after insert-page, the first wmb() here is
mainly due to my mistrust from chasing issues on byt/bsw.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre