Re: [PATCH] drm/radeon/kms: Use surfaces for scanout / cursor byte swapping on big endian.

[Dave Airlie]

2009/9/16 Michel Dänzer <mic...@daenzer.net>:
> From: Michel Dänzer <daen...@vmware.com>
>

>
> @@ -200,6 +201,7 @@ void radeon_object_kunmap(struct radeon_object *robj)
>        }
>        robj->kptr = NULL;
>        spin_unlock(&robj->tobj.lock);
> +       radeon_object_check_tiling(robj, 0, 0);
>        ttm_bo_kunmap(&robj->kmap);
>  }
>
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index 2ba61e1..341c21a 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -802,11 +802,12 @@ struct drm_radeon_gem_create {
>        uint32_t        flags;
>  };
>
> -#define RADEON_TILING_MACRO 0x1
> -#define RADEON_TILING_MICRO 0x2
> -#define RADEON_TILING_SWAP  0x4
> -#define RADEON_TILING_SURFACE  0x8 /* this object requires a surface
> -                                   * when mapped - i.e. front buffer */
> +#define RADEON_TILING_MACRO       0x1
> +#define RADEON_TILING_MICRO       0x2
> +#define RADEON_TILING_SWAP_16BIT  0x4
> +#define RADEON_TILING_SWAP_32BIT  0x8
> +#define RADEON_TILING_SURFACE     0x10 /* this object requires a surface
> +                                       * when mapped - i.e. front buffer */
>

I know we haven't frozen API yet but this seems a bit unnecessary
to reorder, do we really need swap 16 and 32 bit? does it not
depend on other info about the buffer?

Dave.

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel