Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 21 Jun 2018 08:54:00 +0200
From:   Daniel Vetter <daniel@ffwll.ch>
To:     Eric Anholt <eric@anholt.net>
Cc:     dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF
 format.
Message-ID: <20180621065359.GE19791@phenom.ffwll.local>
Mail-Followup-To: Eric Anholt <eric@anholt.net>,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
References: <20180621001703.13522-1-eric@anholt.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180621001703.13522-1-eric@anholt.net>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jun 20, 2018 at 05:17:03PM -0700, Eric Anholt wrote:
> This will be used by Mesa, and potentially other drivers in the
> future, to describe tiled buffers.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>  include/uapi/drm/drm_fourcc.h | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 64bf67abff7e..d5e52350a3aa 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -464,6 +464,27 @@ extern "C" {
>  #define DRM_FORMAT_MOD_BROADCOM_SAND256 \
>  	DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(0)
>  
> +/* Broadcom UIF format
> + *
> + * This is the common format for the current Broadcom multimedia
> + * blocks, including V3D 3.x and newer, newer video codecs, and
> + * displays.
> + *
> + * The image consists of utiles (64b blocks), UIF blocks (2x2 utiles),
> + * and macroblocks (4x4 UIF blocks).  Those 4x4 UIF block groups are
> + * stored in columns, with padding between the columns to ensure that
> + * moving from one column to the next doesn't hit the same SDRAM page
> + * bank.
> + *
> + * To calculate the padding, it is assumed that each hardware block
> + * and the software driving it knows the platform's SDRAM page size,
> + * number of banks, and XOR address, and that it's identical between
> + * all blocks using the format.  This tiling modifier will use XOR as
> + * necessary to reduce the padding.  If a hardware block can't do XOR,
> + * the assumption is that a no-XOR tiling modifier will be created.
> + */

I think for as long as a modifier is only for a specific SoC, and not e.g.
also meant for pci devices, it's perfectly fine to heavily rely on
platform specific "every block agrees" language like here. We do the same
for intel's X/Y tiling on older chips (latest gens stopped doing funky
swizzling because the memory controllers seem to be better).

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> +#define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> -- 
> 2.17.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch