Re: New ioctl for surface allocation/deallocation

2004-12-08 Thread Keith Whitwell
Dave Airlie wrote: Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card

Re: New ioctl for surface allocation/deallocation

2004-12-08 Thread Stephane Marchesin
Michel Dnzer wrote: + // allocate the surface + for(i=0;i8;i++) + if (!(dev_priv-surfaces(1i))) + break; + + if (i=8) + return DRM_ERR(ENOMEM); + else + dev_priv-surfaces=(1i); + + if ( DRM_COPY_TO_USER( alloc.surface, i, + sizeof(int) ) ) { + DRM_ERROR( copy_to_user\n ); +

Re: New ioctl for surface allocation/deallocation

2004-12-08 Thread Stephane Marchesin
Dave Airlie wrote: Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card

Re: New ioctl for surface allocation/deallocation

2004-12-08 Thread Stephane Marchesin
Keith Whitwell wrote: Dave Airlie wrote: Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a

Re: New ioctl for surface allocation/deallocation

2004-12-08 Thread Keith Whitwell
Stephane Marchesin wrote: Keith Whitwell wrote: Dave Airlie wrote: Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a

Re: New ioctl for surface allocation/deallocation

2004-12-08 Thread Mike Mestnik
--- Stephane Marchesin [EMAIL PROTECTED] wrote: Michel Dänzer wrote: + // allocate the surface + for(i=0;i8;i++) + if (!(dev_priv-surfaces(1i))) + break; + + if (i=8) + return DRM_ERR(ENOMEM); + else + dev_priv-surfaces=(1i);

Re: New ioctl for surface allocation/deallocation

2004-12-08 Thread Ian Romanick
Stephane Marchesin wrote: Michel Dnzer wrote: +DRM_COPY_FROM_USER_IOCTL( memfree, (drm_radeon_mem_free_t __user *)data, + sizeof(memfree) ); + +dev_priv-surfaces= (~(1memfree.surface)); It should definitely ensure that only the owner can free a surface though. It would

New ioctl for surface allocation/deallocation

2004-12-07 Thread Stephane Marchesin
Hi, The small attached patch adds a new drm ioctl to do surface allocation/deallocation on the radeon. The reason to add a new ioctl is the following : since there are only 8 surfaces someone has to arbitrate between allocations by the ddx (color buffers) and from the dri (depth buffers).

Re: New ioctl for surface allocation/deallocation

2004-12-07 Thread Michel Dänzer
On Wed, 2004-12-08 at 02:54 +0100, Stephane Marchesin wrote: The small attached patch adds a new drm ioctl to do surface allocation/deallocation on the radeon. [...] Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation)

Re: New ioctl for surface allocation/deallocation

2004-12-07 Thread Dave Airlie
Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card specific hooks..