[Intel-gfx] [PATCH 17/20] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer

[Tvrtko Ursulin]

On 12/08/16 07:25, akash.goel at intel.com wrote:
> From: Akash Goel <akash.goel at intel.com>
>
> Host needs to sample the GuC log buffer on every flush interrupt from GuC.
> To ensure that we always get the up-to-date data from log buffer, its
> better to access the buffer through an uncached CPU mapping. Also the way
> buffer is accessed from GuC & Host side, manually doing cache flush may
> not be effective always if cached CPU mapping is used.
> Though there could be some performance implication with Uncached read, but
> reliability of data will be ensured.
>
> v2: Rebase.
>
> v3: Rebase.
>
> Signed-off-by: Akash Goel <akash.goel at intel.com>
> ---
>   drivers/gpu/drm/i915/i915_guc_submission.c | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 1d58d36..1818343 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1002,8 +1002,6 @@ static void guc_read_update_log_buffer(struct intel_guc *guc)
>   			dst_data_ptr += buffer_size;
>   		}
>
> -		/* FIXME: invalidate/flush for log buffer needed */
> -
>   		/* Update the read pointer in the shared log buffer */
>   		log_buffer_state->read_ptr = write_offset;
>
> @@ -1177,8 +1175,11 @@ static int guc_create_log_extras(struct intel_guc *guc)
>   		return 0;
>
>   	if (!guc->log.buf_addr) {
> -		/* Create a vmalloc mapping of log buffer pages */
> -		vaddr = i915_gem_object_pin_map(guc->log.obj, I915_MAP_WB);
> +		/* Create a WC (Uncached for read) vmalloc mapping of log
> +		 * buffer pages, so that we can directly get the data
> +		 * (up-to-date) from memory.
> +		 */
> +		vaddr = i915_gem_object_pin_map(guc->log.obj, I915_MAP_WC);
>   		if (IS_ERR(vaddr)) {
>   			ret = PTR_ERR(vaddr);
>   			DRM_ERROR("Couldn't map log buffer pages %d\n", ret);
>

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Hopefully no one applies this without 19/20. :)

Regards,

Tvrtko