[PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF format.

[PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF format.

[Eric Anholt]

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.
+ */
+#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

[PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF format.

[Eric Anholt]

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

Re: [PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF format.

[Daniel Vetter]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF format.

[Daniel Vetter]

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

Re: [PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF format.

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 2179 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF format.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]