[PATCH] drm/omap: fix tiled buffer stride calculations

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 18 May 2017 13:28:26 Tomi Valkeinen wrote:
> omap_gem uses page alignment for buffer stride. The related calculations
> are a bit off, though, as byte stride of 4096 gets aligned to 8192,
> instead of 4096. This patch fixes those calculations.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
> ---
>  drivers/gpu/drm/omapdrm/omap_gem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c index 13abf221d153..4c41000ff4c4
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -182,7 +182,7 @@ static void evict_entry(struct drm_gem_object *obj,
>  	size_t size = PAGE_SIZE * n;
>  	loff_t off = mmap_offset(obj) +
>  			(entry->obj_pgoff << PAGE_SHIFT);
> -	const int m = 1 + ((omap_obj->width << fmt) / PAGE_SIZE);
> +	const int m = 1 + (((omap_obj->width - 1) << fmt) / PAGE_SIZE);

How about 

	int m = round_up(omap_obj->width << fmt, PAGE_SIZE);

instead of open-coding it ? I find that a bit easier to understand.

By the way, shifting left by fmt should be fine for TILFMT_8BIT, TILFMT_16BIT 
and TILFMT_32BIT that evaluate to 0, 1 and 2 respectively, but how does it 
work with TILFMT_PAGE ? fmt is computed by gem2fmt() in call cases, which 
returns TILFMT_PAGE in the default case (no tiled flag set). Can this happen 
in practice ?

> 
>  	if (m > 1) {
>  		int i;
> @@ -424,7 +424,7 @@ static int fault_2d(struct drm_gem_object *obj,
>  	 * into account in some of the math, so figure out virtual stride
>  	 * in pages
>  	 */
> -	const int m = 1 + ((omap_obj->width << fmt) / PAGE_SIZE);
> +	const int m = 1 + (((omap_obj->width - 1) << fmt) / PAGE_SIZE);
> 
>  	/* We don't use vmf->pgoff since that has the fake offset: */
>  	pgoff = (vmf->address - vma->vm_start) >> PAGE_SHIFT;

-- 
Regards,

Laurent Pinchart