[PATCH 10/13] drm/msm: Support multiple ringbuffers

[Jordan Crouse]

On Mon, May 08, 2017 at 02:35:06PM -0600, Jordan Crouse wrote:
> -#define rbmemptr(adreno_gpu, member)  \
> +#define _sizeof(member) \
> +	sizeof(((struct adreno_rbmemptrs *) 0)->member[0])
> +
> +#define _base(adreno_gpu, member)  \
>  	((adreno_gpu)->memptrs_iova + offsetof(struct adreno_rbmemptrs, member))
>  
> +#define rbmemptr(adreno_gpu, index, member) \
> +	(_base((adreno_gpu), member) + ((index) * _sizeof(member)))
> +
>  struct adreno_rbmemptrs {
> -	volatile uint32_t rptr;
> -	volatile uint32_t fence;
> +	volatile uint32_t rptr[MSM_GPU_MAX_RINGS];
> +	volatile uint32_t fence[MSM_GPU_MAX_RINGS];
>  };

I'm looking for opinions on moving this to a per-ring buffer object. It would be
a lot simpler to understand but it would cost us a page per ring as opposed
to the 1 page we use now.

Looking ahead we are going to want to start using trace messages in conjunction
with tools like systrace:

(https://developer.android.com/studio/profile/systrace-commandline.html)

This will involve tracking the always on counter value at start/retire for each
outstanding submit on each ring. I *think* we could fit those values into the
existing rmemptrs buffer if we wanted to but I can't imagine these would be the
last runtime statistics we would gather.

I guess I'm leaning toward the per-ring solution but I'll listen to anybody
argue that the memory usage isn't worth it.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project