Via updates. Fixed unlikely but possible uint32_t overflow in ring-buffer

code. bumped patchlevel.
This commit is contained in:
Thomas Hellstrom 2004-10-12 18:46:26 +00:00
parent ad70dc676e
commit bbfe18e3bf
4 changed files with 13 additions and 14 deletions

View file

@ -80,7 +80,7 @@ via_cmdbuf_wait(drm_via_private_t * dev_priv, unsigned int size)
volatile uint32_t *hw_addr_ptr;
uint32_t count;
hw_addr_ptr = dev_priv->hw_addr_ptr;
cur_addr = agp_base + dev_priv->dma_low;
cur_addr = dev_priv->dma_low;
/* At high resolution (i.e. 1280x1024) and with high workload within
* a short commmand stream, the following test will fail. It may be
* that the engine is too busy to update hw_addr. Therefore, add
@ -89,11 +89,10 @@ via_cmdbuf_wait(drm_via_private_t * dev_priv, unsigned int size)
next_addr = cur_addr + size + 64 * 1024;
count = 1000000; /* How long is this? */
do {
hw_addr = *hw_addr_ptr;
hw_addr = *hw_addr_ptr - agp_base;
if (count-- == 0) {
DRM_ERROR
("via_cmdbuf_wait timed out hw %x dma_low %x\n",
hw_addr, dev_priv->dma_low);
DRM_ERROR("via_cmdbuf_wait timed out hw %x cur_addr %x next_addr %x\n",
hw_addr, cur_addr, next_addr);
return -1;
}
} while ((cur_addr < hw_addr) && (next_addr >= hw_addr));

View file

@ -28,11 +28,11 @@
#define DRIVER_NAME "via"
#define DRIVER_DESC "VIA Unichrome"
#define DRIVER_DATE "20041010"
#define DRIVER_DATE "20041012"
#define DRIVER_MAJOR 2
#define DRIVER_MINOR 0
#define DRIVER_PATCHLEVEL 0
#define DRIVER_PATCHLEVEL 1
typedef struct drm_via_ring_buffer {
drm_map_t map;

View file

@ -30,11 +30,11 @@
#define DRIVER_NAME "via"
#define DRIVER_DESC "VIA Unichrome"
#define DRIVER_DATE "20041010"
#define DRIVER_DATE "20041012"
#define DRIVER_MAJOR 2
#define DRIVER_MINOR 0
#define DRIVER_PATCHLEVEL 0
#define DRIVER_PATCHLEVEL 1
#define DRIVER_IOCTLS \
[DRM_IOCTL_NR(DRM_IOCTL_VIA_ALLOCMEM)] = { via_mem_alloc, 1, 0 }, \

View file

@ -81,7 +81,7 @@ via_cmdbuf_wait(drm_via_private_t * dev_priv, unsigned int size)
volatile uint32_t *hw_addr_ptr;
uint32_t count;
hw_addr_ptr = dev_priv->hw_addr_ptr;
cur_addr = agp_base + dev_priv->dma_low;
cur_addr = dev_priv->dma_low;
/* At high resolution (i.e. 1280x1024) and with high workload within
* a short commmand stream, the following test will fail. It may be
* that the engine is too busy to update hw_addr. Therefore, add
@ -90,11 +90,10 @@ via_cmdbuf_wait(drm_via_private_t * dev_priv, unsigned int size)
next_addr = cur_addr + size + 64 * 1024;
count = 1000000; /* How long is this? */
do {
hw_addr = *hw_addr_ptr;
hw_addr = *hw_addr_ptr - agp_base;
if (count-- == 0) {
DRM_ERROR
("via_cmdbuf_wait timed out hw %x dma_low %x\n",
hw_addr, dev_priv->dma_low);
DRM_ERROR("via_cmdbuf_wait timed out hw %x cur_addr %x next_addr %x\n",
hw_addr, cur_addr, next_addr);
return -1;
}
} while ((cur_addr < hw_addr) && (next_addr >= hw_addr));
@ -491,6 +490,7 @@ static void via_cmdbuf_jump(drm_via_private_t * dev_priv)
* state. Prepending a BitBLT command to stall the command
* regulator for a moment seems to solve the problem.
*/
via_cmdbuf_wait(dev_priv, 48);
via_dummy_bitblt(dev_priv);