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

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

2009-09-16 Thread Michel Dänzer

On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote: 
 2009/9/16 Michel Dänzer mic...@daenzer.net:
  From: Michel Dänzer daen...@vmware.com
 
  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_tflags;
   };
 
  -#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, 

Actually, I'm not sure what the problem is, AFAICT userspace doesn't use
the RADEON_TILING_SURFACE flag at all yet. (I know that's a bug, I have
a pending corresponding X driver patch that will fix it)

 do we really need swap 16 and 32 bit? does it not depend on other info
 about the buffer?

A similar argument could be made against the separate macro / micro
tiling flags?


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
Come build with us! The BlackBerryreg; 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

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

2009-09-16 Thread Dave Airlie

2009/9/16 Michel Dänzer mic...@daenzer.net:
 On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
 2009/9/16 Michel Dänzer mic...@daenzer.net:
  From: Michel Dänzer daen...@vmware.com
 
  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,

 Actually, I'm not sure what the problem is, AFAICT userspace doesn't use
 the RADEON_TILING_SURFACE flag at all yet. (I know that's a bug, I have
 a pending corresponding X driver patch that will fix it)

Yeah I have code that uses it just not pushed out, we should be using it
for front buffer allocs at least.


 do we really need swap 16 and 32 bit? does it not depend on other info
 about the buffer?

 A similar argument could be made against the separate macro / micro
 tiling flags?

Not really, you can't tell macro/micro without being told them, I thought
the buffer bpp for swap would tell enough, we could pass it in if we
aren't doing so, but if we aren't and we can't see any other need
then two flags are fine.

Dave.


 --
 Earthling Michel Dänzer           |                http://www.vmware.com
 Libre software enthusiast         |          Debian, X and DRI developer


--
Come build with us! The BlackBerryreg; 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

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

2009-09-16 Thread Michel Dänzer

On Wed, 2009-09-16 at 17:13 +1000, Dave Airlie wrote: 
 2009/9/16 Michel Dänzer mic...@daenzer.net:
  On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
  2009/9/16 Michel Dänzer mic...@daenzer.net:
   From: Michel Dänzer daen...@vmware.com
  
   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_tflags;
};
  
   -#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,
 
  Actually, I'm not sure what the problem is, AFAICT userspace doesn't use
  the RADEON_TILING_SURFACE flag at all yet. (I know that's a bug, I have
  a pending corresponding X driver patch that will fix it)
 
 Yeah I have code that uses it just not pushed out, we should be using it
 for front buffer allocs at least.

Right, below are the relevant parts of my X driver patch.


  do we really need swap 16 and 32 bit? does it not depend on other info
  about the buffer?
 
  A similar argument could be made against the separate macro / micro
  tiling flags?
 
 Not really, you can't tell macro/micro without being told them, I thought
 the buffer bpp for swap would tell enough, we could pass it in if we
 aren't doing so, but if we aren't and we can't see any other need
 then two flags are fine.

radeon_bo_open() doesn't take the bpp, so the kernel can't really know
it. Also I suspect that the bpp alone without more information such as
formats won't be useful for other things, but it's hard to tell without
knowing what those other things would be.

So, is there anything left for me to do for this?


diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index e6b948c..e8e14ae 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -915,6 +915,7 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, int 
height)
int screen_size;
int cpp = info-CurrentLayout.pixel_bytes;
struct radeon_bo *front_bo;
+   uint32_t tiling_flags = 0;
 
if (scrn-virtualX == width  scrn-virtualY == height)
return TRUE;
@@ -948,6 +950,22 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, int 
height)
if (!info-front_bo)
goto fail;
 
+if (info-allowColorTiling)
+   tiling_flags |= RADEON_TILING_MACRO;
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+   switch (cpp) {
+   case 4:
+   tiling_flags |= RADEON_TILING_SWAP_32BIT;
+   break;
+   case 2:
+   tiling_flags |= RADEON_TILING_SWAP_16BIT;
+   break;
+   }
+#endif
+   if (tiling_flags)
+radeon_bo_set_tiling(info-front_bo,
+tiling_flags | RADEON_TILING_SURFACE, pitch * 
cpp);
+
ret = drmModeAddFB(drmmode-fd, width, height, scrn-depth,
   scrn-bitsPerPixel, pitch * cpp,
   info-front_bo-handle,
diff --git a/src/radeon_drm.h b/src/radeon_drm.h
index f974e19..49a5f81 100644
--- a/src/radeon_drm.h
+++ b/src/radeon_drm.h
@@ -802,9 +802,10 @@ struct drm_radeon_gem_create {
 
 #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_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 */
 
 struct drm_radeon_gem_set_tiling {
uint32_thandle;
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index faa0cfd..95247bb 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -855,6 +880,11 @@ static Bool radeon_setup_kernel_mem(ScreenPtr pScreen)
 return FALSE;
 }
 
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+   radeon_bo_set_tiling(info-cursor_bo[c], 
RADEON_TILING_SWAP_32BIT |
+RADEON_TILING_SURFACE, stride);
+#endif
+
 if (radeon_bo_map(info-cursor_bo[c], 1)) {
 ErrorF(Failed to map cursor buffer memory\n);
 }
@@ -875,6 +905,8 @@ static Bool radeon_setup_kernel_mem(ScreenPtr pScreen)

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

2009-09-16 Thread Dave Airlie

2009/9/16 Michel Dänzer mic...@daenzer.net:
 On Wed, 2009-09-16 at 17:13 +1000, Dave Airlie wrote:
 2009/9/16 Michel Dänzer mic...@daenzer.net:
  On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
  2009/9/16 Michel Dänzer mic...@daenzer.net:
   From: Michel Dänzer daen...@vmware.com
  
   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,
 
  Actually, I'm not sure what the problem is, AFAICT userspace doesn't use
  the RADEON_TILING_SURFACE flag at all yet. (I know that's a bug, I have
  a pending corresponding X driver patch that will fix it)

 Yeah I have code that uses it just not pushed out, we should be using it
 for front buffer allocs at least.

 Right, below are the relevant parts of my X driver patch.


  do we really need swap 16 and 32 bit? does it not depend on other info
  about the buffer?
 
  A similar argument could be made against the separate macro / micro
  tiling flags?

 Not really, you can't tell macro/micro without being told them, I thought
 the buffer bpp for swap would tell enough, we could pass it in if we
 aren't doing so, but if we aren't and we can't see any other need
 then two flags are fine.

 radeon_bo_open() doesn't take the bpp, so the kernel can't really know
 it. Also I suspect that the bpp alone without more information such as
 formats won't be useful for other things, but it's hard to tell without
 knowing what those other things would be.

 So, is there anything left for me to do for this?

Nope seems fine, I was going to suggest adding bpp to the set_tiling
call not the open, but its easier to just expose the two flags.

I'll push this one in later.

Dave.


 diff --git a/src/drmmode_display.c b/src/drmmode_display.c
 index e6b948c..e8e14ae 100644
 --- a/src/drmmode_display.c
 +++ b/src/drmmode_display.c
 @@ -915,6 +915,7 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, int 
 height)
        int screen_size;
        int cpp = info-CurrentLayout.pixel_bytes;
        struct radeon_bo *front_bo;
 +       uint32_t tiling_flags = 0;

        if (scrn-virtualX == width  scrn-virtualY == height)
                return TRUE;
 @@ -948,6 +950,22 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, 
 int height)
        if (!info-front_bo)
                goto fail;

 +        if (info-allowColorTiling)
 +           tiling_flags |= RADEON_TILING_MACRO;
 +#if X_BYTE_ORDER == X_BIG_ENDIAN
 +       switch (cpp) {
 +       case 4:
 +           tiling_flags |= RADEON_TILING_SWAP_32BIT;
 +           break;
 +       case 2:
 +           tiling_flags |= RADEON_TILING_SWAP_16BIT;
 +           break;
 +       }
 +#endif
 +       if (tiling_flags)
 +            radeon_bo_set_tiling(info-front_bo,
 +                                tiling_flags | RADEON_TILING_SURFACE, pitch 
 * cpp);
 +
        ret = drmModeAddFB(drmmode-fd, width, height, scrn-depth,
                           scrn-bitsPerPixel, pitch * cpp,
                           info-front_bo-handle,
 diff --git a/src/radeon_drm.h b/src/radeon_drm.h
 index f974e19..49a5f81 100644
 --- a/src/radeon_drm.h
 +++ b/src/radeon_drm.h
 @@ -802,9 +802,10 @@ struct drm_radeon_gem_create {

  #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_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 */

  struct drm_radeon_gem_set_tiling {
        uint32_t        handle;
 diff --git a/src/radeon_kms.c b/src/radeon_kms.c
 index faa0cfd..95247bb 100644
 --- a/src/radeon_kms.c
 +++ b/src/radeon_kms.c
 @@ -855,6 +880,11 @@ static Bool radeon_setup_kernel_mem(ScreenPtr pScreen)
                     return FALSE;
                 }

 +#if X_BYTE_ORDER == X_BIG_ENDIAN
 +               radeon_bo_set_tiling(info-cursor_bo[c], 
 RADEON_TILING_SWAP_32BIT |
 +

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

2009-09-15 Thread Michel Dänzer

From: Michel Dänzer daen...@vmware.com

Signed-off-by: Michel Dänzer daen...@vmware.com
---
 drivers/gpu/drm/radeon/r100.c  |5 ++
 drivers/gpu/drm/radeon/radeon_fb.c |  121 +---
 drivers/gpu/drm/radeon/radeon_object.c |2 +
 include/drm/radeon_drm.h   |   11 ++--
 4 files changed, 31 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index fa0fdc1..737970b 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2235,6 +2235,11 @@ int r100_set_surface_reg(struct radeon_device *rdev, int 
reg,
flags |= R300_SURF_TILE_MICRO;
}
 
+   if (tiling_flags  RADEON_TILING_SWAP_16BIT)
+   flags |= RADEON_SURF_AP0_SWP_16BPP | RADEON_SURF_AP1_SWP_16BPP;
+   if (tiling_flags  RADEON_TILING_SWAP_32BIT)
+   flags |= RADEON_SURF_AP0_SWP_32BPP | RADEON_SURF_AP1_SWP_32BPP;
+
DRM_DEBUG(writing surface %d %d %x %x\n, reg, flags, offset, 
offset+obj_size-1);
WREG32(RADEON_SURFACE0_INFO + surf_index, flags);
WREG32(RADEON_SURFACE0_LOWER_BOUND + surf_index, offset);
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index ada4169..28818eb 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -45,68 +45,6 @@ struct radeon_fb_device {
struct radeon_device*rdev;
 };
 
-static int radeon_fb_check_var(struct fb_var_screeninfo *var,
-  struct fb_info *info)
-{
-   int ret;
-   ret = drm_fb_helper_check_var(var, info);
-   if (ret)
-   return ret;
-
-   /* big endian override for radeon endian workaround */
-#ifdef __BIG_ENDIAN
-   {
-   int depth;
-   switch (var-bits_per_pixel) {
-   case 16:
-   depth = (var-green.length == 6) ? 16 : 15;
-   break;
-   case 32:
-   depth = (var-transp.length  0) ? 32 : 24;
-   break;
-   default:
-   depth = var-bits_per_pixel;
-   break;
-   }
-   switch (depth) {
-   case 8:
-   var-red.offset = 0;
-   var-green.offset = 0;
-   var-blue.offset = 0;
-   var-red.length = 8;
-   var-green.length = 8;
-   var-blue.length = 8;
-   var-transp.length = 0;
-   var-transp.offset = 0;
-   break;
-   case 24:
-   var-red.offset = 8;
-   var-green.offset = 16;
-   var-blue.offset = 24;
-   var-red.length = 8;
-   var-green.length = 8;
-   var-blue.length = 8;
-   var-transp.length = 0;
-   var-transp.offset = 0;
-   break;
-   case 32:
-   var-red.offset = 8;
-   var-green.offset = 16;
-   var-blue.offset = 24;
-   var-red.length = 8;
-   var-green.length = 8;
-   var-blue.length = 8;
-   var-transp.length = 8;
-   var-transp.offset = 0;
-   break;
-   default:
-   return -EINVAL;
-   }
-   }
-#endif
-   return 0;
-}
-
 static int radeonfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
 {
struct radeon_fb_device *rfbdev = info-par;
@@ -187,7 +125,7 @@ void radeonfb_imageblit(struct fb_info *info, const struct 
fb_image *image)
 
 static struct fb_ops radeonfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = radeon_fb_check_var,
+   .fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcolreg = drm_fb_helper_setcolreg,
.fb_fillrect = cfb_fillrect,
@@ -285,6 +223,7 @@ int radeonfb_create(struct drm_device *dev,
int size, aligned_size, ret;
void *fbptr = NULL;
bool fb_tiled = false; /* useful for testing */
+   u32 tiling_flags = 0;
 
mode_cmd.width = surface_width;
mode_cmd.height = surface_height;
@@ -308,7 +247,22 @@ int radeonfb_create(struct drm_device *dev,
robj = gobj-driver_private;
 
if (fb_tiled)
-   radeon_object_set_tiling_flags(robj, 
RADEON_TILING_MACRO|RADEON_TILING_SURFACE, mode_cmd.pitch);
+   tiling_flags = RADEON_TILING_MACRO;
+
+#ifdef __BIG_ENDIAN
+   switch (mode_cmd.bpp) {
+   case 32:
+   tiling_flags |= RADEON_TILING_SWAP_32BIT;
+   break;
+   case 16:
+   tiling_flags |=

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

2009-09-15 Thread 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 BlackBerryreg; 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

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

2009-09-15 Thread Michel Dänzer

On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote: 
 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_tflags;
   };
 
  -#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?

The bytes per element of the buffer contents mostly, but I don't think
we have that information in the kernel for userspace objects. Maybe I'm
missing something.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
Come build with us! The BlackBerryreg; 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

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

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

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

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

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

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

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

7 matches

Site Navigation

Mail list logo

Footer information