Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxxxx>
>> ---
>> 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@xxxxxxxx>
Yeah, this is very similar to the Intel swizzling.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
