drm/v3d: Define the fourcc modifier for the Broadcom UIF format.
diff mbox

Message ID 20180621001703.13522-1-eric@anholt.net
State New
Headers show

Commit Message

Eric Anholt June 21, 2018, 12:17 a.m. UTC
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(+)

Comments

Daniel Vetter June 21, 2018, 6:54 a.m. UTC | #1
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
Eric Anholt June 21, 2018, 5:15 p.m. UTC | #2
Daniel Vetter <daniel@ffwll.ch> writes:

> 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>

Yeah, this is very similar to the Intel swizzling.

Patch
diff mbox

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.
+ */
+#define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
+
 #if defined(__cplusplus)
 }
 #endif