Re: [Patch] Automake: stop polluting ${prefix}/include
Ack as long as things keep building. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] i915: Remove racy delayed vblank swap ioctl.
When userland detected that this ioctl was supported (by version number check),
it used it in a racy way -- dispatch delayed swap, wait for vblank, continue
rendering. As there was no mechanism for it to wait for the swap to finish,
sometimes it would render before the swap and garbage would be displayed on
the screen.
By removing the ioctl and returning -EINVAL, userland returns to its previous,
correct rendering path of waiting for a vblank then dispatching a swap. The
only path that could have used this ioctl correctly was page flipping, which
relied on only one client running and emitting wait-for-vblank-before-rendering
in the command stream. That path also falls back correctly, at the performance
cost of not being able to queue up rendering before the flip occurs.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_drv.h |4 -
drivers/gpu/drm/i915/i915_irq.c | 373 ++-
2 files changed, 14 insertions(+), 363 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be56b0b..bcde863 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -242,9 +242,6 @@ typedef struct drm_i915_private {
u8 saveDACDATA[256*3]; /* 256 3-byte colors */
u8 saveCR[37];
- /** Work task for vblank-related ring access */
- struct work_struct vblank_work;
-
struct {
struct drm_mm gtt_space;
@@ -445,7 +442,6 @@ extern int i915_irq_wait(struct drm_device *dev, void *data,
void i915_user_irq_get(struct drm_device *dev);
void i915_user_irq_put(struct drm_device *dev);
-extern void i915_vblank_work_handler(struct work_struct *work);
extern irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS);
extern void i915_driver_irq_preinstall(struct drm_device * dev);
extern int i915_driver_irq_postinstall(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 26f4893..73912b4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -80,211 +80,6 @@ i915_pipe_enabled(struct drm_device *dev, int pipe)
return 0;
}
-/**
- * Emit blits for scheduled buffer swaps.
- *
- * This function will be called with the HW lock held.
- * Because this function must grab the ring mutex (dev->struct_mutex),
- * it can no longer run at soft irq time. We'll fix this when we do
- * the DRI2 swap buffer work.
- */
-static void i915_vblank_tasklet(struct drm_device *dev)
-{
- drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
- unsigned long irqflags;
- struct list_head *list, *tmp, hits, *hit;
- int nhits, nrects, slice[2], upper[2], lower[2], i;
- unsigned counter[2];
- struct drm_drawable_info *drw;
- drm_i915_sarea_t *sarea_priv = dev_priv->sarea_priv;
- u32 cpp = dev_priv->cpp;
- u32 cmd = (cpp == 4) ? (XY_SRC_COPY_BLT_CMD |
- XY_SRC_COPY_BLT_WRITE_ALPHA |
- XY_SRC_COPY_BLT_WRITE_RGB)
-: XY_SRC_COPY_BLT_CMD;
- u32 src_pitch = sarea_priv->pitch * cpp;
- u32 dst_pitch = sarea_priv->pitch * cpp;
- u32 ropcpp = (0xcc << 16) | ((cpp - 1) << 24);
- RING_LOCALS;
-
- mutex_lock(&dev->struct_mutex);
-
- if (IS_I965G(dev) && sarea_priv->front_tiled) {
- cmd |= XY_SRC_COPY_BLT_DST_TILED;
- dst_pitch >>= 2;
- }
- if (IS_I965G(dev) && sarea_priv->back_tiled) {
- cmd |= XY_SRC_COPY_BLT_SRC_TILED;
- src_pitch >>= 2;
- }
-
- counter[0] = drm_vblank_count(dev, 0);
- counter[1] = drm_vblank_count(dev, 1);
-
- DRM_DEBUG("\n");
-
- INIT_LIST_HEAD(&hits);
-
- nhits = nrects = 0;
-
- spin_lock_irqsave(&dev_priv->swaps_lock, irqflags);
-
- /* Find buffer swaps scheduled for this vertical blank */
- list_for_each_safe(list, tmp, &dev_priv->vbl_swaps.head) {
- drm_i915_vbl_swap_t *vbl_swap =
- list_entry(list, drm_i915_vbl_swap_t, head);
- int pipe = vbl_swap->pipe;
-
- if ((counter[pipe] - vbl_swap->sequence) > (1<<23))
- continue;
-
- list_del(list);
- dev_priv->swaps_pending--;
- drm_vblank_put(dev, pipe);
-
- spin_unlock(&dev_priv->swaps_lock);
- spin_lock(&dev->drw_lock);
-
- drw = drm_get_drawable_info(dev, vbl_swap->drw_id);
-
- list_for_each(hit, &hits) {
- drm_i915_vbl_swap_t *swap_cmp =
- list_entry(hit, drm_i915_vbl_swap_t, head);
- struct drm_drawable_info *dr
[PATCH] i915: Remove IMR masking during interrupt handler, and restart it if needed.
The IMR masking was a technique recommended for avoiding getting stuck with
no interrupts generated again in MSI mode. It kept new IIR bits from getting
set between the IIR read and the IIR write, which would have otherwise
prevented an MSI from ever getting generated again. However, this caused a
problem for vblank as the IMR mask would keep the pipe event interrupt from
getting reflected in IIR, even after the IMR mask was brought back down.
Instead, just check the state of IIR after we ack the interrupts we're going
to handle, and restart if we didn't get IIR all the way to zero.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_irq.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3b8c78b..5c2c3bf 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -162,27 +162,22 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
{
struct drm_device *dev = (struct drm_device *) arg;
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
- u32 iir;
+ u32 iir, new_iir;
u32 pipea_stats = 0, pipeb_stats = 0;
int vblank = 0;
unsigned long irqflags;
- spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
atomic_inc(&dev_priv->irq_received);
+ spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
- if (dev->pdev->msi_enabled)
- I915_WRITE(IMR, ~0);
iir = I915_READ(IIR);
if (iir == 0) {
- if (dev->pdev->msi_enabled) {
- I915_WRITE(IMR, ~I915_INTERRUPT_ENABLE_MASK);
- (void) I915_READ(IMR);
- }
spin_unlock_irqrestore(&dev_priv->user_irq_lock, irqflags);
return IRQ_NONE;
}
+msi_interrupt_again:
/*
* Clear the PIPE(A|B)STAT regs before the IIR
*/
@@ -197,9 +192,7 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
}
I915_WRITE(IIR, iir);
- if (dev->pdev->msi_enabled)
- I915_WRITE(IMR, ~I915_INTERRUPT_ENABLE_MASK);
- (void) I915_READ(IIR); /* Flush posted writes */
+ new_iir = I915_READ(IIR); /* Flush posted writes */
spin_unlock_irqrestore(&dev_priv->user_irq_lock, irqflags);
@@ -226,6 +219,18 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
(iir & I915_ASLE_INTERRUPT))
opregion_asle_intr(dev);
+ /* With MSI, interrupts are only generated when iir transitions from
+* zero to nonzero. If another bit got set while we were handling
+* the existing iir bits, then we would never get another interrupt.
+* This is fine on non-MSI as well, as if we hit this path we avoid
+* exiting the interrupt handler only to generate another one.
+*/
+ if (new_iir != 0) {
+ spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
+ iir = new_iir;
+ goto msi_interrupt_again;
+ }
+
return IRQ_HANDLED;
}
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Manage PIPESTAT pending interrupt values to unblock vblank interrupts
On Tue, 2008-11-04 at 02:03 -0800, Keith Packard wrote:
> The pipestat fields affect reporting of all vblank-related interrupts, so we
> have to reset them during the irq_handler, and while enabling vblank
> interrupts.
>
> This patch adds i915_enable_pipestat and i915_disable_pipestat to abstract
> out the steps needed to change the reported interrupts.
This looks pretty good, and covers a lot of my concerns with interrupt
handling. See comments, and my additional MSI patch that I required for
stability against wiggling a window over vblank-synced glxgears
(reproducible in <30s before, and I've now spent a couple of minutes
wiggling windows successfully).
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b2ba2b6..f7ac581 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -34,28 +34,69 @@
> #define MAX_NOPID ((u32)~0)
>
> /** These are the interrupts used by the driver */
> -#define I915_INTERRUPT_ENABLE_MASK (I915_USER_INTERRUPT |\
> - I915_ASLE_INTERRUPT | \
> - I915_DISPLAY_PIPE_A_EVENT_INTERRUPT | \
> - I915_DISPLAY_PIPE_B_EVENT_INTERRUPT)
> +#define I915_INTERRUPT_ENABLE_FIX (I915_ASLE_INTERRUPT | \
> +I915_DISPLAY_PIPE_A_EVENT_INTERRUPT | \
> +I915_DISPLAY_PIPE_B_EVENT_INTERRUPT)
> +
> +#define I915_INTERRUPT_ENABLE_VAR (I915_USER_INTERRUPT)
> +
> +#define I915_INTERRUPT_ENABLE_MASK (I915_INTERRUPT_ENABLE_FIX | \
> + I915_INTERRUPT_ENABLE_VAR)
>
> void
> i915_enable_irq(drm_i915_private_t *dev_priv, u32 mask)
> {
> - if ((dev_priv->irq_mask_reg & mask) != 0) {
> - dev_priv->irq_mask_reg &= ~mask;
> - I915_WRITE(IMR, dev_priv->irq_mask_reg);
> - (void) I915_READ(IMR);
> + mask &= I915_INTERRUPT_ENABLE_VAR;
> + if ((dev_priv->irq_enable_reg & mask) != mask) {
> + dev_priv->irq_enable_reg |= mask;
> + I915_WRITE(IER, dev_priv->irq_enable_reg);
> + (void) I915_READ(IER);
> }
> }
IER versus IMR would be worthwhile to mention in the commit message.
> spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
> - /* Enabling vblank events in IMR comes before PIPESTAT write, or
> - * there's a race where the PIPESTAT vblank bit gets set to 1, so
> - * the OR of enabled PIPESTAT bits goes to 1, so the PIPExEVENT in
> - * ISR flashes to 1, but the IIR bit doesn't get set to 1 because
> - * IMR masks it. It doesn't ever get set after we clear the masking
> - * in IMR because the ISR bit is edge, not level-triggered, on the
> - * OR of PIPESTAT bits.
> - */
> - i915_enable_irq(dev_priv, interrupt);
> - pipestat = I915_READ(pipestat_reg);
> - if (IS_I965G(dev))
> - pipestat |= PIPE_START_VBLANK_INTERRUPT_ENABLE;
> - else
> - pipestat |= PIPE_VBLANK_INTERRUPT_ENABLE;
> - /* Clear any stale interrupt status */
> - pipestat |= (PIPE_START_VBLANK_INTERRUPT_STATUS |
> - PIPE_VBLANK_INTERRUPT_STATUS);
> - I915_WRITE(pipestat_reg, pipestat);
> - (void) I915_READ(pipestat_reg); /* Posting read */
> + i915_enable_pipestat(dev_priv, pipe, I915_VBLANK_INTERRUPT_ENABLE);
I'm uncomfortable with the dropping of the START_VBLANK versus VBLANK,
as I'm pretty sure people had figured out that the other bit was bad
news on 965+.
> int i915_driver_irq_postinstall(struct drm_device *dev)
> @@ -834,23 +805,25 @@ int i915_driver_irq_postinstall(struct drm_device *dev)
> INIT_WORK(&dev_priv->vblank_work, i915_vblank_work_handler);
> dev_priv->swaps_pending = 0;
>
> - /* Set initial unmasked IRQs to just the selected vblank pipes. */
> - dev_priv->irq_mask_reg = ~0;
> -
> ret = drm_vblank_init(dev, num_pipes);
> if (ret)
> return ret;
>
> dev_priv->vblank_pipe = DRM_I915_VBLANK_PIPE_A | DRM_I915_VBLANK_PIPE_B;
> - dev_priv->irq_mask_reg &= ~I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT;
> - dev_priv->irq_mask_reg &= ~I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
>
> dev->max_vblank_count = 0xff; /* only 24 bits of frame count */
>
> - dev_priv->irq_mask_reg &= I915_INTERRUPT_ENABLE_MASK;
> + dev_priv->irq_enable_reg = I915_INTERRUPT_ENABLE_FIX;
> +
> + dev_priv->pipestat[0] = 0;
> + dev_priv->pipestat[1] = 0;
> +
> + /* Disable pipe interrupt e
[PATCH] drm: Remove infrastructure for supporting i915's vblank swapping.
It's not used in any other drivers, and doesn't look like it will be from
drm.git master.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/drm_irq.c | 80
drivers/gpu/drm/drm_lock.c |9 -
drivers/gpu/drm/drm_stub.c |1 -
include/drm/drmP.h |5 ---
4 files changed, 0 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 212a94f..15c8dab 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -280,8 +280,6 @@ int drm_irq_uninstall(struct drm_device * dev)
drm_vblank_cleanup(dev);
- dev->locked_tasklet_func = NULL;
-
return 0;
}
EXPORT_SYMBOL(drm_irq_uninstall);
@@ -699,81 +697,3 @@ void drm_handle_vblank(struct drm_device *dev, int crtc)
drm_vbl_send_signals(dev, crtc);
}
EXPORT_SYMBOL(drm_handle_vblank);
-
-/**
- * Tasklet wrapper function.
- *
- * \param data DRM device in disguise.
- *
- * Attempts to grab the HW lock and calls the driver callback on success. On
- * failure, leave the lock marked as contended so the callback can be called
- * from drm_unlock().
- */
-static void drm_locked_tasklet_func(unsigned long data)
-{
- struct drm_device *dev = (struct drm_device *)data;
- unsigned long irqflags;
- void (*tasklet_func)(struct drm_device *);
-
- spin_lock_irqsave(&dev->tasklet_lock, irqflags);
- tasklet_func = dev->locked_tasklet_func;
- spin_unlock_irqrestore(&dev->tasklet_lock, irqflags);
-
- if (!tasklet_func ||
- !drm_lock_take(&dev->lock,
- DRM_KERNEL_CONTEXT)) {
- return;
- }
-
- dev->lock.lock_time = jiffies;
- atomic_inc(&dev->counts[_DRM_STAT_LOCKS]);
-
- spin_lock_irqsave(&dev->tasklet_lock, irqflags);
- tasklet_func = dev->locked_tasklet_func;
- dev->locked_tasklet_func = NULL;
- spin_unlock_irqrestore(&dev->tasklet_lock, irqflags);
-
- if (tasklet_func != NULL)
- tasklet_func(dev);
-
- drm_lock_free(&dev->lock,
- DRM_KERNEL_CONTEXT);
-}
-
-/**
- * Schedule a tasklet to call back a driver hook with the HW lock held.
- *
- * \param dev DRM device.
- * \param func Driver callback.
- *
- * This is intended for triggering actions that require the HW lock from an
- * interrupt handler. The lock will be grabbed ASAP after the interrupt handler
- * completes. Note that the callback may be called from interrupt or process
- * context, it must not make any assumptions about this. Also, the HW lock will
- * be held with the kernel context or any client context.
- */
-void drm_locked_tasklet(struct drm_device *dev, void (*func)(struct drm_device
*))
-{
- unsigned long irqflags;
- static DECLARE_TASKLET(drm_tasklet, drm_locked_tasklet_func, 0);
-
- if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ) ||
- test_bit(TASKLET_STATE_SCHED, &drm_tasklet.state))
- return;
-
- spin_lock_irqsave(&dev->tasklet_lock, irqflags);
-
- if (dev->locked_tasklet_func) {
- spin_unlock_irqrestore(&dev->tasklet_lock, irqflags);
- return;
- }
-
- dev->locked_tasklet_func = func;
-
- spin_unlock_irqrestore(&dev->tasklet_lock, irqflags);
-
- drm_tasklet.data = (unsigned long)dev;
-
- tasklet_hi_schedule(&drm_tasklet);
-}
-EXPORT_SYMBOL(drm_locked_tasklet);
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 888159e..1cfa720 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -154,8 +154,6 @@ int drm_lock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
int drm_unlock(struct drm_device *dev, void *data, struct drm_file *file_priv)
{
struct drm_lock *lock = data;
- unsigned long irqflags;
- void (*tasklet_func)(struct drm_device *);
if (lock->context == DRM_KERNEL_CONTEXT) {
DRM_ERROR("Process %d using kernel context %d\n",
@@ -163,13 +161,6 @@ int drm_unlock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
return -EINVAL;
}
- spin_lock_irqsave(&dev->tasklet_lock, irqflags);
- tasklet_func = dev->locked_tasklet_func;
- dev->locked_tasklet_func = NULL;
- spin_unlock_irqrestore(&dev->tasklet_lock, irqflags);
- if (tasklet_func != NULL)
- tasklet_func(dev);
-
atomic_inc(&dev->counts[_DRM_STAT_UNLOCKS]);
/* kernel_context_switch isn't used by any of the x86 drm
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 141e330..66c96ec 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -92,7 +92,6 @@ static int drm_fill_in_dev
[PATCH] i915: Remove racy delayed vblank swap ioctl.
When userland detected that this ioctl was supported (by version number check),
it used it in a racy way -- dispatch delayed swap, wait for vblank, continue
rendering. As there was no mechanism for it to wait for the swap to finish,
sometimes it would render before the swap and garbage would be displayed on
the screen.
By removing the ioctl and returning -EINVAL, userland returns to its previous,
correct rendering path of waiting for a vblank then dispatching a swap. The
only path that could have used this ioctl correctly was page flipping, which
relied on only one client running and emitting wait-for-vblank-before-rendering
in the command stream. That path also falls back correctly, at the performance
cost of not being able to queue up rendering before the flip occurs.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_drv.h | 15 --
drivers/gpu/drm/i915/i915_irq.c | 377 ++-
2 files changed, 14 insertions(+), 378 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d7f1e1..ad03531 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -88,13 +88,6 @@ struct mem_block {
struct drm_file *file_priv; /* NULL: free, -1: heap, other: real files
*/
};
-typedef struct _drm_i915_vbl_swap {
- struct list_head head;
- drm_drawable_t drw_id;
- unsigned int pipe;
- unsigned int sequence;
-} drm_i915_vbl_swap_t;
-
struct opregion_header;
struct opregion_acpi;
struct opregion_swsci;
@@ -147,10 +140,6 @@ typedef struct drm_i915_private {
unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
int vblank_pipe;
- spinlock_t swaps_lock;
- drm_i915_vbl_swap_t vbl_swaps;
- unsigned int swaps_pending;
-
struct intel_opregion opregion;
/* Register state */
@@ -243,9 +232,6 @@ typedef struct drm_i915_private {
u8 saveDACDATA[256*3]; /* 256 3-byte colors */
u8 saveCR[37];
- /** Work task for vblank-related ring access */
- struct work_struct vblank_work;
-
struct {
struct drm_mm gtt_space;
@@ -446,7 +432,6 @@ extern int i915_irq_wait(struct drm_device *dev, void *data,
void i915_user_irq_get(struct drm_device *dev);
void i915_user_irq_put(struct drm_device *dev);
-extern void i915_vblank_work_handler(struct work_struct *work);
extern irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS);
extern void i915_driver_irq_preinstall(struct drm_device * dev);
extern int i915_driver_irq_postinstall(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7522f7f..1fef354 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -121,211 +121,6 @@ i915_pipe_enabled(struct drm_device *dev, int pipe)
return 0;
}
-/**
- * Emit blits for scheduled buffer swaps.
- *
- * This function will be called with the HW lock held.
- * Because this function must grab the ring mutex (dev->struct_mutex),
- * it can no longer run at soft irq time. We'll fix this when we do
- * the DRI2 swap buffer work.
- */
-static void i915_vblank_tasklet(struct drm_device *dev)
-{
- drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
- unsigned long irqflags;
- struct list_head *list, *tmp, hits, *hit;
- int nhits, nrects, slice[2], upper[2], lower[2], i;
- unsigned counter[2];
- struct drm_drawable_info *drw;
- drm_i915_sarea_t *sarea_priv = dev_priv->sarea_priv;
- u32 cpp = dev_priv->cpp;
- u32 cmd = (cpp == 4) ? (XY_SRC_COPY_BLT_CMD |
- XY_SRC_COPY_BLT_WRITE_ALPHA |
- XY_SRC_COPY_BLT_WRITE_RGB)
-: XY_SRC_COPY_BLT_CMD;
- u32 src_pitch = sarea_priv->pitch * cpp;
- u32 dst_pitch = sarea_priv->pitch * cpp;
- u32 ropcpp = (0xcc << 16) | ((cpp - 1) << 24);
- RING_LOCALS;
-
- mutex_lock(&dev->struct_mutex);
-
- if (IS_I965G(dev) && sarea_priv->front_tiled) {
- cmd |= XY_SRC_COPY_BLT_DST_TILED;
- dst_pitch >>= 2;
- }
- if (IS_I965G(dev) && sarea_priv->back_tiled) {
- cmd |= XY_SRC_COPY_BLT_SRC_TILED;
- src_pitch >>= 2;
- }
-
- counter[0] = drm_vblank_count(dev, 0);
- counter[1] = drm_vblank_count(dev, 1);
-
- DRM_DEBUG("\n");
-
- INIT_LIST_HEAD(&hits);
-
- nhits = nrects = 0;
-
- spin_lock_irqsave(&dev_priv->swaps_lock, irqflags);
-
- /* Find buffer swaps scheduled for this vertical blank */
- list_for_each_safe(list, tmp, &dev_priv->vbl_swaps.head) {
- drm_i915_vbl_swap_t *vbl_swap =
- list_entry(list, drm_i915_vbl_swap_t, head);
Re: [PATCH] DRM: radeon: map registers at load time
On Wed, 2008-11-05 at 11:08 -0800, Jesse Barnes wrote:
> Now that the radeon driver has suspend/resume functions, it needs to map its
> registers at load time or it will likely crash if a suspend operation occurs
> before the driver has been initialized.
>
> This patch moves the register mapping code from firstopen to load and makes
> the mapping into a _DRM_DRIVER one so that the core won't remove it at
> lastclose time.
>
> Fixes (at least partially) kernel bz #11891.
>
> Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Looks good to me.
> diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
> b/drivers/gpu/drm/radeon/radeon_cp.c
> index 0738948..abdc1ae 100644
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c
> @@ -1751,6 +1751,12 @@ int radeon_driver_load(struct drm_device *dev,
> unsigned long flags)
> else
> dev_priv->flags |= RADEON_IS_PCI;
>
> + ret = drm_addmap(dev, drm_get_resource_start(dev, 2),
> + drm_get_resource_len(dev, 2), _DRM_REGISTERS,
> + _DRM_READ_ONLY | _DRM_DRIVER, &dev_priv->mmio);
> + if (ret != 0)
> + return ret;
> +
> DRM_DEBUG("%s card detected\n",
> ((dev_priv->flags & RADEON_IS_AGP) ? "AGP" :
> (((dev_priv->flags & RADEON_IS_PCIE) ?
> "PCIE" : "PCI";
> return ret;
> @@ -1767,12 +1773,6 @@ int radeon_driver_firstopen(struct drm_device *dev)
>
> dev_priv->gart_info.table_size = RADEON_PCIGART_TABLE_SIZE;
>
> - ret = drm_addmap(dev, drm_get_resource_start(dev, 2),
> - drm_get_resource_len(dev, 2), _DRM_REGISTERS,
> - _DRM_READ_ONLY, &dev_priv->mmio);
> - if (ret != 0)
> - return ret;
> -
> dev_priv->fb_aper_offset = drm_get_resource_start(dev, 0);
> ret = drm_addmap(dev, dev_priv->fb_aper_offset,
>drm_get_resource_len(dev, 0), _DRM_FRAME_BUFFER,
> @@ -1788,6 +1788,9 @@ int radeon_driver_unload(struct drm_device *dev)
> drm_radeon_private_t *dev_priv = dev->dev_private;
>
> DRM_DEBUG("\n");
> +
> + drm_rmmap(dev, dev_priv->mmio);
> +
> drm_free(dev_priv, sizeof(*dev_priv), DRM_MEM_DRIVER);
>
> dev->dev_private = NULL;
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: i915: add GEM GTT mapping support
On Wed, 2008-11-05 at 16:49 -0800, Jesse Barnes wrote:
> Use the new core GEM object mapping code to allow GTT mapping of GEM objects
> on i915. The fault handler will make sure a fence register is allocated too,
> if the object in question is tiled.
I required the following patch on top of your change to get it compiling
on non-x86_64. Also the args to the gtt mmap ioctl should be cut to
what's actually used. (or, imo, make it actually do the map on the
device's filp, like the other mmap ioctl does :) )
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3a7e2bb..3495117 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -585,11 +585,17 @@ static inline void opregion_enable_asle(struct drm_device
*dev) { return; }
#define I915_READ(reg) readl(dev_priv->regs + (reg))
#define I915_WRITE(reg, val) writel(val, dev_priv->regs + (reg))
-#define I915_WRITE64(reg, val) writeq(val, dev_priv->regs + (reg))
#define I915_READ16(reg) readw(dev_priv->regs + (reg))
#define I915_WRITE16(reg, val) writel(val, dev_priv->regs + (reg))
#define I915_READ8(reg)readb(dev_priv->regs + (reg))
#define I915_WRITE8(reg, val) writeb(val, dev_priv->regs + (reg))
+#ifdef writeq
+#define I915_WRITE64(reg, val) writeq(val, dev_priv->regs + (reg))
+#else
+#define I915_WRITE64(reg, val) (writel(val, dev_priv->regs + (reg)), \
+writel(upper_32_bits(val), \
+ dev_priv->regs + (reg) + 4))
+#endif
#define I915_VERBOSE 0
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d5c909a..98f6f49 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1395,8 +1395,8 @@ static void i965_write_fence_reg(struct
drm_i915_fence_reg *reg)
int regnum = obj_priv->fence_reg;
uint64_t val;
- val = ((obj_priv->gtt_offset + obj->size - 4096) &
- 0xf000) << 32;
+ val = (uint64_t)((obj_priv->gtt_offset + obj->size - 4096) &
+ 0xf000) << 32;
val |= obj_priv->gtt_offset & 0xf000;
val |= ((obj_priv->stride / 128) - 1) << I965_FENCE_PITCH_SHIFT;
if (obj_priv->tiling_mode == I915_TILING_Y)
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] i915: Filter pci devices based on PCI_CLASS_DISPLAY_VGA
This fixes hangs on 855-class hardware by avoiding double attachment of the
driver due to the stub second head device having the same pci id as the real
device.
Other DRM drivers probably want this treatment as well, but I'm applying it
just to this one for safety.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/drm_drv.c | 10 +++-
include/drm/drm_pciids.h | 52 +---
2 files changed, 38 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 96f416a..3ab1e9c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -266,11 +266,19 @@ int drm_init(struct drm_driver *driver)
for (i = 0; driver->pci_driver.id_table[i].vendor != 0; i++) {
pid = (struct pci_device_id *)&driver->pci_driver.id_table[i];
+ /* Loop around setting up a DRM device for each PCI device
+* matching our ID and device class. If we had the internal
+* function that pci_get_subsys and pci_get_class used, we'd
+* be able to just pass pid in instead of doing a two-stage
+* thing.
+*/
pdev = NULL;
- /* pass back in pdev to account for multiple identical cards */
while ((pdev =
pci_get_subsys(pid->vendor, pid->device, pid->subvendor,
pid->subdevice, pdev)) != NULL) {
+ if ((pdev->class & pid->class_mask) != pid->class)
+ continue;
+
/* stealth mode requires a manual probe */
pci_dev_get(pdev);
drm_get_dev(pdev, pid, driver);
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index da04109..d209578 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -394,28 +394,34 @@
#define ffb_PCI_IDS \
{0, 0, 0}
+#define i915_PCI_DEVID(vendor, device) { \
+ vendor, device, \
+ PCI_ANY_ID, PCI_ANY_ID, \
+ PCI_CLASS_DISPLAY_VGA << 8, 0x00, \
+ 0 \
+}
#define i915_PCI_IDS \
- {0x8086, 0x3577, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2562, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x3582, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2572, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2582, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x258a, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2592, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2772, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x27a2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x27ae, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2972, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2982, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2992, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x29a2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x29b2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x29c2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x29d2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2a02, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2a12, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2a42, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2e02, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2e12, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x8086, 0x2e22, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
+ i915_PCI_DEVID(0x8086, 0x3577), \
+ i915_PCI_DEVID(0x8086, 0x2562), \
+ i915_PCI_DEVID(0x8086, 0x3582), \
+ i915_PCI_DEVID(0x8086, 0x2572), \
+ i915_PCI_DEVID(0x8086, 0x2582), \
+ i915_PCI_DEVID(0x8086, 0x258a), \
+ i915_PCI_DEVID(0x8086, 0x2592), \
+ i915_PCI_DEVID(0x8086, 0x2772), \
+ i915_PCI_DEVID(0x8086, 0x27a2), \
+ i915_PCI_DEVID(0x8086, 0x27ae), \
+ i915_PCI_DEVID(0x8086, 0x2972), \
+ i915_PCI_DEVID(0x8086, 0x2982), \
+ i915_PCI_DEVID(0x8086, 0x2992), \
+ i915_PCI_DEVID(0x8086, 0x29a2), \
+ i915_PCI_DEVID(0x8086, 0x29b2), \
+ i915_PCI_DEVID(0x8086, 0x29c2), \
+ i915_PCI_DEVID(0x8086, 0x29d2), \
+ i915_PCI_DEVID(0x8086, 0x2a02), \
+ i915_PCI_DEVID(0x8086, 0x2a12), \
+ i915_PCI_DEVID(0x8086, 0x2a42), \
+ i915_PCI_DEVID(0x8086, 0x2e02), \
+ i915_PCI_DEVID(0x8086, 0x2e12), \
+ i915_PCI_DEVID(0x8086, 0x2e22), \
{0, 0, 0}
--
1.5.6.5
-
This SF.Net email is sponsored by the Mobli
Re: [Intel-gfx] [PATCH] Manage PIPESTAT pending interrupt values to unblock vblank interrupts
On Fri, 2008-11-07 at 14:01 +, Steven J Newbury wrote:
> On Tue, 2008-11-04 at 16:04 -0800, Eric Anholt wrote:
> > On Tue, 2008-11-04 at 02:03 -0800, Keith Packard wrote:
> > > The pipestat fields affect reporting of all vblank-related interrupts, so
> > > we
> > > have to reset them during the irq_handler, and while enabling vblank
> > > interrupts.
> > >
> > > This patch adds i915_enable_pipestat and i915_disable_pipestat to abstract
> > > out the steps needed to change the reported interrupts.
> >
> > This looks pretty good, and covers a lot of my concerns with interrupt
> > handling. See comments, and my additional MSI patch that I required for
> > stability against wiggling a window over vblank-synced glxgears
> > (reproducible in <30s before, and I've now spent a couple of minutes
> > wiggling windows successfully).
> >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index b2ba2b6..f7ac581 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -34,28 +34,69 @@
> > > #define MAX_NOPID ((u32)~0)
> > >
> > > /** These are the interrupts used by the driver */
> > > -#define I915_INTERRUPT_ENABLE_MASK (I915_USER_INTERRUPT |
> > > \
> > > - I915_ASLE_INTERRUPT | \
> > > - I915_DISPLAY_PIPE_A_EVENT_INTERRUPT | \
> > > - I915_DISPLAY_PIPE_B_EVENT_INTERRUPT)
> > > +#define I915_INTERRUPT_ENABLE_FIX (I915_ASLE_INTERRUPT | \
> > > +I915_DISPLAY_PIPE_A_EVENT_INTERRUPT | \
> > > +I915_DISPLAY_PIPE_B_EVENT_INTERRUPT)
> > > +
> > > +#define I915_INTERRUPT_ENABLE_VAR (I915_USER_INTERRUPT)
> > > +
> > > +#define I915_INTERRUPT_ENABLE_MASK (I915_INTERRUPT_ENABLE_FIX | \
> > > + I915_INTERRUPT_ENABLE_VAR)
> > >
> > > void
> > > i915_enable_irq(drm_i915_private_t *dev_priv, u32 mask)
> > > {
> > > - if ((dev_priv->irq_mask_reg & mask) != 0) {
> > > - dev_priv->irq_mask_reg &= ~mask;
> > > - I915_WRITE(IMR, dev_priv->irq_mask_reg);
> > > - (void) I915_READ(IMR);
> > > + mask &= I915_INTERRUPT_ENABLE_VAR;
> > > + if ((dev_priv->irq_enable_reg & mask) != mask) {
> > > + dev_priv->irq_enable_reg |= mask;
> > > + I915_WRITE(IER, dev_priv->irq_enable_reg);
> > > + (void) I915_READ(IER);
> > > }
> > > }
> >
> > IER versus IMR would be worthwhile to mention in the commit message.
> >
> > > spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
> > > - /* Enabling vblank events in IMR comes before PIPESTAT write, or
> > > - * there's a race where the PIPESTAT vblank bit gets set to 1, so
> > > - * the OR of enabled PIPESTAT bits goes to 1, so the PIPExEVENT in
> > > - * ISR flashes to 1, but the IIR bit doesn't get set to 1 because
> > > - * IMR masks it. It doesn't ever get set after we clear the masking
> > > - * in IMR because the ISR bit is edge, not level-triggered, on the
> > > - * OR of PIPESTAT bits.
> > > - */
> > > - i915_enable_irq(dev_priv, interrupt);
> > > - pipestat = I915_READ(pipestat_reg);
> > > - if (IS_I965G(dev))
> > > - pipestat |= PIPE_START_VBLANK_INTERRUPT_ENABLE;
> > > - else
> > > - pipestat |= PIPE_VBLANK_INTERRUPT_ENABLE;
> > > - /* Clear any stale interrupt status */
> > > - pipestat |= (PIPE_START_VBLANK_INTERRUPT_STATUS |
> > > - PIPE_VBLANK_INTERRUPT_STATUS);
> > > - I915_WRITE(pipestat_reg, pipestat);
> > > - (void) I915_READ(pipestat_reg); /* Posting read */
> > > + i915_enable_pipestat(dev_priv, pipe, I915_VBLANK_INTERRUPT_ENABLE);
> >
> > I'm uncomfortable with the dropping of the START_VBLANK versus VBLANK,
> > as I'm pretty sure people had figured out that the other bit was bad
> > news on 965+.
> >
> I'm on 965GM and I'm having a serious interrupt problem since this patch
> went into for-review:
>
> Nov 7 04:20:22 infinity irq 16: nobody cared (try booting with the
> "irqpoll" option)
> Nov 7 04:20:22 infinity Pid: 0, comm: swapper Not tainted
> 2.6.28-rc3-00236-g1d7eff8 #23
> Nov 7 04:20
Final intel IRQ fixes patch series
This is the patch series I've pushed to for-airlied for 2.6.28. It's similar to the previous IRQ patch series, but with the IMR -> IER change that had snuck in reverted. On non-MSI chipsets, twiddling IER apparently sometimes gets the interrupt wedged despite IIR=0, and the interrupt gets disabled shortly afterwards (easy way to reproduce on GM965: while true do glxgears&; sleep 10; killall glxgears; sleep 10; done). Since we're leaving the pipestat interrupts unmasked all the time now (controlling them using the pipestat bits, not imr/ier), we shouldn't have any further pipe interrupt loss. I've been looping vblank_mode=2 openarena on GM965 and G45, and a mix of synced and unsynced glxgears on 915GM for the last half hour, and things are looking good. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] i915: Remove IMR masking during interrupt handler, and restart it if needed.
The IMR masking was a technique recommended for avoiding getting stuck with
no interrupts generated again in MSI mode. It kept new IIR bits from getting
set between the IIR read and the IIR write, which would have otherwise
prevented an MSI from ever getting generated again. However, this caused a
problem for vblank as the IMR mask would keep the pipe event interrupt from
getting reflected in IIR, even after the IMR mask was brought back down.
Instead, just check the state of IIR after we ack the interrupts we're going
to handle, and restart if we didn't get IIR all the way to zero.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_irq.c | 40 +++---
1 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ca3ed18..047b9d7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -168,46 +168,38 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
{
struct drm_device *dev = (struct drm_device *) arg;
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
- u32 iir;
+ u32 iir, new_iir;
u32 pipea_stats = 0, pipeb_stats = 0;
int vblank = 0;
unsigned long irqflags;
- spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
atomic_inc(&dev_priv->irq_received);
- if (dev->pdev->msi_enabled)
- I915_WRITE(IMR, ~0);
iir = I915_READ(IIR);
- if (iir == 0) {
- if (dev->pdev->msi_enabled) {
- I915_WRITE(IMR, dev_priv->irq_mask_reg);
- (void) I915_READ(IMR);
- }
- spin_unlock_irqrestore(&dev_priv->user_irq_lock, irqflags);
+ if (iir == 0)
return IRQ_NONE;
- }
+msi_interrupt_again:
/*
* Clear the PIPE(A|B)STAT regs before the IIR
*/
if (iir & I915_DISPLAY_PIPE_A_EVENT_INTERRUPT) {
+ spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
pipea_stats = I915_READ(PIPEASTAT);
I915_WRITE(PIPEASTAT, pipea_stats);
+ spin_unlock_irqrestore(&dev_priv->user_irq_lock, irqflags);
}
if (iir & I915_DISPLAY_PIPE_B_EVENT_INTERRUPT) {
+ spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
pipeb_stats = I915_READ(PIPEBSTAT);
I915_WRITE(PIPEBSTAT, pipeb_stats);
+ spin_unlock_irqrestore(&dev_priv->user_irq_lock, irqflags);
}
I915_WRITE(IIR, iir);
- if (dev->pdev->msi_enabled)
- I915_WRITE(IMR, dev_priv->irq_mask_reg);
- (void) I915_READ(IIR); /* Flush posted writes */
-
- spin_unlock_irqrestore(&dev_priv->user_irq_lock, irqflags);
+ new_iir = I915_READ(IIR); /* Flush posted writes */
if (dev_priv->sarea_priv)
dev_priv->sarea_priv->last_dispatch =
@@ -232,6 +224,22 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
(iir & I915_ASLE_INTERRUPT))
opregion_asle_intr(dev);
+ /* With MSI, interrupts are only generated when iir transitions from
+* zero to nonzero. If another bit got set while we were handling
+* the existing iir bits, then we would never get another interrupt.
+* This is fine on non-MSI as well, as if we hit this path we avoid
+* exiting the interrupt handler only to generate another one.
+*
+* Note that for MSI this could cause a stray interrupt report if an
+* interrupt landed in the time between writing IIR and the posting
+* read. This should be rare enough to never trigger the 99% of
+* 100,000 interrupts test for disabling stray interrupts.
+*/
+ if (new_iir != 0) {
+ iir = new_iir;
+ goto msi_interrupt_again;
+ }
+
return IRQ_HANDLED;
}
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] i915: Manage PIPESTAT to control vblank interrupts instead of IMR.
From: Keith Packard <[EMAIL PROTECTED]>
The pipestat fields affect reporting of all vblank-related interrupts, so we
have to reset them during the irq_handler, and while enabling vblank
interrupts. Otherwise, if a pipe status field had been set to non-zero
before enabling reporting, we would never see an interrupt again.
This patch adds i915_enable_pipestat and i915_disable_pipestat to abstract
out the steps needed to change the reported interrupts.
Signed-off-by: Keith Packard <[EMAIL PROTECTED]>
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_drv.h |8 ++
drivers/gpu/drm/i915/i915_irq.c | 211 --
drivers/gpu/drm/i915/i915_opregion.c | 18 ++--
3 files changed, 115 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef1c0b8..ed1edcf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -132,6 +132,7 @@ typedef struct drm_i915_private {
int user_irq_refcount;
/** Cached value of IMR to avoid reads in updating the bitfield */
u32 irq_mask_reg;
+ u32 pipestat[2];
int tex_lru_log_granularity;
int allow_batchbuffer;
@@ -446,6 +447,13 @@ extern int i915_vblank_swap(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
extern void i915_enable_irq(drm_i915_private_t *dev_priv, u32 mask);
+void
+i915_enable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask);
+
+void
+i915_disable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask);
+
+
/* i915_mem.c */
extern int i915_mem_alloc(struct drm_device *dev, void *data,
struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 82752d6..ca3ed18 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -33,11 +33,23 @@
#define MAX_NOPID ((u32)~0)
-/** These are the interrupts used by the driver */
-#define I915_INTERRUPT_ENABLE_MASK (I915_USER_INTERRUPT | \
- I915_ASLE_INTERRUPT | \
- I915_DISPLAY_PIPE_A_EVENT_INTERRUPT | \
- I915_DISPLAY_PIPE_B_EVENT_INTERRUPT)
+/**
+ * Interrupts that are always left unmasked.
+ *
+ * Since pipe events are edge-triggered from the PIPESTAT register to IIR,
+ * we leave them always unmasked in IMR and then control enabling them through
+ * PIPESTAT alone.
+ */
+#define I915_INTERRUPT_ENABLE_FIX (I915_ASLE_INTERRUPT | \
+ I915_DISPLAY_PIPE_A_EVENT_INTERRUPT | \
+ I915_DISPLAY_PIPE_B_EVENT_INTERRUPT)
+
+/** Interrupts that we mask and unmask at runtime. */
+#define I915_INTERRUPT_ENABLE_VAR (I915_USER_INTERRUPT)
+
+/** These are all of the interrupts used by the driver */
+#define I915_INTERRUPT_ENABLE_MASK (I915_INTERRUPT_ENABLE_FIX | \
+ I915_INTERRUPT_ENABLE_VAR)
void
i915_enable_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -59,6 +71,41 @@ i915_disable_irq(drm_i915_private_t *dev_priv, u32 mask)
}
}
+static inline u32
+i915_pipestat(int pipe)
+{
+ if (pipe == 0)
+ return PIPEASTAT;
+ if (pipe == 1)
+ return PIPEBSTAT;
+ BUG_ON(1);
+}
+
+void
+i915_enable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask)
+{
+ if ((dev_priv->pipestat[pipe] & mask) != mask) {
+ u32 reg = i915_pipestat(pipe);
+
+ dev_priv->pipestat[pipe] |= mask;
+ /* Enable the interrupt, clear any pending status */
+ I915_WRITE(reg, dev_priv->pipestat[pipe] | (mask >> 16));
+ (void) I915_READ(reg);
+ }
+}
+
+void
+i915_disable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask)
+{
+ if ((dev_priv->pipestat[pipe] & mask) != 0) {
+ u32 reg = i915_pipestat(pipe);
+
+ dev_priv->pipestat[pipe] &= ~mask;
+ I915_WRITE(reg, dev_priv->pipestat[pipe]);
+ (void) I915_READ(reg);
+ }
+}
+
/**
* i915_pipe_enabled - check if a pipe is enabled
* @dev: DRM device
@@ -122,9 +169,11 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
struct drm_device *dev = (struct drm_device *) arg;
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
u32 iir;
- u32 pipea_stats, pipeb_stats;
+ u32 pipea_stats = 0, pipeb_stats = 0;
int vblank = 0;
+ unsigned long irqflags;
+ spin_lock_irqsave(&dev_priv->user_irq_lock, irqflags);
atomic_inc(&dev_priv->irq_received);
if (dev->pdev->msi_enabled)
@@ -136,44 +185,20 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
Re: [PATCH] DRM: i915: add GEM GTT mapping support
On Tue, 2008-11-11 at 16:48 -0800, Jesse Barnes wrote:
> On Tuesday, November 11, 2008 2:16 pm Jesse Barnes wrote:
> > +struct drm_i915_gem_mmap_gtt {
> > + /** Handle for the object being mapped. */
> > + uint32_t handle;
> > + uint32_t pad;
> > + /**
> > +* Fake offset to use for subsequent mmap call
> > +*
> > +* This is a fixed-size type for 32/64 compatibility.
> > +*/
> > + uint64_t addr_ptr;
> > + uint32_t flags;
> > +};
>
> Damn, I left flags in (had it removed but not committed). It's not actually
> necessary. I'll post an updated set with the libdrm stuff and this fixed.
addr_ptr should probably be called "offset" since it's not actually a
pointer, right?
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: i915: add GEM GTT mapping support
On Tue, 2008-11-11 at 17:15 -0800, Jesse Barnes wrote:
> On Tuesday, November 11, 2008 4:55 pm Eric Anholt wrote:
> > On Tue, 2008-11-11 at 16:48 -0800, Jesse Barnes wrote:
> > > On Tuesday, November 11, 2008 2:16 pm Jesse Barnes wrote:
> > > > +struct drm_i915_gem_mmap_gtt {
> > > > + /** Handle for the object being mapped. */
> > > > + uint32_t handle;
> > > > + uint32_t pad;
> > > > + /**
> > > > +* Fake offset to use for subsequent mmap call
> > > > +*
> > > > +* This is a fixed-size type for 32/64 compatibility.
> > > > +*/
> > > > + uint64_t addr_ptr;
> > > > + uint32_t flags;
> > > > +};
> > >
> > > Damn, I left flags in (had it removed but not committed). It's not
> > > actually necessary. I'll post an updated set with the libdrm stuff and
> > > this fixed.
> >
> > addr_ptr should probably be called "offset" since it's not actually a
> > pointer, right?
>
> Yeah, I thought the same thing when I updated it, though it's not even really
> an offset, more of an object map key... So I could do either offset or
> map_key or whatever. Any preferences?
The name of the argument to mmap is "offset", so it seems like a decent
choice.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [patch] Use intel_viewport for i915 dri driver
On Tue, 2008-11-11 at 11:23 +0800, Li Peng wrote:
> I followed the dri2 discussion on dri-devel
> (http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg35990.html),
> current dri2 implementation depends on glViewport being called whenever the
> window/framebuffer is resized, otherwise renderbuffer can't be updated. In
> i915 dri driver, we first set functions->Viewport to intel_viewport, then
> this function pointer is overrided by intelViewport, who calls
> intelCalcViewport and doesn't update renderbuffer.
>
> With this patch, we can resize glxgears as normal.
>
> This patch also fix a metacity-clutter/DRI2 issue, that we only have
> 640x480 preallocated renderbuffer at metacity-clutter start and then the
> buffers can't be updated anymore.
>
> Please review and your comments are welcome. Thanks
Your patch results in i915's Viewport not getting called. Replacement
patch to follow.
> diff --git a/src/mesa/drivers/dri/i915/intel_state.c
> b/src/mesa/drivers/dri/i915/intel_state.c
> index 09aa62d..c99bb16 100644
> --- a/src/mesa/drivers/dri/i915/intel_state.c
> +++ b/src/mesa/drivers/dri/i915/intel_state.c
> @@ -289,7 +289,6 @@ void
> intelInitStateFuncs(struct dd_function_table *functions)
> {
> functions->RenderMode = intelRenderMode;
> - functions->Viewport = intelViewport;
> functions->DepthRange = intelDepthRange;
> functions->ClearColor = intelClearColor;
> }
>
>
> _______
> Intel-gfx mailing list
> [EMAIL PROTECTED]
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH][drm/i915] restore HWS_PGA if resuming from suspend
On Mon, 2008-11-17 at 18:14 +0800, Li Peng wrote:
> This patch restore HWS_PGA for device who don't use gtt mapped hardware
> status page.
> It is to fix the suspend/resume failure of xf86-video-intel dri2 branch
> on 945GME, as the dri2 branch doesn't call I830Resume() to restore
> hardware status page anymore and we need to handle this in
> i915_gem_entervt_ioctl()
This should also be saved/restored in i915_suspend.c so that it works
correctly in the absence of the X Server doing the enter/leavevt path.
> Peng
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index a15b098..b6b451a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2924,8 +2924,13 @@ i915_gem_init_hws(struct drm_device *dev)
> /* If we need a physical address for the status page, it's already
>* initialized at driver load time.
>*/
> - if (!I915_NEED_GFX_HWS(dev))
> + if (!I915_NEED_GFX_HWS(dev)) {
> + if (dev_priv->mm.suspended) {
> + I915_WRITE(HWS_PGA, dev_priv->dma_status_page);
> + I915_READ(HWS_PGA); /* posting read */
> + }
> return 0;
> + }
>
> obj = drm_gem_object_alloc(dev, 4096);
> if (obj == NULL) {
>
>
> ___
> Intel-gfx mailing list
> [EMAIL PROTECTED]
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: add mode setting support
} else if (cmp(p, q) <= 0) {
> + e = p;
> + p = p->next;
> + psize--;
> + if (p == oldhead)
> + p = NULL;
> + } else {
> + e = q;
> + q = q->next;
> + qsize--;
> + if (q == oldhead)
> + q = NULL;
> + }
> + if (tail)
> + tail->next = e;
> + else
> + list = e;
> + e->prev = tail;
> + tail = e;
> + }
> + p = q;
> + }
> +
> + tail->next = list;
> + list->prev = tail;
> +
> + if (nmerges <= 1)
> + break;
> +
> + insize *= 2;
> + }
> +
> + head->next = list;
> + head->prev = list->prev;
> + list->prev->next = head;
> + list->prev = head;
> +}
> --- /dev/null
> +++ b/include/drm/drm_crtc.h
> @@ -0,0 +1,716 @@
> +/*
> + * Copyright © 2006 Keith Packard
> + * Copyright © 2007 Intel Corporation
> + * Jesse Barnes <[EMAIL PROTECTED]>
> + */
Copyright with no license?
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> new file mode 100644
> index 000..e770205
> --- /dev/null
> +++ b/include/drm/drm_crtc_helper.h
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright © 2006 Keith Packard
> + * Copyright © 2007 Intel Corporation
> + * Jesse Barnes <[EMAIL PROTECTED]>
> + */
License?
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> new file mode 100644
> index 000..dccfba9
> --- /dev/null
> +++ b/include/drm/drm_edid.h
> @@ -0,0 +1,178 @@
> +#ifndef __DRM_EDID_H__
> +#define __DRM_EDID_H__
> +
> +#include
Copyright?
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: i915: add mode setting support
On Wed, 2008-11-05 at 16:49 -0800, Jesse Barnes wrote:
> Adds support for DRM based mode setting on Intel integrated graphics chips.
Might be nice to note what hardware is/isn't supported and tested here.
For example, native HDMI is missing from the 2d driver it looks like,
and we still need to write DP support.
My major concern is basically license clarification.
> diff --git a/drivers/gpu/drm/i915/dvo.h b/drivers/gpu/drm/i915/dvo.h
> new file mode 100644
> index 000..b122ea1
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/dvo.h
> @@ -0,0 +1,159 @@
> +/*
> + * Copyright © 2006 Eric Anholt
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission. The copyright holders make no representations
> + * about the suitability of this software for any purpose. It is provided
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + */
> +
> +#ifndef _INTEL_DVO_H
> +#define _INTEL_DVO_H
> +
> +#include
> +#include "drmP.h"
> +#include "drm.h"
> +#include "drm_crtc.h"
> +#include "intel_drv.h"
> +
> +struct intel_dvo_device {
> + char *name;
> + int type;
> + /* DVOA/B/C output register */
> + u32 dvo_reg;
> + /* GPIO register used for i2c bus to control this device */
> + u32 gpio;
> + int slave_addr;
> + struct intel_i2c_chan *i2c_bus;
> +
> + const struct intel_dvo_dev_ops *dev_ops;
> + void *dev_priv;
> +
> + struct drm_display_mode *panel_fixed_mode;
> + bool panel_wants_dither;
> +};
> +
> +struct intel_dvo_dev_ops {
> + /*
> + * Initialize the device at startup time.
> + * Returns NULL if the device does not exist.
> + */
> + bool (*init)(struct intel_dvo_device *dvo,
> + struct intel_i2c_chan *i2cbus);
> +
> + /*
> + * Called to allow the output a chance to create properties after the
> + * RandR objects have been created.
> + */
> + void (*create_resources)(struct intel_dvo_device *dvo);
> +
> + /*
> + * Turn on/off output or set intermediate power levels if available.
> + *
> + * Unsupported intermediate modes drop to the lower power setting.
> + * If the mode is DPMSModeOff, the output must be disabled,
> + * as the DPLL may be disabled afterwards.
> + */
> + void (*dpms)(struct intel_dvo_device *dvo, int mode);
> +
> + /*
> + * Saves the output's state for restoration on VT switch.
> + */
> + void (*save)(struct intel_dvo_device *dvo);
> +
> + /*
> + * Restore's the output's state at VT switch.
> + */
> + void (*restore)(struct intel_dvo_device *dvo);
> +
> + /*
> + * Callback for testing a video mode for a given output.
> + *
> + * This function should only check for cases where a mode can't
> + * be supported on the output specifically, and not represent
> + * generic CRTC limitations.
> + *
> + * \return MODE_OK if the mode is valid, or another MODE_* otherwise.
> + */
> + int (*mode_valid)(struct intel_dvo_device *dvo,
> + struct drm_display_mode *mode);
> +
> + /*
> + * Callback to adjust the mode to be set in the CRTC.
> + *
> + * This allows an output to adjust the clock or even the entire set of
> + * timings, which is used for panels with fixed timings or for
> + * buses with clock limitations.
> + */
> + bool (*mode_fixup)(struct intel_dvo_device *dvo,
> +struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode);
> +
> + /*
> + *
Re: Handling buffer swaps in composited environments
On Tue, 2008-11-25 at 11:31 -0800, Jesse Barnes wrote: > DRI2 is about to land in the Intel driver, so we've been thinking about how > to > deal with the last missing piece: vertical blank synchronized buffer swaps. > I > think there are a few of problems to solve here: > 1) swap buffers should be asynchronous (i.e. it should let the app continue > rendering the next frame, not block until the swap completes, since that > would defeat the whole purpose of double buffering) > 2) swap buffers in general shouldn't just let the app run flat out (i.e. > apps typically want to block until at least one of their frames is > displayed, configurable with the swap control extension) > 3) in a composited environment the compositor decides when the frames are > actually displayed, so we can't just do direct vblank waits in the app > like we do today I agree on 1 and 3 but not clearly on 2. I think actually letting the app run nearly flat out is probably a fine plan. > I think the typical use case is a double buffered app doing glXSwapBuffers > between frames, expecting the function to return immediately unless the > buffer > being swapped to hasn't been displayed yet. That will allow it to continue > drawing as soon as possible, which should allow it to render another frame > before the next vertical blank period even in the face of scheduling latency. No, traditionally in swap of frame n, you wait for swap of frame n-1, so that you get full concurrency instead of letting both gpu and cpu spend some time idle. vblank syncing introduced waiting for vsync for the display of frame n and then dispatching it. > Currently, DRI2 glXSwapBuffers ends up in the DDX CopyRegion hook, which at > this point simply does a GC CopyArea. Kristian has a patch to allow for > swaps > synchronized to vertical blank, using a separate queue in the i915 DRM > driver, > but that only addresses problem (1). > > To handle problems (2) and (3) it seems like we need a way for the > compositing > manager to signal to the server/DDX that the front buffer has been updated > with the most recent buffers from the currently running GL apps. Kristian > thought we might be able to use the compositor's damage notifier for this; if > the DDX knew which one the compositor was using, it could wait until it was > clear before allowing subsequent buffer swaps to continue. > > Comments on this? In other environments (for example specific EGL back ends) > some other synchronization mechanism will be necessary. In the case of > Wayland, I think the compositor has its own copy of things, so it can simply > allow the swap to continue once it has a copy of the latest buffer. I don't like this plan. If my app has a new frame all ready to go, I want it to get displayed the next time the compositor wakes up to do a vblank-synced composite, not wait for the compositor to grab the stale frame before continuing. In the world I imagine, the app's running nearly flat-out (waiting only for getting its n-1 frame completed), getting damage posted as it "swaps" (flips front/back BO handles), and the compositor's picking up the last swapped frame when it wakes up to prepare the next frame to get displayed. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Respect GM965/GM45 bit-17-instead-of-bit-11 option for swizzling.
This fixes readpixels and buffer corruption when swapped out and in by
disabling tiling on them.
Now that we know that the bit 17 mode isn't just a mistake of older chipsets,
we'll need to work on a clever fix so that we can get the performance of
tiling on these chipsets, but that will require intrusive changes targeted
at the next kernel release, not this one.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_gem_tiling.c |7 ---
drivers/gpu/drm/i915/i915_reg.h|1 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index e8b85ac..a8cb694 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -119,9 +119,10 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
dcc & DCC_CHANNEL_XOR_DISABLE) {
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
swizzle_y = I915_BIT_6_SWIZZLE_9;
- } else if (IS_I965GM(dev) || IS_GM45(dev)) {
- /* GM965 only does bit 11-based channel
-* randomization
+ } else if ((IS_I965GM(dev) || IS_GM45(dev)) &&
+ (dcc & DCC_CHANNEL_XOR_BIT_17) == 0) {
+ /* GM965/GM45 does either bit 11 or bit 17
+* swizzling.
*/
swizzle_x = I915_BIT_6_SWIZZLE_9_10_11;
swizzle_y = I915_BIT_6_SWIZZLE_9_11;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0e476eb..9d24aae 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -522,6 +522,7 @@
#define DCC_ADDRESSING_MODE_DUAL_CHANNEL_INTERLEAVED (2 << 0)
#define DCC_ADDRESSING_MODE_MASK (3 << 0)
#define DCC_CHANNEL_XOR_DISABLE(1 << 10)
+#define DCC_CHANNEL_XOR_BIT_17 (1 << 9)
/** 965 MCH register controlling DRAM channel configuration */
#define C0DRB3 0x10206
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [drm/i915] Retry execbuffer pinning after clearing the GTT
On Fri, 2008-11-21 at 01:00 -0800, Keith Packard wrote:
> If we fail to pin all of the buffers in an execbuffer request, go through
> and clear the GTT and try again to see if its just a matter of fragmentation
>
> Signed-off-by: Keith Packard <[EMAIL PROTECTED]>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 51
> ---
> 1 files changed, 42 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7fd1b26..3e54e94 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1089,6 +1089,19 @@ i915_gem_evict_something(struct drm_device *dev)
> }
>
> static int
> +i915_gem_evict_everything(struct drm_device *dev)
> +{
> + int ret;
> +
> + for (;;) {
> + ret = i915_gem_evict_something(dev);
> + if (ret != -ENOMEM)
I think this test should be != 0. We want to stop if there's nothing
left to evict (-ENOMEM) and also if we get interrupted (-ERESTARTSYS).
Is there any error we want to actually ignore?
> + break;
> + }
> + return ret;
> +}
> +
> +static int
> i915_gem_object_get_page_list(struct drm_gem_object *obj)
> {
> struct drm_i915_gem_object *obj_priv = obj->driver_private;
> @@ -1896,6 +1909,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
> int ret, i, pinned = 0;
> uint64_t exec_offset;
> uint32_t seqno, flush_domains;
> + int pin_tries;
>
> #if WATCH_EXEC
> DRM_INFO("buffers_ptr %d buffer_count %d len %08x\n",
> @@ -1957,17 +1971,36 @@ i915_gem_execbuffer(struct drm_device *dev, void
> *data,
> }
>
> /* Pin and relocate */
> - for (i = 0; i < args->buffer_count; i++) {
> - object_list[i]->pending_read_domains = 0;
> - object_list[i]->pending_write_domain = 0;
> - ret = i915_gem_object_pin_and_relocate(object_list[i],
> -file_priv,
> -&exec_list[i]);
> - if (ret) {
> - DRM_ERROR("object bind and relocate failed %d\n", ret);
> + for (pin_tries = 0; ; pin_tries++) {
> + ret = 0;
> + for (i = 0; i < args->buffer_count; i++) {
> + object_list[i]->pending_read_domains = 0;
> + object_list[i]->pending_write_domain = 0;
> + ret = i915_gem_object_pin_and_relocate(object_list[i],
> +file_priv,
> +&exec_list[i]);
> + if (ret)
> + break;
> + pinned = i + 1;
> + }
> + /* success */
> + if (ret == 0)
> + break;
> +
> + /* error other than GTT full, or we've already tried again */
> + if (ret != -ENOMEM || pin_tries >= 1) {
> + DRM_ERROR("Failed to pin buffers %d\n", ret);
> goto err;
> }
ret could be -EINTR, since pin_and_relocate could have waited on space
to evict someone, in which case we should quietly return to userland.
> - pinned = i + 1;
> +
> + /* unpin all of our buffers */
> + for (i = 0; i < pinned; i++)
> + i915_gem_object_unpin(object_list[i]);
> +
> + /* evict everyone we can from the aperture */
> + ret = i915_gem_evict_everything(dev);
> + if (ret)
> + goto err;
> }
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [drm/i915] In execbuffer, split handle lookup and relocation
On Fri, 2008-11-21 at 01:00 -0800, Keith Packard wrote:
> Splitting these will make re-trying the relocation cleaner
I like it, but I'll fold it into the next patch.
> Signed-off-by: Keith Packard <[EMAIL PROTECTED]>
> ---
> drivers/gpu/drm/i915/i915_gem.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3e074ab..7fd1b26 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1944,7 +1944,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
> return -EBUSY;
> }
>
> - /* Look up object handles and perform the relocations */
> + /* Look up object handles */
> for (i = 0; i < args->buffer_count; i++) {
> object_list[i] = drm_gem_object_lookup(dev, file_priv,
> exec_list[i].handle);
> @@ -1954,7 +1954,10 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
> ret = -EBADF;
> goto err;
> }
> + }
>
> + /* Pin and relocate */
> + for (i = 0; i < args->buffer_count; i++) {
> object_list[i]->pending_read_domains = 0;
> object_list[i]->pending_write_domain = 0;
> ret = i915_gem_object_pin_and_relocate(object_list[i],
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel renderbuffer formats
On Sun, 2008-11-16 at 15:53 +0100, Philipp Klaus Krause wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > In intel_fbo.c from the 965 driver RGBA, GL_RGBA2, GL_RGBA4, GL_RGB5_A1, > GL_RGBA8, GL_RGB10_A2, GL_RGBA12 and GL_RGBA16 are all mapped to GL_RGBA8. > > Is this limit imposed by the hardware or the driver? Can the hardware do > RGBA16? The public specs list r10g10b10a2, r16g16b16a16, and many others as available formats. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel text mode restore problem
On Tue, 2008-12-09 at 19:11 +0100, Norbert Preining wrote: > Dear all, > > (please Cc) > > I would like to report two problems with the following system: > > Hardware: > Sony Vaio VGN-Z11 > Chipset Mobile Intel® GM45 Express Chipset found > (and in addition a nVidia chipset, both built into the laptop, > but via switch only intel one is selected) > > Software: > kernel 2.6.28-rc7 (and several kernels before) > Debian/sid: > xorg 7.3, xserver 1.4.2 > > There are two problems with this laptop: The first is that often (or > better always) when I start X and run it for some time (no idea what is > necessary), and then switch to the console the text mode is not > restored. The effect is that on the top of the screen there is probably > one of maybe two screen lines of the characters shown (screen lines > means 1 pixel lines) and the whole screen is flashing. The rest of the > screen is dark/grey and flashing. > > Interestingly. Doing from the text console a switch to X and back fixes > that for some time. But waiting a bit doing things in X and switching > again to the Console makes the effect re-appear. > > The other problem is that sometimes, hard to reproduce but it happens > again and again, gdm starts up with a bit strange dimensions: It > occupies a considerably smaller portion of the screen, as shown in the > attached screenshot. > > It would be great if we can track down the issues of that, or if that is > the wrong contact point please let me know who is responsible. If you > need any further data (dmesg, kernel config, X log file, ...) please let > me know. > > Thanks a lot and all the best For the first issue, it's often hard to tell what's going wrong as the registers will be the same as far as we can see between success and failure. The difficulty of recovering text mode is one of the reasons that text mode is going away with kernel modesetting (planned for 2.6.29). intel_reg_dumper from the 2d driver build tree may help debug what's different between success and failure of vt switching today. Second issue sounds like sometimes you get DDC and sometimes you don't, but when you don't there isn't BIOS data to fall back on so you end up using the console mode (which has a small active area, and we don't set scaling because we assume that that's the real 1:1 native mode). Xorg.0.log between success and failure would be the way to tell. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Reallocate frame buffer on resize
rn->displayWidth;
> -int i;
> Bool tiled = FALSE;
>
> -/*
> - * Adjust the display width to allow for front buffer tiling if possible
> - */
> -if (pI830->tiling) {
> - if (IS_I965G(pI830)) {
> - int tile_pixels = 512 / pI830->cpp;
> - pScrn->displayWidth = (pScrn->displayWidth + tile_pixels - 1) &
> - ~(tile_pixels - 1);
> - tiled = TRUE;
> - } else {
> - /* Good pitches to allow tiling. Don't care about pitches < 1024
> - * pixels.
> - */
> - static const int pitches[] = {
> - 1024,
> - 2048,
> - 4096,
> - 8192,
> - 0
> - };
> -
> - for (i = 0; pitches[i] != 0; i++) {
> - if (pitches[i] >= pScrn->displayWidth) {
> - pScrn->displayWidth = pitches[i];
> - tiled = TRUE;
> - break;
> - }
> - }
> - }
> -}
> +tiled = i830_tiled_width(pI830, &pScrn->displayWidth, pI830->cpp);
> /* Set up our video memory allocator for the chosen videoRam */
> if (!i830_allocator_init(pScrn, 0, pScrn->videoRam * KB(1))) {
> xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
> @@ -3043,7 +3112,7 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen, int
> argc, char **argv)
> if (!pI830->use_drm_mode)
> hwp = VGAHWPTR(pScrn);
>
> - pScrn->displayWidth = (pScrn->virtualX + 63) & ~63;
> + pScrn->displayWidth = i830_pad_drawable_width(pScrn->virtualX);
>
> /*
> * The "VideoRam" config file parameter specifies the maximum amount of
> @@ -3105,7 +3174,7 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen, int
> argc, char **argv)
> /* If DRI hasn't been explicitly disabled, try to initialize it.
> * It will be used by the memory allocator.
> */
> - if (pI830->directRenderingType == DRI_NONE && I830DRIScreenInit(pScreen))
> + if (!pI830->can_resize && pI830->directRenderingType == DRI_NONE &&
> I830DRIScreenInit(pScreen))
> pI830->directRenderingType = DRI_XF86DRI;
> #endif
>
> diff --git a/src/i830_exa.c b/src/i830_exa.c
> index 3e3487e..ced31a8 100644
> --- a/src/i830_exa.c
> +++ b/src/i830_exa.c
> @@ -758,6 +758,28 @@ i830_get_pixmap_bo(PixmapPtr pixmap)
> return NULL;
> }
>
> +void
> +i830_set_pixmap_bo(PixmapPtr pixmap, dri_bo *bo)
> +{
> +ScrnInfoPtr pScrn = xf86Screens[pixmap->drawable.pScreen->myNum];
> +I830Ptr i830 = I830PTR(pScrn);
> +dri_bo *old_bo = i830_get_pixmap_bo (pixmap);
> +
> +if (old_bo)
> + dri_bo_unreference (old_bo);
> +#if I830_USE_UXA
> +if (i830->accel == ACCEL_UXA)
> + dixSetPrivate(&pixmap->devPrivates, &uxa_pixmap_index, bo);
> +#endif
> +#ifdef XF86DRM_MODE
> +if (i830->accel == ACCEL_EXA) {
> + struct i830_exa_pixmap_priv *driver_priv =
> + exaGetPixmapDriverPrivate(pixmap);
> + if (driver_priv)
> + driver_priv->bo = bo;
> +}
> +#endif
> +}
> #if defined(I830_USE_UXA)
>
> static void
> diff --git a/src/i830_memory.c b/src/i830_memory.c
> index ca15964..132642f 100644
> --- a/src/i830_memory.c
> +++ b/src/i830_memory.c
> @@ -918,10 +918,13 @@ i830_allocate_memory_tiled(ScrnInfoPtr pScrn, const
> char *name,
> mem = i830_allocate_memory(pScrn, name, aper_size, aper_align, flags);
> if (mem == NULL)
> return NULL;
> +i830_unbind_memory(pScrn, mem);
> mem->size = size;
> mem->tiling = tile_format;
> mem->pitch = pitch;
> mem->fence_nr = -1;
> +if (pScrn->vtSema || pI830->use_drm_mode)
> + i830_bind_memory(pScrn, mem);
>
> #ifdef XF86DRI
> if (mem->bo != 0) {
> @@ -1145,7 +1148,7 @@ IsTileable(ScrnInfoPtr pScrn, int pitch)
> * \param pI830 I830Ptr for the screen being allocated.
> * \param FbMemBox
> */
> -static i830_memory *
> +i830_memory *
> i830_allocate_framebuffer(ScrnInfoPtr pScrn, I830Ptr pI830, BoxPtr FbMemBox,
> Bool secondary)
> {
> @@ -1167,10 +1170,14 @@ i830_allocate_framebuffer(ScrnInfoPtr pScrn, I830Ptr
> pI830, BoxPtr FbMemBox,
> /* We'll allocate the fb such that the root window will fit regardless of
> * rotation.
> */
> -if (!pI830->use_drm_mode && pScrn->virtualX > pScrn->virtualY)
> - fb_height = pScrn->virtualX;
> -else
> - fb_height = pScrn->virtualY;
> +fb_height = pScrn->virtualY;
> +if (!pI830->can_resize)
> +{
> + if (!pI830->use_drm_mode && pScrn->virtualX > pScrn->virtualY)
> + fb_height = pScrn->virtualX;
> + else
> + fb_height = pScrn->virtualY;
> +}
>
> FbMemBox->x1 = 0;
> FbMemBox->x2 = pScrn->displayWidth;
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] libdrm merge of KMS bits
3
> -#define DRM_BO_MEM_PRIV1 4
> -#define DRM_BO_MEM_PRIV2 5
> -#define DRM_BO_MEM_PRIV3 6
> -#define DRM_BO_MEM_PRIV4 7
> -
> -#define DRM_BO_MEM_TYPES 8 /* For now. */
> -
> -#define DRM_BO_LOCK_UNLOCK_BM (1 << 0)
> -#define DRM_BO_LOCK_IGNORE_NO_EVICT (1 << 1)
> -
> -struct drm_bo_version_arg {
> - uint32_t major;
> - uint32_t minor;
> - uint32_t patchlevel;
> -};
> -
> -struct drm_mm_type_arg {
> - unsigned int mem_type;
> - unsigned int lock_flags;
> -};
> -
> -struct drm_mm_init_arg {
> - unsigned int magic;
> - unsigned int major;
> - unsigned int minor;
> - unsigned int mem_type;
> - uint64_t p_offset;
> - uint64_t p_size;
> -};
> -
> -struct drm_mm_info_arg {
> - unsigned int mem_type;
> - uint64_t p_size;
> -};
> -
I think some of the drivers that are still left in the external kernel
code will get angry about this.
> @@ -363,6 +363,10 @@ typedef struct drm_i915_vblank_swap {
> #define MMIO_REGS_CL_INVOCATION_COUNT6
> #define MMIO_REGS_PS_INVOCATION_COUNT7
> #define MMIO_REGS_PS_DEPTH_COUNT 8
> +#define MMIO_REGS_DOVSTA 9
> +#define MMIO_REGS_GAMMA 10
> +#define MMIO_REGS_FENCE 11
> +#define MMIO_REGS_FENCE_NEW 12
>
> typedef struct drm_i915_mmio_entry {
> unsigned int flag;
> @@ -380,58 +384,6 @@ typedef struct drm_i915_hws_addr {
> uint64_t addr;
> } drm_i915_hws_addr_t;
>
> -/*
> - * Relocation header is 4 uint32_ts
> - * 0 - 32 bit reloc count
> - * 1 - 32-bit relocation type
> - * 2-3 - 64-bit user buffer handle ptr for another list of relocs.
> - */
> -#define I915_RELOC_HEADER 4
> -
> -/*
> - * type 0 relocation has 4-uint32_t stride
> - * 0 - offset into buffer
> - * 1 - delta to add in
> - * 2 - buffer handle
> - * 3 - reserved (for optimisations later).
> - */
> -/*
> - * type 1 relocation has 4-uint32_t stride.
> - * Hangs off the first item in the op list.
> - * Performed after all valiations are done.
> - * Try to group relocs into the same relocatee together for
> - * performance reasons.
> - * 0 - offset into buffer
> - * 1 - delta to add in
> - * 2 - buffer index in op list.
> - * 3 - relocatee index in op list.
> - */
> -#define I915_RELOC_TYPE_0 0
> -#define I915_RELOC0_STRIDE 4
> -#define I915_RELOC_TYPE_1 1
> -#define I915_RELOC1_STRIDE 4
> -
> -
> -struct drm_i915_op_arg {
> - uint64_t next;
> - uint64_t reloc_ptr;
> - int handled;
> - unsigned int pad64;
> - union {
> - struct drm_bo_op_req req;
> - struct drm_bo_arg_rep rep;
> - } d;
> -
> -};
> -
> -struct drm_i915_execbuffer {
> - uint64_t ops_list;
> - uint32_t num_buffers;
> - struct drm_i915_batchbuffer batch;
> - drm_context_t context; /* for lockless use in the future */
> - struct drm_fence_arg fence_arg;
> -};
> -
> struct drm_i915_gem_init {
> /**
>* Beginning offset in the GTT to be managed by the DRM memory
Looks like it shouldn't be part of this patchset.
> --- /dev/null
> +++ b/tests/modedemo/demo.c
> @@ -0,0 +1,634 @@
> +/*
> + * Some defines to define the behavior of the program
> + */
This code should have a license on it if it's in our tree.
> --- /dev/null
> +++ b/tests/modefb/demo.c
> @@ -0,0 +1,230 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "linux/fb.h"
> +#include
> +#include "sys/ioctl.h"
> +#include "xf86drm.h"
> +#include "xf86drmMode.h"
Same.
> --- /dev/null
> +++ b/tests/modehotplug/demo.c
> @@ -0,0 +1,157 @@
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "xf86drm.h"
> +#include "xf86drmMode.h"
Same.
> diff --git a/tests/modeprint/modetest.c b/tests/modeprint/modetest.c
> new file mode 100644
> index 000..cefa526
> --- /dev/null
> +++ b/tests/modeprint/modetest.c
> @@ -0,0 +1,371 @@
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "xf86drm.h"
> +#include "xf86drmMode.h"
Same.
(Oh, and a nice doxygen about what the test app does would be awesome)
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [intel] Dump out memory usage information when the kernel fails to pin
On Fri, 2008-12-12 at 10:42 -0800, Keith Packard wrote:
> The execbuffer ioctl returns ENOMEM when it fails to pin all of the buffers
> in the GTT. This is usually caused by the DRM client attempting to use too
> much memory in a single request. Dumping out the requested and available
> memory values should help point out failures in the DRM code to catch over
> commitments of this form.
looks good to me.
> Signed-off-by: Keith Packard
> ---
> libdrm/intel/intel_bufmgr_gem.c | 70 ++
> 1 files changed, 55 insertions(+), 15 deletions(-)
>
> diff --git a/libdrm/intel/intel_bufmgr_gem.c b/libdrm/intel/intel_bufmgr_gem.c
> index be41474..3958f43 100644
> --- a/libdrm/intel/intel_bufmgr_gem.c
> +++ b/libdrm/intel/intel_bufmgr_gem.c
> @@ -164,6 +164,12 @@ struct _drm_intel_bo_gem {
>
> static void drm_intel_gem_bo_reference_locked(drm_intel_bo *bo);
>
> +static unsigned int
> +drm_intel_gem_estimate_batch_space(drm_intel_bo **bo_array, int count);
> +
> +static unsigned int
> +drm_intel_gem_compute_batch_space(drm_intel_bo **bo_array, int count);
> +
> static int
> logbase2(int n)
> {
> @@ -913,6 +919,14 @@ drm_intel_gem_bo_exec(drm_intel_bo *bo, int used,
> ret = ioctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_EXECBUFFER, &execbuf);
> } while (ret != 0 && errno == EAGAIN);
>
> +if (ret != 0 && errno == ENOMEM) {
> + fprintf(stderr, "Execbuffer fails to pin. Estimate: %u. Actual: %u.
> Available: %u\n",
> + drm_intel_gem_estimate_batch_space(bufmgr_gem->exec_bos,
> +bufmgr_gem->exec_count),
> + drm_intel_gem_compute_batch_space(bufmgr_gem->exec_bos,
> + bufmgr_gem->exec_count),
> + bufmgr_gem->gtt_size);
> +}
> drm_intel_update_buffer_offsets (bufmgr_gem);
>
> if (bufmgr_gem->bufmgr.debug)
> @@ -1100,6 +1114,43 @@
> drm_intel_gem_bo_clear_aperture_space_flag(drm_intel_bo *bo)
> }
>
> /**
> + * Return a conservative estimate for the amount of aperture required
> + * for a collection of buffers. This may double-count some buffers.
> + */
> +static unsigned int
> +drm_intel_gem_estimate_batch_space(drm_intel_bo **bo_array, int count)
> +{
> +int i;
> +unsigned int total = 0;
> +
> +for (i = 0; i < count; i++) {
> + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *)bo_array[i];
> + if (bo_gem != NULL)
> + total += bo_gem->reloc_tree_size;
> +}
> +return total;
> +}
> +
> +/**
> + * Return the amount of aperture needed for a collection of buffers.
> + * This avoids double counting any buffers, at the cost of looking
> + * at every buffer in the set.
> + */
> +static unsigned int
> +drm_intel_gem_compute_batch_space(drm_intel_bo **bo_array, int count)
> +{
> +int i;
> +unsigned int total = 0;
> +
> +for (i = 0; i < count; i++)
> + total += drm_intel_gem_bo_get_aperture_space(bo_array[i]);
> +
> +for (i = 0; i < count; i++)
> + drm_intel_gem_bo_clear_aperture_space_flag(bo_array[i]);
> +return total;
> +}
> +
> +/**
> * Return -1 if the batchbuffer should be flushed before attempting to
> * emit rendering referencing the buffers pointed to by bo_array.
> *
> @@ -1121,24 +1172,13 @@ drm_intel_gem_check_aperture_space(drm_intel_bo
> **bo_array, int count)
> drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem
> *)bo_array[0]->bufmgr;
> unsigned int total = 0;
> unsigned int threshold = bufmgr_gem->gtt_size * 3 / 4;
> -int i;
>
> -for (i = 0; i < count; i++) {
> - drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *)bo_array[i];
> - if (bo_gem != NULL)
> - total += bo_gem->reloc_tree_size;
> -}
> +total = drm_intel_gem_estimate_batch_space(bo_array, count);
> +
> +if (total > threshold)
> + total = drm_intel_gem_compute_batch_space(bo_array, count);
>
> if (total > threshold) {
> - total = 0;
> - for (i = 0; i < count; i++)
> - total += drm_intel_gem_bo_get_aperture_space(bo_array[i]);
> -
> - for (i = 0; i < count; i++)
> - drm_intel_gem_bo_clear_aperture_space_flag(bo_array[i]);
> -}
> -
> -if (total > bufmgr_gem->gtt_size * 3 / 4) {
> DBG("check_space: overflowed available aperture, %dkb vs %dkb\n",
> total / 1024, (int)bufmgr_gem->gtt_size / 1024);
> return -1;
> --
> 1.5.6.5
>
> ___
> Intel-
Re: [Intel-gfx] [PATCH] intel: Limit re-use cache size
On Mon, 2008-12-15 at 15:08 -0800, Keith Packard wrote:
> This limits reuse to 16MB per cache level to try and reduce application
> memory consumption.
Is 16MB based on any measurements at all?
I don't like this patch. I'd prefer to have us figure out bugs that
make the cache grow overly large, and free old buffers (which we *still*
haven't done), instead of having static limits that'll just hide failure
so that you end up with both poor performance and excessive memory
consumption.
> Signed-off-by: Keith Packard
> ---
> libdrm/intel/intel_bufmgr_gem.c |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/libdrm/intel/intel_bufmgr_gem.c b/libdrm/intel/intel_bufmgr_gem.c
> index 4d1f7d1..5ba12a9 100644
> --- a/libdrm/intel/intel_bufmgr_gem.c
> +++ b/libdrm/intel/intel_bufmgr_gem.c
> @@ -1291,7 +1291,13 @@ drm_intel_bufmgr_gem_enable_reuse(drm_intel_bufmgr
> *bufmgr)
> int i;
>
> for (i = 0; i < DRM_INTEL_GEM_BO_BUCKETS; i++) {
> - bufmgr_gem->cache_bucket[i].max_entries = -1;
> + int max;
> +
> + if (i > 12)
> + max = 1;
> + else
> + max = 4096 >> i;
> + bufmgr_gem->cache_bucket[i].max_entries = max;
> }
> }
>
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] intel: Cache tiling/swizzle state in user mode. Reset tiling on reuse.
= 0 && *tiling_mode == bo_gem->tiling_mode)
> + return 0;
> +
> set_tiling.handle = bo_gem->gem_handle;
> set_tiling.tiling_mode = *tiling_mode;
> set_tiling.stride = stride;
>
> ret = ioctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_SET_TILING, &set_tiling);
> if (ret != 0) {
> - *tiling_mode = I915_TILING_NONE;
> + *tiling_mode = bo_gem->tiling_mode;
> return -errno;
> }
> +bo_gem->tiling_mode = set_tiling.tiling_mode;
> +bo_gem->swizzle_mode = set_tiling.swizzle_mode;
>
> -*tiling_mode = set_tiling.tiling_mode;
> +*tiling_mode = bo_gem->tiling_mode;
> return 0;
> }
>
> @@ -1031,22 +1070,10 @@ static int
> drm_intel_gem_bo_get_tiling(drm_intel_bo *bo, uint32_t *tiling_mode,
> uint32_t *swizzle_mode)
> {
> -drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bo->bufmgr;
> drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *)bo;
> -struct drm_i915_gem_get_tiling get_tiling;
> -int ret;
> -
> -get_tiling.handle = bo_gem->gem_handle;
> -
> -ret = ioctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_GET_TILING, &get_tiling);
> -if (ret != 0) {
> - *tiling_mode = I915_TILING_NONE;
> - *swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
> - return -errno;
> -}
>
> -*tiling_mode = get_tiling.tiling_mode;
> -*swizzle_mode = get_tiling.swizzle_mode;
> +*tiling_mode = bo_gem->tiling_mode;
> +*swizzle_mode = bo_gem->swizzle_mode;
> return 0;
> }
>
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Make i830_allocate_memory take tiling parameters.
; IsTileable(pScrn, pitch))
> {
> - enum tile_format tile_format;
> -
> - size = ROUND_TO_PAGE(pitch * ALIGN(height, 16));
> -
> /* The 965 requires that the depth buffer be in Y Major format, while
>* the rest appear to fail when handed that format.
>*/
> tile_format = IS_I965G(pI830) ? TILE_YMAJOR: TILE_XMAJOR;
> -
> - pI830->depth_buffer =
> - i830_allocate_memory_tiled(pScrn, "depth buffer", size, pitch,
> -GTT_PAGE_SIZE,
> -ALIGN_BOTH_ENDS |
> -ALLOW_SHARING,
> -tile_format);
> + height = ALIGN(height, 16);
> + flags |= ALIGN_BOTH_ENDS;
> }
> +size = ROUND_TO_PAGE(pitch * height);
>
> -/* Otherwise, allocate it linear. The offset must stay constant
> - * currently because we don't ever update the DRI maps after screen init.
> - */
> -if (pI830->depth_buffer == NULL) {
> - size = ROUND_TO_PAGE(pitch * height);
> - pI830->depth_buffer =
> - i830_allocate_memory(pScrn, "depth buffer", size, GTT_PAGE_SIZE,
> - ALLOW_SHARING);
> -}
> +pI830->depth_buffer =
> + i830_allocate_memory(pScrn, "depth buffer", size, pitch,
> + GTT_PAGE_SIZE, flags, tile_format);
>
> if (pI830->depth_buffer == NULL) {
> xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
> @@ -1703,9 +1685,11 @@ i830_allocate_texture_memory(ScrnInfoPtr pScrn)
>* made conditional on DRM version.
>*/
> pI830->textures = i830_allocate_memory(pScrn, "classic textures", size,
> +PITCH_NONE,
> GTT_PAGE_SIZE,
> ALLOW_SHARING |
> -NEED_LIFETIME_FIXED);
> +NEED_LIFETIME_FIXED,
> +TILE_NONE);
> if (pI830->textures == NULL) {
> xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
> "Failed to allocate texture space.\n");
> @@ -1730,7 +1714,8 @@ i830_allocate_hwstatus(ScrnInfoPtr pScrn)
> if (HWS_NEED_NONSTOLEN(pI830))
> flags |= NEED_NON_STOLEN;
> pI830->hw_status = i830_allocate_memory(pScrn, "HW status",
> - HWSTATUS_PAGE_SIZE, GTT_PAGE_SIZE, flags);
> + HWSTATUS_PAGE_SIZE, PITCH_NONE, GTT_PAGE_SIZE, flags,
> + TILE_NONE);
> if (pI830->hw_status == NULL) {
> xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
> "Failed to allocate hw status page.\n");
> @@ -1745,8 +1730,10 @@ i830_allocate_pwrctx(ScrnInfoPtr pScrn)
> I830Ptr pI830 = I830PTR(pScrn);
>
> pI830->power_context = i830_allocate_memory(pScrn, "power context",
> - PWRCTX_SIZE, GTT_PAGE_SIZE,
> - NEED_LIFETIME_FIXED);
> + PWRCTX_SIZE, PITCH_NONE,
> + GTT_PAGE_SIZE,
> + NEED_LIFETIME_FIXED,
> + TILE_NONE);
> if (!pI830->power_context) {
> xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
> "Failed to allocate power context.\n");
> @@ -1812,6 +1799,11 @@ i830_set_tiling(ScrnInfoPtr pScrn, unsigned int offset,
>
> assert(tile_format != TILE_NONE);
>
> +if (pI830->need_sync) {
> + I830Sync(pScrn);
> + pI830->need_sync = FALSE;
> +}
> +
> if (IS_I965G(pI830))
> max_fence = FENCE_NEW_NR;
> else
> @@ -2115,8 +2107,8 @@ Bool i830_allocate_xvmc_buffer(ScrnInfoPtr pScrn, const
> char *name,
> i830_memory **buffer, unsigned long size,
> int flags)
> {
> -*buffer = i830_allocate_memory(pScrn, name, size,
> - GTT_PAGE_SIZE, flags);
> +*buffer = i830_allocate_memory(pScrn, name, size, PITCH_NONE,
> + GTT_PAGE_SIZE, flags, TILE_NONE);
>
> if (!*buffer) {
> xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
> diff --git a/src/i830_video.c b/src/i830_video.c
> index 87fa020..8a3718d 100644
> --- a/src/i830_video.c
> +++ b/src/i830_video.c
> @@ -2389,8 +2389,9 @@ I830PutImage(ScrnInfoPtr pScrn,
> }
>
> if (pPriv->buf == NULL) {
> - pPriv->buf = i830_allocate_memory(pScrn, "xv buffer", alloc_size, 16,
> - 0);
> + pPriv->buf = i830_allocate_memory(pScrn, "xv buffer",
> + alloc_size, 0, 16,
> + 0, TILE_NONE);
> }
>
> if (pPriv->buf == NULL)
> @@ -2724,7 +2725,7 @@ I830AllocateSurface(ScrnInfoPtr pScrn,
> fbpitch = pI830->cpp * pScrn->displayWidth;
> size = pitch * h;
>
> -pPriv->buf = i830_allocate_memory(pScrn, "xv surface buffer", size, 16,
> 0);
> +pPriv->buf = i830_allocate_memory(pScrn, "xv surface buffer", size, 0,
> 16, 0, TILE_NONE);
> if (pPriv->buf == NULL) {
> xfree(surface->pitches);
> xfree(surface->offsets);
> diff --git a/src/i965_hwmc.c b/src/i965_hwmc.c
> index 1c293d1..99e86f5 100644
> --- a/src/i965_hwmc.c
> +++ b/src/i965_hwmc.c
> @@ -49,7 +49,7 @@ static int alloc_drm_memory_tiled(ScrnInfoPtr pScrn,
> char *name, size_t size, unsigned long pitch, unsigned long alignment)
> {
> I830Ptr pI830 = I830PTR(pScrn);
> -if ((mem->buffer = i830_allocate_memory_tiled(pScrn,
> +if ((mem->buffer = i830_allocate_memory(pScrn,
> name, size, pitch,
> GTT_PAGE_SIZE, ALIGN_BOTH_ENDS, TILE_XMAJOR)) == NULL) {
> ErrorF("Fail to alloc \n");
> @@ -75,8 +75,8 @@ static int alloc_drm_memory(ScrnInfoPtr pScrn,
> {
> I830Ptr pI830 = I830PTR(pScrn);
> if ((mem->buffer = i830_allocate_memory(pScrn,
> - name, size,
> - GTT_PAGE_SIZE, ALIGN_BOTH_ENDS)) == NULL) {
> + name, size, PITCH_NONE, GTT_PAGE_SIZE,
> + ALIGN_BOTH_ENDS, TILE_NONE)) == NULL) {
> ErrorF("Fail to alloc \n");
> return BadAlloc;
> }
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] intel: When re-use cache is full, wait instead of allocating
On Mon, 2008-12-15 at 15:08 -0800, Keith Packard wrote:
> This limits application memory usage by waiting for the GPU to free memory
> rather than simply continuing to allocate more memory.
I think I theoretically prefer the current behavior in the presence of
max_entries where you still alloc a new buffer (so you're not syncing)
but you free the buffer being unreferenced instead of adding it to the
cache.
Of course, I haven't run with max_entries yet since we shouldn't need
it.
> Signed-off-by: Keith Packard
> ---
> libdrm/intel/intel_bufmgr_gem.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libdrm/intel/intel_bufmgr_gem.c b/libdrm/intel/intel_bufmgr_gem.c
> index 323007a..9f6ef68 100644
> --- a/libdrm/intel/intel_bufmgr_gem.c
> +++ b/libdrm/intel/intel_bufmgr_gem.c
> @@ -350,8 +350,12 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr, const
> char *name,
> bo_gem = bucket->head;
> busy.handle = bo_gem->gem_handle;
>
> -ret = ioctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_BUSY, &busy);
> -alloc_from_cache = (ret == 0 && busy.busy == 0);
> + if (bucket->max_entries != -1 && bucket->num_entries >=
> bucket->max_entries)
> + alloc_from_cache = 1;
> + else {
> + ret = ioctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_BUSY, &busy);
> + alloc_from_cache = (ret == 0 && busy.busy == 0);
> + }
>
> if (alloc_from_cache) {
> bucket->head = bo_gem->next;
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] intel: Sync GEM ioctl comments for easier diffing against the kernel.
---
shared-core/i915_drm.h | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/shared-core/i915_drm.h b/shared-core/i915_drm.h
index 976ff18..628f7f8 100644
--- a/shared-core/i915_drm.h
+++ b/shared-core/i915_drm.h
@@ -469,8 +469,12 @@ struct drm_i915_gem_pread {
uint64_t offset;
/** Length of data to read */
uint64_t size;
- /** Pointer to write the data into. */
- uint64_t data_ptr; /* void *, but pointers are not 32/64
compatible */
+ /**
+* Pointer to write the data into.
+*
+* This is a fixed-size type for 32/64 compatibility.
+*/
+ uint64_t data_ptr;
};
struct drm_i915_gem_pwrite {
@@ -481,8 +485,12 @@ struct drm_i915_gem_pwrite {
uint64_t offset;
/** Length of data to write */
uint64_t size;
- /** Pointer to read the data from. */
- uint64_t data_ptr; /* void *, but pointers are not 32/64
compatible */
+ /**
+* Pointer to read the data from.
+*
+* This is a fixed-size type for 32/64 compatibility.
+*/
+ uint64_t data_ptr;
};
struct drm_i915_gem_mmap {
@@ -497,8 +505,12 @@ struct drm_i915_gem_mmap {
* The value will be page-aligned.
*/
uint64_t size;
- /** Returned pointer the data was mapped at */
- uint64_t addr_ptr; /* void *, but pointers are not 32/64
compatible */
+ /**
+* Returned pointer the data was mapped at.
+*
+* This is a fixed-size type for 32/64 compatibility.
+*/
+ uint64_t addr_ptr;
};
struct drm_i915_gem_mmap_gtt {
@@ -643,7 +655,8 @@ struct drm_i915_gem_execbuffer {
uint32_t DR1;
uint32_t DR4;
uint32_t num_cliprects;
- uint64_t cliprects_ptr; /* struct drm_clip_rect *cliprects */
+ /** This is a struct drm_clip_rect *cliprects */
+ uint64_t cliprects_ptr;
};
struct drm_i915_gem_pin {
--
1.5.6.5
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] intel: Rename plane[AB]* back to pipe[AB]*.
The values are really going to continue meaning pipe, not plane, and that's
what they're called in the kernel copy of the header. Userland hasn't ever
made the switch to pipe!=plane, since userland checks are based on DRM
version, which is still stuck at 1.6. However, Mesa did start using
plane[AB] names, so provide a compat define.
---
shared-core/i915_drm.h | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/shared-core/i915_drm.h b/shared-core/i915_drm.h
index 628f7f8..04ab4cf 100644
--- a/shared-core/i915_drm.h
+++ b/shared-core/i915_drm.h
@@ -111,14 +111,25 @@ typedef struct drm_i915_sarea {
unsigned int rotated_tiled;
unsigned int rotated2_tiled;
- int planeA_x;
- int planeA_y;
- int planeA_w;
- int planeA_h;
- int planeB_x;
- int planeB_y;
- int planeB_w;
- int planeB_h;
+ /* compat defines for the period of time when pipeA_* got renamed
+* to planeA_*. They mean pipe, really.
+*/
+#define planeA_x pipeA_x
+#define planeA_y pipeA_y
+#define planeA_w pipeA_w
+#define planeA_h pipeA_h
+#define planeB_x pipeB_x
+#define planeB_y pipeB_y
+#define planeB_w pipeB_w
+#define planeB_h pipeB_h
+ int pipeA_x;
+ int pipeA_y;
+ int pipeA_w;
+ int pipeA_h;
+ int pipeB_x;
+ int pipeB_y;
+ int pipeB_w;
+ int pipeB_h;
/* Triple buffering */
drm_handle_t third_handle;
--
1.5.6.5
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Pin new and unpin old buffer when setting a mode.
On Wed, 2008-12-17 at 22:14 -0500, Kristian Høgsberg wrote: > This removes the requirement for user space to pin a buffer before > setting a mode that is backed by the pixels from that buffer. > > Signed-off-by: Kristian Høgsberg Committed. Thanks! -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/6] drm/i915: fix sparse warnings
On Thu, 2008-12-18 at 23:27 +0100, Hannes Eder wrote: > This series of patches fixes a couple of sparse warnings in drm/i915. > > Hannes Eder (6): > drm/i915: fix sparse warnings: declare one-bit bitfield as unsigned > drm/i915: fix sparse warnings: make symbols static > drm/i915: fix sparse warnings: move 'extern' decls to header file > drm/i915: fix sparse warnings: returning void-valued expression > drm/i915: comment out unused function 'i915_driver_firstopen' > drm/i915: add prototype for 'intelfb_panic' to header file Committed this patch series, except for replacing #5 with just deleting the function, and using the updated #6 patch. Thanks! -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] drivers/gpu/drm: Move a dereference below a NULL test
On Sat, 2008-12-20 at 08:35 +1000, Dave Airlie wrote:
> On Sat, Dec 20, 2008 at 3:10 AM, Julia Lawall wrote:
> > From: Julia Lawall
> >
> > If the NULL test is necessary, then the dereference should be moved below
> > the NULL test.
> >
> > The semantic patch that makes this change is as follows:
> > (http://www.emn.fr/x-info/coccinelle/). The result has been modified to
> > move the initialization of driver down closer to where it is used.
> >
> > //
> > @@
> > type T;
> > expression E;
> > identifier i,fld;
> > statement S;
> > @@
> >
> > - T i = E->fld;
> > + T i;
> > ... when != E
> > when != i
> > if (E == NULL) S
> > + i = E->fld;
> > //
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> > drivers/gpu/drm/drm_drv.c |7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 0b9f316..4bdfc98 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -297,7 +297,7 @@ EXPORT_SYMBOL(drm_init);
> > */
> > static void drm_cleanup(struct drm_device * dev)
> > {
> > - struct drm_driver *driver = dev->driver;
> > + struct drm_driver *driver;
> >
> >DRM_DEBUG("\n");
> >
> > @@ -324,8 +324,9 @@ static void drm_cleanup(struct drm_device * dev)
> >dev->agp = NULL;
> >}
> >
> > - if (dev->driver->unload)
> > - dev->driver->unload(dev);
> > + driver = dev->driver;
> > + if (driver->unload)
> > + driver->unload(dev);
>
> Huh?
>
> The original test is to check it dev->driver->unload exists, not it
> dev->driver exists.
>
> I think your test parameters are wrong.
No, it was valid, but I think the better patch is:
From 1e0a24cfe75a328db5a50dbcdaaf0eb461638b6b Mon Sep 17 00:00:00 2001
From: Eric Anholt
Date: Fri, 19 Dec 2008 15:07:11 -0800
Subject: [PATCH] drm: Avoid use-before-null-test on dev in drm_cleanup().
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_drv.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 373e3de..febb517 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -294,8 +294,6 @@ EXPORT_SYMBOL(drm_init);
*/
static void drm_cleanup(struct drm_device * dev)
{
- struct drm_driver *driver = dev->driver;
-
DRM_DEBUG("\n");
if (!dev) {
@@ -330,7 +328,7 @@ static void drm_cleanup(struct drm_device * dev)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_put_minor(&dev->control);
- if (driver->driver_features & DRIVER_GEM)
+ if (dev->driver->driver_features & DRIVER_GEM)
drm_gem_destroy(dev);
drm_put_minor(&dev->primary);
--
1.5.6.5
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Rework DRM proc file handling
On Tue, 2008-12-09 at 14:00 -0500, Ben Gamari wrote: > Hey everyone, > > This is the latest version of my procfs file handling patch. I have > ported the old proc files to use the seq_file interface greatly > simplifying the code. I have also put in place infrastructure for > exporting data through debugfs, creating a dri/ directory in the debugfs > root similar to procfs. I moved /proc/dri/*/vma along with all of the > i915_gem_* files into this directory. Like the proc code, the debugfs > code uses seq_file. This code has all been tested and appears to work. > > Lastly, I ported the old ring buffer dump code to the drm. This creates > a file in debugfs (i915_gem_ringbuf) from which the ring buffer can be > dumped. Currently, the code is only capable of dumping the ring buffer > itself. It'll probably be a few weeks before I have time to think about > getting batchbuffer dumping working. This is the outline I currently > have, > - Search through the active batchbuffer list looking for a batchbuffer > located at the offset indicated in the MI_BATCH_BUFFER_START instruction > - Pin this batchbuffer into memory somewhere > - Dump its contents > - Unpin > > I know practically nothing about gem at the moment, so it'll take me a > while to get up to speed. If someone else wants to try adding > batchbuffer dumping, they are more than welcome. > > At this point, I think the patch is nearing a merge-worthy point. Let me > know what else is needed to get it merged. Could this get split up into a step that converts the existing code to using seq_printf (which seems great!), a second step moving appropriate parts to debugfs (I'm not really sold on this), and another step adding the intel ring dumping (I'm very interested in this)? Then we can look at the individual parts of the project more easily than reviewing a 1700-line patch :) -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Rework DRM proc file handling
On Sat, 2008-12-20 at 09:21 +1000, Dave Airlie wrote: > On Sat, Dec 20, 2008 at 9:19 AM, Eric Anholt wrote: > > On Tue, 2008-12-09 at 14:00 -0500, Ben Gamari wrote: > >> Hey everyone, > >> > >> This is the latest version of my procfs file handling patch. I have > >> ported the old proc files to use the seq_file interface greatly > >> simplifying the code. I have also put in place infrastructure for > >> exporting data through debugfs, creating a dri/ directory in the debugfs > >> root similar to procfs. I moved /proc/dri/*/vma along with all of the > >> i915_gem_* files into this directory. Like the proc code, the debugfs > >> code uses seq_file. This code has all been tested and appears to work. > >> > >> Lastly, I ported the old ring buffer dump code to the drm. This creates > >> a file in debugfs (i915_gem_ringbuf) from which the ring buffer can be > >> dumped. Currently, the code is only capable of dumping the ring buffer > >> itself. It'll probably be a few weeks before I have time to think about > >> getting batchbuffer dumping working. This is the outline I currently > >> have, > >> - Search through the active batchbuffer list looking for a batchbuffer > >> located at the offset indicated in the MI_BATCH_BUFFER_START instruction > >> - Pin this batchbuffer into memory somewhere > >> - Dump its contents > >> - Unpin > >> > >> I know practically nothing about gem at the moment, so it'll take me a > >> while to get up to speed. If someone else wants to try adding > >> batchbuffer dumping, they are more than welcome. > >> > >> At this point, I think the patch is nearing a merge-worthy point. Let me > >> know what else is needed to get it merged. > > > > Could this get split up into a step that converts the existing code to > > using seq_printf (which seems great!), a second step moving appropriate > > parts to debugfs (I'm not really sold on this), and another step adding > > the intel ring dumping (I'm very interested in this)? Then we can look > > at the individual parts of the project more easily than reviewing a > > 1700-line patch :) > > I'm all for that as well, the problem with using /proc for this stuff > is upstream > doesn't want us to use proc for this stuff. In the end we need distros > to start mounting > debugfs maybe I can start kicking some heads in that direction. Yeah, that's my only objection to debugfs -- if I can't ask someone for /whatever/path/i/dont/care/i915_gem_interrupt and have it work, I'm sad. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Add a debug node for vblank state.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_irq.c |9 ++
drivers/gpu/drm/drm_proc.c | 63
include/drm/drmP.h |1 +
3 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 1608f8d..724e505 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -116,6 +116,9 @@ void drm_vblank_cleanup(struct drm_device *dev)
dev->num_crtcs, DRM_MEM_DRIVER);
drm_free(dev->last_vblank, sizeof(*dev->last_vblank) * dev->num_crtcs,
DRM_MEM_DRIVER);
+ drm_free(dev->last_vblank_wait,
+sizeof(*dev->last_vblank_wait) * dev->num_crtcs,
+DRM_MEM_DRIVER);
drm_free(dev->vblank_inmodeset, sizeof(*dev->vblank_inmodeset) *
dev->num_crtcs, DRM_MEM_DRIVER);
@@ -161,6 +164,11 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
if (!dev->last_vblank)
goto err;
+ dev->last_vblank_wait = drm_calloc(num_crtcs, sizeof(u32),
+ DRM_MEM_DRIVER);
+ if (!dev->last_vblank_wait)
+ goto err;
+
dev->vblank_inmodeset = drm_calloc(num_crtcs, sizeof(int),
DRM_MEM_DRIVER);
if (!dev->vblank_inmodeset)
@@ -642,6 +650,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
} else {
DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
vblwait->request.sequence, crtc);
+ dev->last_vblank_wait[crtc] = vblwait->request.sequence;
DRM_WAIT_ON(ret, dev->vbl_queue[crtc], 3 * DRM_HZ,
((drm_vblank_count(dev, crtc)
- vblwait->request.sequence) <= (1 << 23)));
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 7dbaa1a..8df849f 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -49,6 +49,8 @@ static int drm_queues_info(char *buf, char **start, off_t
offset,
int request, int *eof, void *data);
static int drm_bufs_info(char *buf, char **start, off_t offset,
int request, int *eof, void *data);
+static int drm_vblank_info(char *buf, char **start, off_t offset,
+ int request, int *eof, void *data);
static int drm_gem_name_info(char *buf, char **start, off_t offset,
int request, int *eof, void *data);
static int drm_gem_object_info(char *buf, char **start, off_t offset,
@@ -72,6 +74,7 @@ static struct drm_proc_list {
{"clients", drm_clients_info, 0},
{"queues", drm_queues_info, 0},
{"bufs", drm_bufs_info, 0},
+ {"vblank", drm_vblank_info, 0},
{"gem_names", drm_gem_name_info, DRIVER_GEM},
{"gem_objects", drm_gem_object_info, DRIVER_GEM},
#if DRM_DEBUG_CODE
@@ -458,6 +461,66 @@ static int drm_bufs_info(char *buf, char **start, off_t
offset, int request,
}
/**
+ * Called when "/proc/dri/.../vblank" is read.
+ *
+ * \param buf output buffer.
+ * \param start start of output data.
+ * \param offset requested start offset.
+ * \param request requested number of bytes.
+ * \param eof whether there is no more data to return.
+ * \param data private data.
+ * \return number of written bytes.
+ */
+static int drm__vblank_info(char *buf, char **start, off_t offset, int request,
+ int *eof, void *data)
+{
+ struct drm_minor *minor = (struct drm_minor *) data;
+ struct drm_device *dev = minor->dev;
+ int len = 0;
+ int crtc;
+
+ if (offset > DRM_PROC_LIMIT) {
+ *eof = 1;
+ return 0;
+ }
+
+ *start = &buf[offset];
+ *eof = 0;
+
+ for (crtc = 0; crtc < dev->num_crtcs; crtc++) {
+ DRM_PROC_PRINT("CRTC %d enable: %d\n",
+ crtc, atomic_read(&dev->vblank_refcount[crtc]));
+ DRM_PROC_PRINT("CRTC %d counter:%d\n",
+ crtc, drm_vblank_count(dev, crtc));
+ DRM_PROC_PRINT("CRTC %d last wait: %d\n",
+ crtc, dev->last_vblank_wait[crtc]);
+ DRM_PROC_PRINT("CRTC %d in modeset: %d\n",
+ crtc, dev->vblank_inmodeset[crtc]);
+ }
+
+ if (len > request + offset)
+ return request;
+ *eof = 1;
+ return len - offset;
+}
+
+/**
+ * Simply calls _vblank_info() while holding the drm_device::struct_mutex lock.
+ */
+static int drm_vblank_info(char *buf, char **start, off_t offset, int request,
+
Re: [PATCH 2/13] drivers/gpu/drm/i915: Remove redundant test
On Sun, 2008-12-21 at 16:28 +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> object_list is checked to be not NULL near the beginning of the function and
> is not updated subsequently.
>
> A simplified version of the semantic patch that makes this change is as
> follows: (http://www.emn.fr/x-info/coccinelle/)
>
> //
Committed. Thanks!
> ---
> drivers/gpu/drm/i915/i915_gem.c | 11 +--
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index fccf199..78319ec 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2611,13 +2611,12 @@ i915_gem_execbuffer(struct drm_device *dev, void
> *data,
> "back to user (%d)\n",
> args->buffer_count, ret);
> err:
> - if (object_list != NULL) {
> - for (i = 0; i < pinned; i++)
> - i915_gem_object_unpin(object_list[i]);
> + for (i = 0; i < pinned; i++)
> + i915_gem_object_unpin(object_list[i]);
> +
> + for (i = 0; i < args->buffer_count; i++)
> + drm_gem_object_unreference(object_list[i]);
>
> - for (i = 0; i < args->buffer_count; i++)
> - drm_gem_object_unreference(object_list[i]);
> - }
> mutex_unlock(&dev->struct_mutex);
>
> pre_mutex_err:
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] libdrm-2.4.3
I've tagged it and uploaded it. The big update this release is the modesetting userland support. I'm skipping the "shortlog" as it's noisy with the modesetting kernel changes that were merged and then reverted. I'll also push the release script updates to modular that I (almost) used to generate this. git tag: libdrm-2.4.3 http://dri.freedesktop.org/libdrm/libdrm-2.4.3.tar.bz2 MD5: 8a4a46eb3df70af64b5ea240e71f libdrm-2.4.3.tar.bz2 SHA1: 7daff622a1c68d55a02b0fe1a48205188682c018 libdrm-2.4.3.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.3.tar.gz MD5: ddf2876bd8b4b484a9c2a360a835aee8 libdrm-2.4.3.tar.gz SHA1: 465f3b7d26021225ca936043fbfadc2780f13653 libdrm-2.4.3.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: use drm vma accounting functions to make sure VMs don't get lost
On Mon, 2008-12-29 at 09:08 +, Dave Airlie wrote:
> From: Dave Airlie
>
> The gem gtt mapping code didn't use the drm_vm.c accounting open/close,
> it did call the initial drm_vm_open_locked, so it should always do this.
>
> I'm not 100% sure it doesn't need a special open/close pair, but this at
> least makes /proc/dri/0/vma not end up with lots of crap in it. I'm still
> not getting kms + EXA on i915 working at all.
This introduces a lock order reversal between execbuf grabbing
struct_mutex and then copy_to/from_user grabbing the mm lock, and
drm_vm_open grabbing struct_mutex while mm lock is already held.
I guess we need to pull the copy_to/from_user out from execbuf's locked
section? I don't think that's going to be pretty. Do we want
finer-grained locks?
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_vm.c|9 -
> drivers/gpu/drm/i915/i915_drv.c |2 ++
> include/drm/drmP.h |2 ++
> 3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index 3ffae02..132b03d 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -38,9 +38,6 @@
> #include
> #endif
>
> -static void drm_vm_open(struct vm_area_struct *vma);
> -static void drm_vm_close(struct vm_area_struct *vma);
> -
> static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma)
> {
> pgprot_t tmp = vm_get_page_prot(vma->vm_flags);
> @@ -420,7 +417,7 @@ void drm_vm_open_locked(struct vm_area_struct *vma)
> }
> }
>
> -static void drm_vm_open(struct vm_area_struct *vma)
> +void drm_vm_open(struct vm_area_struct *vma)
> {
> struct drm_file *priv = vma->vm_file->private_data;
> struct drm_device *dev = priv->minor->dev;
> @@ -429,6 +426,7 @@ static void drm_vm_open(struct vm_area_struct *vma)
> drm_vm_open_locked(vma);
> mutex_unlock(&dev->struct_mutex);
> }
> +EXPORT_SYMBOL(drm_vm_open);
>
> /**
> * \c close method for all virtual memory types.
> @@ -438,7 +436,7 @@ static void drm_vm_open(struct vm_area_struct *vma)
> * Search the \p vma private data entry in drm_device::vmalist, unlink it,
> and
> * free it.
> */
> -static void drm_vm_close(struct vm_area_struct *vma)
> +void drm_vm_close(struct vm_area_struct *vma)
> {
> struct drm_file *priv = vma->vm_file->private_data;
> struct drm_device *dev = priv->minor->dev;
> @@ -458,6 +456,7 @@ static void drm_vm_close(struct vm_area_struct *vma)
> }
> mutex_unlock(&dev->struct_mutex);
> }
> +EXPORT_SYMBOL(drm_vm_close);
>
> /**
> * mmap DMA memory.
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f8b3df0..61d8ed6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -94,6 +94,8 @@ static int i915_resume(struct drm_device *dev)
>
> static struct vm_operations_struct i915_gem_vm_ops = {
> .fault = i915_gem_fault,
> + .open = drm_vm_open,
> + .close = drm_vm_close,
> };
>
> static struct drm_driver driver = {
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index afb7858..9a736e3 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1058,6 +1058,8 @@ extern int drm_release(struct inode *inode, struct file
> *filp);
> extern int drm_mmap(struct file *filp, struct vm_area_struct *vma);
> extern int drm_mmap_locked(struct file *filp, struct vm_area_struct *vma);
> extern void drm_vm_open_locked(struct vm_area_struct *vma);
> +extern void drm_vm_open(struct vm_area_struct *vma);
> +extern void drm_vm_close(struct vm_area_struct *vma);
> extern unsigned long drm_core_get_map_ofs(struct drm_map * map);
> extern unsigned long drm_core_get_reg_ofs(struct drm_device *dev);
> extern unsigned int drm_poll(struct file *filp, struct poll_table_struct
> *wait);
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Don't allow objects to get bound while VT switched.
This avoids a BUG_ON in the enter_vt path due to objects being in the GTT
when we shouldn't have ever let them be (as we're not supposed to touch the
device during that time).
This was triggered by a change in the 2D driver to use the GTT mapping of
objects after pinning them to improve software fallback performance.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/i915_gem.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cc2ca55..14afc23 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1623,6 +1623,8 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj,
unsigned alignment)
struct drm_mm_node *free_space;
int page_count, ret;
+ if (dev_priv->mm.suspended)
+ return -EBUSY;
if (alignment == 0)
alignment = PAGE_SIZE;
if (alignment & (PAGE_SIZE - 1)) {
@@ -2641,7 +2643,7 @@ i915_gem_object_pin(struct drm_gem_object *obj, uint32_t
alignment)
if (obj_priv->gtt_space == NULL) {
ret = i915_gem_object_bind_to_gtt(obj, alignment);
if (ret != 0) {
- if (ret != -ERESTARTSYS)
+ if (ret != -EBUSY && ret != -ERESTARTSYS)
DRM_ERROR("Failure to bind: %d", ret);
return ret;
}
@@ -3219,20 +3221,21 @@ i915_gem_entervt_ioctl(struct drm_device *dev, void
*data,
dev_priv->mm.wedged = 0;
}
- ret = i915_gem_init_ringbuffer(dev);
- if (ret != 0)
- return ret;
-
dev_priv->mm.gtt_mapping = io_mapping_create_wc(dev->agp->base,
dev->agp->agp_info.aper_size
* 1024 * 1024);
mutex_lock(&dev->struct_mutex);
+ dev_priv->mm.suspended = 0;
+
+ ret = i915_gem_init_ringbuffer(dev);
+ if (ret != 0)
+ return ret;
+
BUG_ON(!list_empty(&dev_priv->mm.active_list));
BUG_ON(!list_empty(&dev_priv->mm.flushing_list));
BUG_ON(!list_empty(&dev_priv->mm.inactive_list));
BUG_ON(!list_empty(&dev_priv->mm.request_list));
- dev_priv->mm.suspended = 0;
mutex_unlock(&dev->struct_mutex);
drm_irq_install(dev);
--
1.5.6.5
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Respect the other stolen memory sizes we know of.
fd.o bug #19336.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/i915_dma.c | 46 ---
drivers/gpu/drm/i915/i915_reg.h |8 ++-
2 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3d7082a..62a4bf7 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -827,6 +827,7 @@ static int i915_probe_agp(struct drm_device *dev, unsigned
long *aperture_size,
struct pci_dev *bridge_dev;
u16 tmp = 0;
unsigned long overhead;
+ unsigned long stolen;
bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0,0));
if (!bridge_dev) {
@@ -866,36 +867,55 @@ static int i915_probe_agp(struct drm_device *dev,
unsigned long *aperture_size,
else
overhead = (*aperture_size / 1024) + 4096;
- switch (tmp & INTEL_855_GMCH_GMS_MASK) {
+ switch (tmp & INTEL_GMCH_GMS_MASK) {
+ case INTEL_855_GMCH_GMS_DISABLED:
+ DRM_ERROR("video memory is disabled\n");
+ return -1;
case INTEL_855_GMCH_GMS_STOLEN_1M:
- break; /* 1M already */
+ stolen = 1 * 1024 * 1024;
+ break;
case INTEL_855_GMCH_GMS_STOLEN_4M:
- *preallocated_size *= 4;
+ stolen = 4 * 1024 * 1024;
break;
case INTEL_855_GMCH_GMS_STOLEN_8M:
- *preallocated_size *= 8;
+ stolen = 8 * 1024 * 1024;
break;
case INTEL_855_GMCH_GMS_STOLEN_16M:
- *preallocated_size *= 16;
+ stolen = 16 * 1024 * 1024;
break;
case INTEL_855_GMCH_GMS_STOLEN_32M:
- *preallocated_size *= 32;
+ stolen = 32 * 1024 * 1024;
break;
case INTEL_915G_GMCH_GMS_STOLEN_48M:
- *preallocated_size *= 48;
+ stolen = 48 * 1024 * 1024;
break;
case INTEL_915G_GMCH_GMS_STOLEN_64M:
- *preallocated_size *= 64;
+ stolen = 64 * 1024 * 1024;
+ break;
+ case INTEL_GMCH_GMS_STOLEN_128M:
+ stolen = 128 * 1024 * 1024;
+ break;
+ case INTEL_GMCH_GMS_STOLEN_256M:
+ stolen = 256 * 1024 * 1024;
+ break;
+ case INTEL_GMCH_GMS_STOLEN_96M:
+ stolen = 96 * 1024 * 1024;
+ break;
+ case INTEL_GMCH_GMS_STOLEN_160M:
+ stolen = 160 * 1024 * 1024;
+ break;
+ case INTEL_GMCH_GMS_STOLEN_224M:
+ stolen = 224 * 1024 * 1024;
+ break;
+ case INTEL_GMCH_GMS_STOLEN_352M:
+ stolen = 352 * 1024 * 1024;
break;
- case INTEL_855_GMCH_GMS_DISABLED:
- DRM_ERROR("video memory is disabled\n");
- return -1;
default:
DRM_ERROR("unexpected GMCH_GMS value: 0x%02x\n",
- tmp & INTEL_855_GMCH_GMS_MASK);
+ tmp & INTEL_GMCH_GMS_MASK);
return -1;
}
- *preallocated_size -= overhead;
+ *preallocated_size = stolen - overhead;
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1024315..2731625 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -35,7 +35,7 @@
#define INTEL_GMCH_MEM_64M 0x1
#define INTEL_GMCH_MEM_128M0
-#define INTEL_855_GMCH_GMS_MASK(0x7 << 4)
+#define INTEL_GMCH_GMS_MASK(0xf << 4)
#define INTEL_855_GMCH_GMS_DISABLED(0x0 << 4)
#define INTEL_855_GMCH_GMS_STOLEN_1M (0x1 << 4)
#define INTEL_855_GMCH_GMS_STOLEN_4M (0x2 << 4)
@@ -45,6 +45,12 @@
#define INTEL_915G_GMCH_GMS_STOLEN_48M (0x6 << 4)
#define INTEL_915G_GMCH_GMS_STOLEN_64M (0x7 << 4)
+#define INTEL_GMCH_GMS_STOLEN_128M (0x8 << 4)
+#define INTEL_GMCH_GMS_STOLEN_256M (0x9 << 4)
+#define INTEL_GMCH_GMS_STOLEN_96M (0xa << 4)
+#define INTEL_GMCH_GMS_STOLEN_160M (0xb << 4)
+#define INTEL_GMCH_GMS_STOLEN_224M (0xc << 4)
+#define INTEL_GMCH_GMS_STOLEN_352M (0xd << 4)
/* PCI config space */
--
1.5.6.5
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Pin cursor bo and unpin old bo when setting cursor.
From: Kristian Høgsberg
We also didn't track the cursor bo before and would leak a reference
when the cursor image was change.
Signed-off-by: Kristian Høgsberg
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/intel_display.c | 29 +
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e5c1c80..1204d26 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -986,19 +986,17 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
uint32_t base = (pipe == 0) ? CURABASE : CURBBASE;
uint32_t temp;
size_t addr;
+ int ret;
DRM_DEBUG("\n");
/* if we want to turn off the cursor ignore width and height */
if (!handle) {
DRM_DEBUG("cursor off\n");
- /* turn of the cursor */
- temp = 0;
- temp |= CURSOR_MODE_DISABLE;
-
- I915_WRITE(control, temp);
- I915_WRITE(base, 0);
- return 0;
+ temp = CURSOR_MODE_DISABLE;
+ addr = 0;
+ bo = NULL;
+ goto finish;
}
/* Currently we only support 64x64 cursors */
@@ -1025,15 +1023,30 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
addr = obj_priv->gtt_offset;
}
- intel_crtc->cursor_addr = addr;
+ ret = i915_gem_object_pin(bo, PAGE_SIZE);
+ if (ret) {
+ DRM_ERROR("failed to pin cursor bo\n");
+ drm_gem_object_unreference(bo);
+ return ret;
+ }
+
temp = 0;
/* set the pipe for the cursor */
temp |= (pipe << 28);
temp |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
+ finish:
I915_WRITE(control, temp);
I915_WRITE(base, addr);
+ if (intel_crtc->cursor_bo) {
+ i915_gem_object_unpin(intel_crtc->cursor_bo);
+ drm_gem_object_unreference(intel_crtc->cursor_bo);
+ }
+
+ intel_crtc->cursor_addr = addr;
+ intel_crtc->cursor_bo = bo;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 407edd5..94981ee 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -88,6 +88,7 @@ struct intel_crtc {
struct drm_crtc base;
int pipe;
int plane;
+ struct drm_gem_object *cursor_bo;
uint32_t cursor_addr;
u8 lut_r[256], lut_g[256], lut_b[256];
int dpms_mode;
--
1.5.6.5
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Don't oops when root asks to unpin an already unpinned buffer.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/i915_gem.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 14afc23..e87db6f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2761,6 +2761,13 @@ i915_gem_unpin_ioctl(struct drm_device *dev, void *data,
mutex_unlock(&dev->struct_mutex);
return -EBADF;
}
+ obj_priv = obj->driver_private;
+
+ if (obj_priv->pin_count == 0) {
+ drm_gem_object_unreference(obj);
+ mutex_unlock(&dev->struct_mutex);
+ return -EINVAL;
+ }
obj_priv = obj->driver_private;
if (obj_priv->pin_filp != file_priv) {
--
1.5.6.5
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
intel KMS and stability series
Here comes a series of patches I've been cleaning up over the last few days. The first couple are bugfixes that we've tripped over with 2.6.28 that I'll want to get merged to stable. The rest are getting KMS ready to go. Dropped from the series is airlied's vma patch, which caused lock ordering complaints. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Fix failure to take the mode_config lock in driver setup.
We're not really concerned with races during setup, but we do want to keep
the warning around given how easy it is to misplace that lock.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_crtc_helper.c |3 +++
drivers/gpu/drm/i915/intel_tv.c |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index d8a982b..f4e6d1d 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -766,7 +766,10 @@ bool drm_helper_initial_config(struct drm_device *dev,
bool can_grow)
{
int ret = false;
+ mutex_lock(&dev->mode_config.mutex);
drm_helper_plugged_event(dev);
+ mutex_unlock(&dev->mode_config.mutex);
+
return ret;
}
EXPORT_SYMBOL(drm_helper_initial_config);
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index fbb35dc..aa36f92 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1704,6 +1704,7 @@ intel_tv_init(struct drm_device *dev)
goto out;
for (i = 0; i < NUM_TV_MODES; i++)
tv_format_names[i] = tv_modes[i].name;
+ mutex_lock(&dev->mode_config.mutex);
drm_mode_create_tv_properties(dev, NUM_TV_MODES, tv_format_names);
drm_connector_attach_property(connector,
dev->mode_config.tv_mode_property,
@@ -1720,6 +1721,7 @@ intel_tv_init(struct drm_device *dev)
drm_connector_attach_property(connector,
dev->mode_config.tv_bottom_margin_property,
tv_priv->margin[TV_MARGIN_BOTTOM]);
+ mutex_unlock(&dev->mode_config.mutex);
out:
drm_sysfs_connector_add(connector);
}
--
1.5.6.5
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Non-mobile parts don't have integrated TV-out.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 14d82de..5824462 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1455,7 +1455,7 @@ static void intel_setup_outputs(struct drm_device *dev)
} else
intel_dvo_init(dev);
- if (IS_I9XX(dev) && !IS_I915G(dev))
+ if (IS_I9XX(dev) && IS_MOBILE(dev))
intel_tv_init(dev);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
--
1.5.6.5
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Add support for integrated HDMI on G4X hardware.
This is ported directly from the userland 2D driver code. The HDMI audio bits
aren't hooked up yet.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/i915_reg.h | 17 ++
drivers/gpu/drm/i915/intel_display.c | 11 +-
drivers/gpu/drm/i915/intel_drv.h |4 +-
drivers/gpu/drm/i915/intel_hdmi.c| 281 ++
drivers/gpu/drm/i915/intel_sdvo.c|8 +-
7 files changed, 317 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_hdmi.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index dd57a5b..793cba3 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -13,6 +13,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_crt.o \
intel_lvds.o \
intel_bios.o \
+ intel_hdmi.o \
intel_sdvo.o \
intel_modes.o \
intel_i2c.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4756e5c..563de18 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -664,6 +664,7 @@ extern void intel_modeset_cleanup(struct drm_device *dev);
writel(upper_32_bits(val), dev_priv->regs + \
(reg) + 4))
#endif
+#define POSTING_READ(reg) (void)I915_READ(reg)
#define I915_VERBOSE 0
@@ -760,6 +761,7 @@ extern int i915_wait_ring(struct drm_device * dev, int n,
const char *caller);
IS_I945GM(dev) || IS_I965GM(dev) || IS_GM45(dev))
#define I915_NEED_GFX_HWS(dev) (IS_G33(dev) || IS_GM45(dev) || IS_G4X(dev))
+#define SUPPORTS_INTEGRATED_HDMI(dev) (IS_G4X(dev))
#define PRIMARY_RINGBUFFER_SIZE (128*1024)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 47e6baf..1024315 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -549,6 +549,8 @@
/** GM965 GM45 render standby register */
#define MCHBAR_RENDER_STANDBY 0x111B8
+#define PEG_BAND_GAP_DATA 0x14d68
+
/*
* Overlay regs
*/
@@ -612,6 +614,9 @@
/* Hotplug control (945+ only) */
#define PORT_HOTPLUG_EN0x61110
+#define HDMIB_HOTPLUG_INT_EN (1 << 29)
+#define HDMIC_HOTPLUG_INT_EN (1 << 28)
+#define HDMID_HOTPLUG_INT_EN (1 << 27)
#define SDVOB_HOTPLUG_INT_EN (1 << 26)
#define SDVOC_HOTPLUG_INT_EN (1 << 25)
#define TV_HOTPLUG_INT_EN(1 << 18)
@@ -619,6 +624,9 @@
#define CRT_HOTPLUG_FORCE_DETECT (1 << 3)
#define PORT_HOTPLUG_STAT 0x61114
+#define HDMIB_HOTPLUG_INT_STATUS (1 << 29)
+#define HDMIC_HOTPLUG_INT_STATUS (1 << 28)
+#define HDMID_HOTPLUG_INT_STATUS (1 << 27)
#define CRT_HOTPLUG_INT_STATUS (1 << 11)
#define TV_HOTPLUG_INT_STATUS(1 << 10)
#define CRT_HOTPLUG_MONITOR_MASK (3 << 8)
@@ -648,7 +656,16 @@
#define SDVO_PHASE_SELECT_DEFAULT(6 << 19)
#define SDVO_CLOCK_OUTPUT_INVERT (1 << 18)
#define SDVOC_GANG_MODE (1 << 16)
+#define SDVO_ENCODING_SDVO (0x0 << 10)
+#define SDVO_ENCODING_HDMI (0x2 << 10)
+/** Requird for HDMI operation */
+#define SDVO_NULL_PACKETS_DURING_VSYNC (1 << 9)
#define SDVO_BORDER_ENABLE (1 << 7)
+#define SDVO_AUDIO_ENABLE(1 << 6)
+/** New with 965, default is to be set */
+#define SDVO_VSYNC_ACTIVE_HIGH (1 << 4)
+/** New with 965, default is to be set */
+#define SDVO_HSYNC_ACTIVE_HIGH (1 << 3)
#define SDVOB_PCIE_CONCURRENCY (1 << 3)
#define SDVO_DETECTED(1 << 2)
/* Bits to be preserved when writing */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1204d26..14d82de 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1443,8 +1443,15 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_lvds_init(dev);
if (IS_I9XX(dev)) {
- intel_sdvo_init(dev, SDVOB);
- intel_sdvo_init(dev, SDVOC);
+ int found;
+
+ found = intel_sdvo_init(dev, SDVOB);
+ if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
+ intel_hdmi_init(dev, SDVOB);
+
+ found = intel_sdvo_init(dev, SDVOC);
+ if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
+ intel_hdmi_init(dev, SDVOC);
} else
intel_dvo_init(dev);
di
Re: [PATCH] drm/i915: Don't oops when root asks to unpin an already unpinned buffer.
On Tue, 2009-01-06 at 14:22 +, Renato Caldas wrote:
> Hello,
>
> On Tue, Jan 6, 2009 at 12:34 AM, Eric Anholt wrote:
> > Signed-off-by: Eric Anholt
> > ---
> > drivers/gpu/drm/i915/i915_gem.c |7 +++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 14afc23..e87db6f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2761,6 +2761,13 @@ i915_gem_unpin_ioctl(struct drm_device *dev, void
> > *data,
> >mutex_unlock(&dev->struct_mutex);
> >return -EBADF;
> >}
> > + obj_priv = obj->driver_private;
> > +
> > + if (obj_priv->pin_count == 0) {
> > + drm_gem_object_unreference(obj);
> > + mutex_unlock(&dev->struct_mutex);
> > + return -EINVAL;
> > + }
> >
> >obj_priv = obj->driver_private;
>
> Is it necessary to do this again?
No, it's just rebasing leftovers. Thanks!
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: KMS with Xorg on G45 failing
On Tue, 2009-01-06 at 22:35 +, Mike Lothian wrote: > Hi there > > Thought I'd send in some info about Xorg with a KMS kernel, libdrm and > xf86-video-intel > > I've attached my dmesg and Xorg.0.log > > The only outputs are LVDS 15" screen an a disconnected VGA out and > HDMI connectors > > I'll quite happily submit a bug but thought the code was a little too > new to harp on about especially if this is a known issue The segfault should be fixed as of: commit 342120be0956bfc12822d1ffbfbd8aaabf3e922f Author: Eric Anholt Date: Mon Jan 5 23:21:07 2009 -0800 Fix pin leakage with EXA GTT-mapping shortcut, and crash with UXA on KMS. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] add timeout to drmWaitVBlank to avoid hangs
On Wed, 2009-01-07 at 11:11 -0800, Jesse Barnes wrote: > On Wednesday, January 7, 2009 10:54 am Keith Packard wrote: > > On Wed, 2009-01-07 at 10:15 -0800, Jesse Barnes wrote: > > > Ok; I messed with drmIoctl because I thought I remembered you saying we > > > shouldn't put the retry code there but rather in the individual ioctls > > > that needed it. We should probably do that separately anyway though if > > > we ever decide to. > > > > That wasn't me; I'm all for additional levels of bullet-proofing when it > > comes to EINTR as it's hard to test all of the code paths. > > > > > +libdrm_la_LIBADD = -lrt > > > > I fear you'll need autoconf-fu for this? > > > > Otherwise, it looks like a reasonable plan. > > I'm but an autoconf grasshopper. If there's a better way of doing this I'm > open to suggestions. Paraphrased slightly from server configure.ac: AC_CHECK_FUNCS([clock_gettime], [CLOCK_LIB=], [AC_CHECK_LIB([rt], [clock_gettime], [CLOCK_LIB=-lrt], [AC_MSG_ERROR([Couldn't find clock_gettime])])]) AC_SUBST([CLOCK_LIB]) -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] create IDR mutex for mode_config identifier allocation
On Wed, 2009-01-14 at 10:48 -0800, Jesse Barnes wrote:
> >From fc3b2a31f1d2274bcf98929d5f3a5aeaee1baf4d Mon Sep 17 00:00:00 2001
> From: Jesse Barnes
> Date: Wed, 14 Jan 2009 10:38:13 -0800
> Subject: [PATCH] drm: create mode_config idr lock
>
> Create a separate mode_config IDR lock for simplicity. The core DRM
> config structures (connector, mode, etc. lists) are still protected by
> the mode_config mutex, but the CRTC IDR (used for the various identifier
> IDs) is now protected by the mode_config idr_mutex. Simplifies the
> locking a bit and removes a warning.
So, I don't see any refcounting on these objects. What's keeping them
alive over the time that the consumer of these APIs uses an object
returned by drm_mode_object_find()?
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/drm_crtc.c | 15 ++-
> include/drm/drm_crtc.h |3 ++-
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 53c8725..6c9ead8 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -194,7 +194,6 @@ char *drm_get_connector_status_name(enum
> drm_connector_status status)
> * @type: object type
> *
> * LOCKING:
> - * Caller must hold DRM mode_config lock.
> *
> * Create a unique identifier based on @ptr in @dev's identifier space. Used
> * for tracking modes, CRTCs and connectors.
> @@ -209,15 +209,15 @@ static int drm_mode_object_get(struct drm_device *dev,
> int new_id = 0;
> int ret;
>
> - WARN(!mutex_is_locked(&dev->mode_config.mutex),
> - "%s called w/o mode_config lock\n", __FUNCTION__);
> again:
> if (idr_pre_get(&dev->mode_config.crtc_idr, GFP_KERNEL) == 0) {
> DRM_ERROR("Ran out memory getting a mode number\n");
> return -EINVAL;
> }
>
> + mutex_lock(&dev->mode_config.idr_mutex);
> ret = idr_get_new_above(&dev->mode_config.crtc_idr, obj, 1, &new_id);
> + mutex_unlock(&dev->mode_config.idr_mutex);
> if (ret == -EAGAIN)
> goto again;
>
> @@ -239,16 +239,20 @@ again:
> static void drm_mode_object_put(struct drm_device *dev,
> struct drm_mode_object *object)
> {
> + mutex_lock(&dev->mode_config.idr_mutex);
> idr_remove(&dev->mode_config.crtc_idr, object->id);
> + mutex_unlock(&dev->mode_config.idr_mutex);
> }
Fix the doc on this function
> void *drm_mode_object_find(struct drm_device *dev, uint32_t id, uint32_t
> type)
> {
> - struct drm_mode_object *obj;
> + struct drm_mode_object *obj = NULL;
>
> + mutex_lock(&dev->mode_config.idr_mutex);
> obj = idr_find(&dev->mode_config.crtc_idr, id);
> if (!obj || (obj->type != type) || (obj->id != id))
> - return NULL;
> + obj = NULL;
> + mutex_unlock(&dev->mode_config.idr_mutex);
>
> return obj;
> }
> @@ -786,6 +790,7 @@ EXPORT_SYMBOL(drm_mode_create_dithering_property);
> void drm_mode_config_init(struct drm_device *dev)
> {
> mutex_init(&dev->mode_config.mutex);
> + mutex_init(&dev->mode_config.idr_mutex);
> INIT_LIST_HEAD(&dev->mode_config.fb_list);
> INIT_LIST_HEAD(&dev->mode_config.fb_kernel_list);
> INIT_LIST_HEAD(&dev->mode_config.crtc_list);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 0acb07f..ad113c7 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -528,7 +528,8 @@ struct drm_mode_group {
> *
> */
> struct drm_mode_config {
> - struct mutex mutex; /* protects configuration and IDR */
> + struct mutex mutex; /* protects configuration (mode lists etc.) */
> + struct mutex idr_mutex; /* for IDR management */
> struct idr crtc_idr; /* use this idr for all IDs, fb, crtc, connector,
> modes - just makes life easier */
> /* this is limited to one for now */
> int num_fb;
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] add debugfs init hooks
On Sun, 2008-12-21 at 15:21 -0500, Ben Gamari wrote:
> ---
> drivers/gpu/drm/drm_stub.c | 12
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 5697764..23f1bca 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -50,6 +50,7 @@ struct idr drm_minors_idr;
>
> struct class *drm_class;
> struct proc_dir_entry *drm_proc_root;
> +struct dentry *drm_debugfs_root;
>
> static int drm_minor_get_id(struct drm_device *dev, int type)
> {
> @@ -314,6 +315,14 @@ static int drm_get_minor(struct drm_device *dev, struct
> drm_minor **minor, int t
> } else
> new_minor->proc_root = NULL;
>
> +#if defined(CONFIG_DRM_DEBUGFS)
> +ret = drm_debugfs_init(new_minor, minor_id, drm_debugfs_root);
> +if (ret) {
> +DRM_ERROR("DRM: Failed to initialize /debugfs/dri.\n");
> +goto err_g2;
> +}
> +#endif
> +
> ret = drm_sysfs_device_add(new_minor);
> if (ret) {
> printk(KERN_ERR
> @@ -449,6 +458,9 @@ int drm_put_minor(struct drm_minor **minor_p)
>
> if (minor->type == DRM_MINOR_LEGACY)
> drm_proc_cleanup(minor, drm_proc_root);
> +#if defined(CONFIG_DRM_DEBUGFS)
> +drm_debugfs_cleanup(minor);
> +#endif
> drm_sysfs_device_remove(minor);
>
> idr_remove(&drm_minors_idr, minor->index);
This appears to depend on a later patch, and should be merged in with
that one. Also, watch the whitespace -- the kernel uses 8-space tabs,
not 8 spaces.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] add DRM_DEBUGFS config option to Kconfig
On Sun, 2008-12-21 at 15:21 -0500, Ben Gamari wrote: > --- > drivers/gpu/drm/Kconfig |7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 6903e54..fd7418a 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -16,6 +16,13 @@ menuconfig DRM > details. You should also select and configure AGP > (/dev/agpgart) support. > > +config DRM_DEBUGFS > +bool "DRM debugfs file system" > +depends on DEBUG_FS > +help > + Choose this option is you wish to enable the debugfs filesystem > + for the DRM and drivers. > + > config DRM_TDFX > tristate "3dfx Banshee/Voodoo3+" > depends on DRM && PCI I'd rather see this not be an option -- if you've got both debugfs and drm in your kernel, you get the drm debugfs bits. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Add GEM to i915 broke compilation on MIPS
On Sat, 2009-01-10 at 19:16 +0100, Martin Michlmayr wrote:
> Eric,
>
> Your patch "drm: Add GEM ("graphics execution manager") to i915
> driver" [1] broke compilation on MIPS because agp.h doesn't exist.
>
> CALLscripts/checksyscalls.sh
> CC [M] drivers/gpu/drm/drm_agpsupport.o
> drivers/gpu/drm/drm_agpsupport.c:36:21: error: asm/agp.h: No such file or
> directory
> make[3]: *** [drivers/gpu/drm/drm_agpsupport.o] Error 1
>
> [1]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=673a394b1e3b69be886ff24abfd6df97c52e8d08
Is this enough to fix it?
From 8a8d7ba9cac5f569c9b0426e583203bab1feeb73 Mon Sep 17 00:00:00 2001
From: Eric Anholt
Date: Wed, 14 Jan 2009 17:16:25 -0800
Subject: [PATCH] drm: stash AGP include under the do-we-have-AGP ifdef
This should fix the MIPS with DRM build.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_agpsupport.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 3d33b82..1479659 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -33,10 +33,11 @@
#include "drmP.h"
#include
-#include
#if __OS_HAS_AGP
+#include
+
/**
* Get AGP information.
*
--
1.5.6.5
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] VGA hotplug support for i915 kms
On Fri, 2009-01-16 at 14:42 +0100, Jakob Bornecrantz wrote: > Jesse Barnes wrote: > > On Wednesday, January 14, 2009 2:14 pm Jesse Barnes wrote: > >> Here's a work in progress VGA hotplug patch that I've been testing on my > >> GM45. I've only tested VGA interrupts so far, but other ports may work or > >> should be easy to enable. When a hotplug interrupt is received, the i915 > >> interrupt handler kicks off a work queue which ends up sending a uevent. > >> I've deliberately done nothing else; I figure userspace should decide what > >> to do with the event (ignore it, probe outputs, set up a cloned or extended > >> configuration, etc.). > >> > >> Thoughts or comments? The passing of the DRM device struct to the work > >> function is pretty ugly at this point, and could be improved, and whether > >> hotplug detection is enabled should probably be configurable since it > >> depends on the outputs being powered enough to detect events. > > > > Here's a slightly less revolting version. I removed all the global > > variables, > > and moved to using the system wide work queue rather than an i915 specific > > one, > > so things are much cleaner & clearer. > > > > Comments? Userspace will still need to call getresources after receiving a > > hotplug event, but I think that's better than trying to do something by > > default > > in the kernel. > > When we only run fbcon we might not be blessed with a clever userspace > that can add a new monitor to the fb config. Maybe we should run some > sort of detection code in the intel fb code. Our experience with trying to "do something sensible when we notice new things plugged in" in the early randr 1.2 days was that it was a terrible idea that made users hate us. I suspect it would be even worse if we tried it in the kernel. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Skip SDVO/HDMI init when the chipset tells us it's not present.
This saves startup time from probing SDVO, and saves setting up HDMI outputs
on G4X devices that don't have them.
---
drivers/gpu/drm/i915/intel_display.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 31c3732..dce1abf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1452,6 +1452,7 @@ static int intel_connector_clones(struct drm_device *dev,
int type_mask)
static void intel_setup_outputs(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_connector *connector;
intel_crt_init(dev);
@@ -1463,13 +1464,16 @@ static void intel_setup_outputs(struct drm_device *dev)
if (IS_I9XX(dev)) {
int found;
- found = intel_sdvo_init(dev, SDVOB);
- if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
- intel_hdmi_init(dev, SDVOB);
-
- found = intel_sdvo_init(dev, SDVOC);
- if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
- intel_hdmi_init(dev, SDVOC);
+ if (I915_READ(SDVOB) & SDVO_DETECTED) {
+ found = intel_sdvo_init(dev, SDVOB);
+ if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
+ intel_hdmi_init(dev, SDVOB);
+ }
+ if (!IS_G4X(dev) || (I915_READ(SDVOB) & SDVO_DETECTED)) {
+ found = intel_sdvo_init(dev, SDVOC);
+ if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
+ intel_hdmi_init(dev, SDVOC);
+ }
} else
intel_dvo_init(dev);
--
1.5.6.5
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Suppress GEM teardown on X Server exit in KMS mode.
Fixes hangs when starting X for the second time.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/i915/i915_gem.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 96316fd..3741101 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3273,6 +3273,9 @@ i915_gem_lastclose(struct drm_device *dev)
{
int ret;
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
ret = i915_gem_idle(dev);
if (ret)
DRM_ERROR("failed to idle hardware: %d\n", ret);
--
1.5.6.5
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] support tiled rendering in 2D driver
32767 || h > 32767)
> @@ -884,9 +884,12 @@ i830_uxa_create_pixmap (ScreenPtr screen, int w, int h,
> int depth, unsigned usag
> {
> stride = ROUND_TO((w * pixmap->drawable.bitsPerPixel + 7) / 8,
> i830->accel_pixmap_pitch_alignment);
> +
> + stride = I830GetFencePitch(i830, stride, I915_TILING_X);
> +
> + align = stride * h > 1024*1024 ? stride * h : 1024*1024;
If we're going to have to calculate alignment in userland for the
purpose of tiling, it should be a separate function like it is in the
kernel, and match its behavior (I still think the kernel should just do
it for us).
> - bo = dri_bo_alloc (i830->bufmgr, "pixmap", stride * h,
> -i830->accel_pixmap_offset_alignment);
> + bo = dri_bo_alloc (i830->bufmgr, "pixmap", stride * h, align);
> if (!bo) {
> fbDestroyPixmap (pixmap);
> return NullPixmap;
> diff --git a/src/i830_memory.c b/src/i830_memory.c
> index 9bfee81..7d55910 100644
> --- a/src/i830_memory.c
> +++ b/src/i830_memory.c
> @@ -388,6 +388,7 @@ i830_allocator_init(ScrnInfoPtr pScrn, unsigned long
> offset, unsigned long size)
> #ifdef XF86DRI
> int dri_major, dri_minor, dri_patch;
> struct drm_i915_getparam gp;
> +struct drm_i915_setparam sp;
> int has_gem;
> int has_dri;
> #endif
> @@ -495,6 +496,17 @@ i830_allocator_init(ScrnInfoPtr pScrn, unsigned long
> offset, unsigned long size)
> TILE_NONE);
>
> if (pI830->memory_manager != NULL) {
> + sp.param = I915_SETPARAM_NUM_USED_FENCES;
> + if (pI830->use_drm_mode)
> + sp.value = 0; /* kernel gets them all */
> + else if (pI830->directRenderingType == DRI_XF86DRI)
> + sp.value = 3; /* front/back/depth */
> + else
> + sp.value = 2; /* just front for DRI2 (both old & new though) */
> + /* Don't care about failure, we'll just get slow rendering */
> + drmCommandWrite(pI830->drmSubFD, DRM_I915_SETPARAM, &sp,
> + sizeof(sp));
> +
Well, we'll get wrong rendering as well if we enable tiling despite not
having a new enough kernel. Any SW fallbacks will use the tiling state
rather than the unset fence registers, and you'll get swizzled.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] add fence register management to execbuf
On Fri, 2009-01-23 at 14:12 -0800, Jesse Barnes wrote:
> Adds code to set up fence registers at execbuf time on pre-965 chips
> as
> necessary. Also fixes up a few bugs in the pre-965 tile register
> support
> (get_order != ffs). The number of fences available to the kernel
> defaults
> to the hw limit minus 3 (for legacy X front/back/depth), but a new
> parameter
> allows userspace to override that as needed.
>
> We should probably be smarter here, and make sure the all the buffers
> are
> covered by fences before hanging the chip, and there may be other
> steps
> required in the fence eviction code (iirc Eric mentioned that some
> additional
> flushing may be required).
Looks pretty good, and thanks for the flushing reminder. Basically we
need to flush the gpu write domain before waiting for rendering (or
we'll bug!), and we need to clear the read domain flags (or the next
person to come along after setting up their new fence register may get
stale speculated garbage from reads that occurred while the fence reg
wasn't in place).
> --
> Jesse Barnes, Intel Open Source Technology Center
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 96316fd..41749cd 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1445,21 +1445,27 @@ static void i915_write_fence_reg(struct
> drm_i915_fence_reg *reg)
> drm_i915_private_t *dev_priv = dev->dev_private;
> struct drm_i915_gem_object *obj_priv = obj->driver_private;
> int regnum = obj_priv->fence_reg;
> + int tile_width = 512;
> uint32_t val;
> uint32_t pitch_val;
>
> if ((obj_priv->gtt_offset & ~I915_FENCE_START_MASK) ||
> (obj_priv->gtt_offset & (obj->size - 1))) {
> - WARN(1, "%s: object not 1M or size aligned\n", __func__);
> + WARN(1, "%s: object 0x%08x not 1M or size (0x%x) aligned\n",
> + __func__, obj_priv->gtt_offset, obj->size);
> return;
> }
>
> if (obj_priv->tiling_mode == I915_TILING_Y && (IS_I945G(dev) ||
> IS_I945GM(dev) ||
> IS_G33(dev)))
> - pitch_val = (obj_priv->stride / 128) - 1;
> - else
> - pitch_val = (obj_priv->stride / 512) - 1;
> + tile_width = 128;
> +
> + pitch_val = obj_priv->stride / tile_width;
> + WARN(pitch_val & (pitch_val - 1),
> + "pitch value not a power of two tile widths\n");
SET_TILING ioctl should just reject the tiling request if a bad stride
or a bad tiling type for a given chipset was passed in, so we don't have
to validate and WARN here.
Hmm, actually all the fence management code probably ought to live in
i915_gem_tiling.c. Something for the next kernel, I guess.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] support tiled rendering in 2D driver
On Fri, 2009-01-23 at 16:24 -0800, Eric Anholt wrote:
> On Fri, 2009-01-23 at 14:15 -0800, Jesse Barnes wrote:
> > Set alignments, tile settings and flags correctly in the 2D driver to
> > support
> > tiled rendering. UXA's create pixmap function currently assumes the worst
> > about the alignment constraints; that should probably be fixed. Some of the
> > 1M alignment fixes could probably be done more cleanly as well.
Updated version incorporating my comments. Note the XXXs. With this
I've seen OA go from 5.5fps to 34.7fps on my eee 901, so I think we're
looking pretty good once we clean a few messes up. I had to disable
TILING_Y to get correct rendering with OA, which we should probably look
into.
From 1d9cda617f29badf50584bafa42ea597f1a5b27d Mon Sep 17 00:00:00 2001
From: Jesse Barnes
Date: Fri, 23 Jan 2009 14:15:26 -0800
Subject: [PATCH] Support tiled back/depth on 915-class hardware with DRI2.
Set alignments, tile settings and flags correctly in the 2D driver to support
tiled rendering. UXA's create pixmap function currently assumes the worst
about the alignment constraints; that should probably be fixed. Some of the
1M alignment fixes could probably be done more cleanly as well.
---
src/i830.h|4 +++
src/i830_dri.c| 14 ---
src/i830_driver.c |1 +
src/i830_exa.c| 23 ---
src/i830_memory.c | 61 +++-
5 files changed, 84 insertions(+), 19 deletions(-)
diff --git a/src/i830.h b/src/i830.h
index 4794169..d9adfbf 100644
--- a/src/i830.h
+++ b/src/i830.h
@@ -724,6 +724,7 @@ typedef struct _I830Rec {
enum last_3d *last_3d;
Bool use_drm_mode;
+ Bool kernel_exec_fencing;
#ifdef XF86DRM_MODE
drmmode_rec drmmode;
int drm_mm_init;
@@ -910,6 +911,9 @@ extern void i830WaitSync(ScrnInfoPtr pScrn);
/* i830_memory.c */
Bool i830_bind_all_memory(ScrnInfoPtr pScrn);
Bool i830_unbind_all_memory(ScrnInfoPtr pScrn);
+unsigned long i830_get_fence_size(I830Ptr pI830, unsigned long size);
+unsigned long i830_get_fence_pitch(I830Ptr pI830, unsigned long pitch, int
format);
+unsigned long i830_get_fence_alignment(I830Ptr pI830, unsigned long size);
Bool I830BindAGPMemory(ScrnInfoPtr pScrn);
Bool I830UnbindAGPMemory(ScrnInfoPtr pScrn);
diff --git a/src/i830_dri.c b/src/i830_dri.c
index d6698da..da5b7cd 100644
--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -1570,7 +1570,7 @@ I830DRI2CreateBuffers(DrawablePtr pDraw, unsigned int
*attachments, int count)
pDraw->depth, 0);
switch (attachments[i]) {
case DRI2BufferDepth:
- if (IS_I965G(pI830))
+ if (IS_I965G(pI830) /* || IS_I945GM(pI830) || IS_I945G(pI830)
*/)
tiling = I915_TILING_Y;
else
tiling = I915_TILING_X;
@@ -1583,19 +1583,15 @@ I830DRI2CreateBuffers(DrawablePtr pDraw, unsigned int
*attachments, int count)
break;
}
- /* Disable tiling on 915-class 3D for now. Because the 2D blitter
-* requires fence regs to operate, and they're not being managed
-* by the kernel yet, we don't want to expose tiled buffers to the
-* 3D client as it'll just render incorrectly if it pays attention
-* to our tiling bits at all.
-*/
- if (!IS_I965G(pI830))
+ if (!pI830->tiling ||
+ (!IS_I965G(pI830) && !pI830->kernel_exec_fencing))
tiling = I915_TILING_NONE;
+ ErrorF("tiling %d %d\n", attachments[i], tiling);
if (tiling != I915_TILING_NONE) {
bo = i830_get_pixmap_bo(pPixmap);
drm_intel_bo_set_tiling(bo, &tiling,
- pDraw->width * pDraw->bitsPerPixel / 8);
+ intel_get_pixmap_pitch(pPixmap));
}
}
diff --git a/src/i830_driver.c b/src/i830_driver.c
index bf5ecc4..2c4ea07 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -1822,6 +1822,7 @@ I830PreInit(ScrnInfoPtr pScrn, int flags)
pI830->SaveGeneration = -1;
pI830->pEnt = pEnt;
pI830->use_drm_mode = drm_mode_setting;
+ pI830->kernel_exec_fencing = pI830->use_drm_mode;
if (!I830LoadSyms(pScrn))
return FALSE;
diff --git a/src/i830_exa.c b/src/i830_exa.c
index 9249074..f293d19 100644
--- a/src/i830_exa.c
+++ b/src/i830_exa.c
@@ -872,7 +872,7 @@ i830_uxa_create_pixmap (ScreenPtr screen, int w, int h, int
depth, unsigned usag
ScrnInfoPtr scrn = xf86Screens[screen->myNum];
I830Ptr i830 = I830PTR(scrn);
dri_bo *bo;
-int stride;
+int stride, align;
PixmapPtr pixmap;
if (w > 32767 || h > 32767)
@@ -882,11 +882,26 @@ i830_uxa_create_pixmap (ScreenPtr screen, int w,
Re: [Intel-gfx] [PATCH] support tiled rendering in 2D driver
On Sat, 2009-01-24 at 11:01 -0800, Jesse Barnes wrote: > On Friday, January 23, 2009 4:24 pm Eric Anholt wrote: > > > +/** > > > + * On some chips, pitch width has to be a power of two tile width, so > > > + * calculate that here. > > > + */ > > > +unsigned long > > > +I830GetFencePitch(I830Ptr pI830, unsigned long pitch, int format) > > > > DeathToStudlyCaps() > > Yeah sorry, was just trying to blend in. We should just have a flag day on > the driver and change all the formatting. I've got an intel-cleanup branch in my 2d driver tree I'm working on for the nuking of bad old code we don't want to support (10% reduction in LOC so far, and just getting started) post-KMS. I'm thinking that whenever we do that would be a good time to fix style. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Rip out the racy, unused vblank signal code.
Schedule a vblank signal, kill the process, and we'll go walking over freed
memory. Given that no open-source userland exists using this, nor have I
ever heard of a consumer, just let this code die.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_irq.c | 161 +++--
include/drm/drm.h |2 +-
include/drm/drmP.h|9 ---
3 files changed, 24 insertions(+), 148 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 477caa1..69aa0ab 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -106,8 +106,6 @@ void drm_vblank_cleanup(struct drm_device *dev)
drm_free(dev->vbl_queue, sizeof(*dev->vbl_queue) * dev->num_crtcs,
DRM_MEM_DRIVER);
- drm_free(dev->vbl_sigs, sizeof(*dev->vbl_sigs) * dev->num_crtcs,
-DRM_MEM_DRIVER);
drm_free(dev->_vblank_count, sizeof(*dev->_vblank_count) *
dev->num_crtcs, DRM_MEM_DRIVER);
drm_free(dev->vblank_refcount, sizeof(*dev->vblank_refcount) *
@@ -132,7 +130,6 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
setup_timer(&dev->vblank_disable_timer, vblank_disable_fn,
(unsigned long)dev);
spin_lock_init(&dev->vbl_lock);
- atomic_set(&dev->vbl_signal_pending, 0);
dev->num_crtcs = num_crtcs;
dev->vbl_queue = drm_alloc(sizeof(wait_queue_head_t) * num_crtcs,
@@ -140,11 +137,6 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
if (!dev->vbl_queue)
goto err;
- dev->vbl_sigs = drm_alloc(sizeof(struct list_head) * num_crtcs,
- DRM_MEM_DRIVER);
- if (!dev->vbl_sigs)
- goto err;
-
dev->_vblank_count = drm_alloc(sizeof(atomic_t) * num_crtcs,
DRM_MEM_DRIVER);
if (!dev->_vblank_count)
@@ -177,7 +169,6 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
/* Zero per-crtc vblank stuff */
for (i = 0; i < num_crtcs; i++) {
init_waitqueue_head(&dev->vbl_queue[i]);
- INIT_LIST_HEAD(&dev->vbl_sigs[i]);
atomic_set(&dev->_vblank_count[i], 0);
atomic_set(&dev->vblank_refcount[i], 0);
}
@@ -540,15 +531,10 @@ out:
* \param data user argument, pointing to a drm_wait_vblank structure.
* \return zero on success or a negative number on failure.
*
- * Verifies the IRQ is installed.
- *
- * If a signal is requested checks if this task has already scheduled the same
signal
- * for the same vblank sequence number - nothing to be done in
- * that case. If the number of tasks waiting for the interrupt exceeds 100 the
- * function fails. Otherwise adds a new entry to drm_device::vbl_sigs for this
- * task.
- *
- * If a signal is not requested, then calls vblank_wait().
+ * This function enables the vblank interrupt on the pipe requested, then
+ * sleeps waiting for the requested sequence number to occur, and drops
+ * the vblank interrupt refcount afterwards. (vblank irq disable follows that
+ * after a timeout with no further vblank waits scheduled).
*/
int drm_wait_vblank(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -560,6 +546,9 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
if ((!dev->pdev->irq) || (!dev->irq_enabled))
return -EINVAL;
+ if (vblwait->request.type & _DRM_VBLANK_SIGNAL)
+ return -EINVAL;
+
if (vblwait->request.type &
~(_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK)) {
DRM_ERROR("Unsupported type value 0x%x, supported mask 0x%x\n",
@@ -597,89 +586,26 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
vblwait->request.sequence = seq + 1;
}
- if (flags & _DRM_VBLANK_SIGNAL) {
- unsigned long irqflags;
- struct list_head *vbl_sigs = &dev->vbl_sigs[crtc];
- struct drm_vbl_sig *vbl_sig;
-
- spin_lock_irqsave(&dev->vbl_lock, irqflags);
-
- /* Check if this task has already scheduled the same signal
-* for the same vblank sequence number; nothing to be done in
-* that case
-*/
- list_for_each_entry(vbl_sig, vbl_sigs, head) {
- if (vbl_sig->sequence == vblwait->request.sequence
- && vbl_sig->info.si_signo ==
- vblwait->request.signal
- && vbl_sig->task == current) {
- spin_unlock_irqrestore(&dev->vbl_lock,
-
Re: [PATCH] drm: Drop unused and broken dri_library_name sysfs attribute.
On Mon, 2009-01-05 at 16:10 -0500, Kristian Høgsberg wrote: > The kernel shouldn't be in the business of telling user space which > driver to load. The kernel defers mapping PCI IDs to module names > to user space and we should do the same for DRI drivers. > > And in fact, that's how it does work today. Nothing uses the > dri_library_name attribute, and the attribute is in fact broken. > For intel devices, it falls back to the default behaviour of returning > the kernel module name as the DRI driver name, which doesn't work for > i965 devices. Nobody has ever hit this problem or filed a bug about this. Acked-by: Eric Anholt -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] drm: Split drm_map and drm_local_map
On Mon, 2009-02-02 at 16:55 +1100, Benjamin Herrenschmidt wrote: > Once upon a time, the DRM made the distinction between the drm_map > data structure exchanged with user space and the drm_local_map used > in the kernel. > > For some reasons, while the BSD port still has that "feature", the > linux part abused drm_map for kernel internal usage as the local > map only existed as a typedef of the struct drm_map. > > This patch fixes it by declaring struct drm_local_map separately > (though its content is currently identical to the userspace variant), > and changing the kernel code to only use that, except when it's a > user<->kernel interface (ie. ioctl). > > This allows subsequent changes to the in-kernel format > > I've also replaced the use of drm_local_map_t with struct drm_local_map > in a couple of places. Mostly by accident but they are the same (the > former is a typedef of the later) and I have some remote plans and > half finished patch to completely kill the drm_local_map_t typedef > so I left those bits in. > > Signed-off-by: Benjamin Herrenschmidt Thanks for taking on this mess! Acked-by: Eric Anholt -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/3] drm: Make drm_local_map use a resource_size_t offset
On Mon, 2009-02-02 at 16:55 +1100, Benjamin Herrenschmidt wrote:
> This changes drm_local_map to use a resource_size for its "offset"
> member instead of an unsigned long, thus allowing 32-bit machines
> with a >32-bit physical address space to be able to store there
> their register or framebuffer addresses when those are above 4G,
> such as when using a PCI video card on a recent AMCC 440 SoC.
>
> This patch isn't as "trivial" as it sounds: A few functions needed
> to have some unsigned long/int changed to resource_size_t and a few
> printk's had to be adjusted.
>
> But also, because userspace isn't capable of passing such offsets,
> I had to modify drm_find_matching_map() to ignore the offset passed
> in for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.
>
> If we ever support multiple _DRM_FRAMEBUFFER or _DRM_REGISTERS maps
> for a given device, we might have to change that trick, but I don't
> think that happens on any current driver.
>
> Signed-off-by: Benjamin Herrenschmidt
Just one little comment I think then I'd be happy:
> ---
>
> drivers/gpu/drm/drm_bufs.c | 33 -
> drivers/gpu/drm/drm_proc.c |4 ++--
> drivers/gpu/drm/drm_vm.c | 22 --
> drivers/gpu/drm/mga/mga_dma.c | 17 +
> drivers/gpu/drm/mga/mga_drv.h |4 ++--
> drivers/gpu/drm/r128/r128_cce.c|7 ---
> drivers/gpu/drm/radeon/radeon_cp.c |9 +
> include/drm/drmP.h | 12 ++--
> 8 files changed, 64 insertions(+), 44 deletions(-)
>
> --- linux-work.orig/drivers/gpu/drm/drm_bufs.c2009-02-02
> 16:29:54.0 +1100
> +++ linux-work/drivers/gpu/drm/drm_bufs.c 2009-02-02 16:29:54.0
> +1100
> @@ -54,11 +54,25 @@ static struct drm_map_list *drm_find_mat
> {
> struct drm_map_list *entry;
> list_for_each_entry(entry, &dev->maplist, head) {
> - if (entry->map && (entry->master == dev->primary->master) &&
> (map->type == entry->map->type) &&
> - ((entry->map->offset == map->offset) ||
> - ((map->type == _DRM_SHM) &&
> (map->flags&_DRM_CONTAINS_LOCK {
> + /* Due to userspace API breakage, we ignore the map offset
> + * for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS
> + */
Could this comment instead be maybe:
Because the kernel-userspace ABI is fixed at a 32-bit offset, while PCI
resources may live above that, we ignore the map offset for maps of type
_DRM_FRAMEBUFFER or _DRM_REGISTERS. It is assumed that each driver will
have only one resource of each type.
(I want to remember later what exact ABI problem was in question)
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] drm: Use resource_size_t for drm_get_resource_{start, len}
dev,
> 0));
> }
> } else if (dev_priv->chipset != S3_SUPERSAVAGE &&
> dev_priv->chipset != S3_SAVAGE2000) {
> @@ -620,8 +620,8 @@ int savage_driver_firstopen(struct drm_d
> drm_mtrr_add(dev_priv->mtrr[0].base,
>dev_priv->mtrr[0].size, DRM_MTRR_WC);
> } else {
> - DRM_ERROR("strange pci_resource_len %08lx\n",
> - drm_get_resource_len(dev, 1));
> + DRM_ERROR("strange pci_resource_len %08llx\n",
> + (unsigned long long)drm_get_resource_len(dev,
> 1));
> }
> } else {
> mmio_base = drm_get_resource_start(dev, 0);
> Index: linux-work/include/drm/drmP.h
> ===
> --- linux-work.orig/include/drm/drmP.h2009-02-02 14:16:43.0
> +1100
> +++ linux-work/include/drm/drmP.h 2009-02-02 14:16:57.0 +1100
> @@ -1173,10 +1173,10 @@ extern int drm_freebufs(struct drm_devic
> extern int drm_mapbufs(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> extern int drm_order(unsigned long size);
> -extern unsigned long drm_get_resource_start(struct drm_device *dev,
> +extern resource_size_t drm_get_resource_start(struct drm_device *dev,
> + unsigned int resource);
> +extern resource_size_t drm_get_resource_len(struct drm_device *dev,
> unsigned int resource);
> -extern unsigned long drm_get_resource_len(struct drm_device *dev,
> - unsigned int resource);
>
> /* DMA support (drm_dma.h) */
> extern int drm_dma_setup(struct drm_device *dev);
> Index: linux-work/include/drm/drm_crtc.h
> ===
> --- linux-work.orig/include/drm/drm_crtc.h2009-02-02 14:24:56.0
> +1100
> +++ linux-work/include/drm/drm_crtc.h 2009-02-02 14:25:03.0 +1100
> @@ -550,7 +550,7 @@ struct drm_mode_config {
> int min_width, min_height;
> int max_width, max_height;
> struct drm_mode_config_funcs *funcs;
> - unsigned long fb_base;
> + resource_size_t fb_base;
>
> /* pointers to standard properties */
> struct list_head property_blob_list;
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Fix lock order reversal between mmap_sem and struct_mutex.
The basic problem was
mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap())
struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
We have plenty of places where we want to hold device state the same
(struct_mutex) while we move a non-trivial amount of data
(copy_from/to_user()), such as i915_gem_pwrite(). Solve this by moving the
one thing that needed struct_mutex with mmap_sem held to using a lock to cover
just those data structures (offset hash and offset manager).
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_gem.c |8
drivers/gpu/drm/i915/i915_gem.c |5 +
include/drm/drmP.h |1 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6915fb8..7fe91b6 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -97,6 +97,7 @@ drm_gem_init(struct drm_device *dev)
dev->mm_private = mm;
+ mutex_init(&mm->offset_mutex);
if (drm_ht_create(&mm->offset_hash, 19)) {
drm_free(mm, sizeof(struct drm_gem_mm), DRM_MEM_MM);
return -ENOMEM;
@@ -485,10 +486,9 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
unsigned long prot;
int ret = 0;
- mutex_lock(&dev->struct_mutex);
-
+ mutex_lock(&mm->offset_mutex);
if (drm_ht_find_item(&mm->offset_hash, vma->vm_pgoff, &hash)) {
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&mm->offset_mutex);
return drm_mmap(filp, vma);
}
@@ -525,7 +525,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
drm_vm_open_locked(vma);
out_unlock:
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&mm->offset_mutex);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6a9e3a8..8754054 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -646,6 +646,7 @@ i915_gem_create_mmap_offset(struct drm_gem_object *obj)
map->size = obj->size;
map->handle = obj;
+ mutex_lock(&mm->offset_mutex);
/* Get a DRM GEM mmap offset allocated... */
list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
obj->size / PAGE_SIZE, 0,
0);
@@ -671,12 +672,14 @@ i915_gem_create_mmap_offset(struct drm_gem_object *obj)
/* By now we should be all set, any drm_mmap request on the offset
* below will get to our mmap & fault handler */
obj_priv->mmap_offset = ((uint64_t) list->hash.key) << PAGE_SHIFT;
+ mutex_unlock(&mm->offset_mutex);
return 0;
out_free_mm:
drm_mm_put_block(list->file_offset_node);
out_free_list:
+ mutex_unlock(&mm->offset_mutex);
drm_free(list->map, sizeof(struct drm_map_list), DRM_MEM_DRIVER);
return ret;
@@ -2896,6 +2899,7 @@ void i915_gem_free_object(struct drm_gem_object *obj)
i915_gem_object_unbind(obj);
+ mutex_lock(&mm->offset_mutex);
list = &obj->map_list;
drm_ht_remove_item(&mm->offset_hash, &list->hash);
@@ -2903,6 +2907,7 @@ void i915_gem_free_object(struct drm_gem_object *obj)
drm_mm_put_block(list->file_offset_node);
list->file_offset_node = NULL;
}
+ mutex_unlock(&mm->offset_mutex);
map = list->map;
if (map) {
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 8190b9b..daadf06 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -570,6 +570,7 @@ struct drm_ati_pcigart_info {
struct drm_gem_mm {
struct drm_mm offset_manager; /**< Offset mgmt for buffer objects */
struct drm_open_hash offset_hash; /**< User token hash table for maps */
+ struct mutex offset_mutex; /**< covers offset_manager and offset_hash */
};
/**
--
1.5.6.5
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel bufmgr concerns?
On Wed, 2009-02-04 at 23:48 +0100, Thomas Hellström wrote: > Eric, > > Looking at the intel_bufmgr_gem implementation there seems to be a > number of members on a > "struct drm_intel_bo_gem" that really should be per context, like > validate_index, *reloc_* members, included_in_check_aperture etc. > > What happens if a shared texture, for example, is used by multiple > contexts from multiple threads simultaneously? Shared textures and renderbuffers don't have relocations. validate_index is protected by the lock held across bo_exec. check_aperture needs the same locking treatment. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gem GTT mmaps..
On Wed, 2009-02-04 at 15:02 -0800, Jesse Barnes wrote: > On Wednesday, February 4, 2009 2:32 pm Thomas Hellström wrote: > > Jesse, > > > > I have some concerns about the GEM GTT mmap functionality. > > Thanks for looking it over again; you would know since some of this code came > from you in the first place. :) > > > First, a gem object pointer is copied to map->offset and then to the > > vma->vm_private_data without proper reference counting. This pointer is > > used in i915_gem_fault() to access the gem object. However if the gem > > object is destroyed and a process then tries to access data in a vma > > mapping the (now destroyed) object, it would dereference a stale pointer > > into kernel space? Shouldn't those pointers be reference counted, and to > > account for fork(), a vm open and close would be needed to reference > > count corresponding pointers of newly created and destroyed vmas? > > Yeah looks like we don't protect against vm_private_data pointing at a freed > or other object. But rather than refcounting the pointers I wonder if we > could make the private data use the GEM object name instead, then do the > lookup in the fault handler? The object doesn't necessarily have a public name. You do need to refcount the objects. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #12574] possible circular locking dependency detected
On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote: > Dave, dri guys, > Could you take a look at this circular dependency please (below)? I > observe it when suspending laptop with radeon drm loaded and with > lockdep enabled. It seems that the root of the problem is that > various vm ops such as drm_vm_open, drm_mmap) are called with mm > semaphore taken, and take dev->struct_mutex. On the other hand, > drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del > which depends on mm semaphore indirectly. > > What do you think? Yes, there are real lock inversions now due to the GTT mmap code. It's going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex path to go away, but the fact that mmap_sem is held over the fault handler pretty much kills that). It's high on the list, though. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gem GTT mmaps..
On Fri, 2009-02-06 at 14:24 -0800, Jesse Barnes wrote: > On Friday, February 6, 2009 1:35 pm Thomas Hellström wrote: > > Jesse Barnes wrote: > > > On Thursday, February 5, 2009 10:37 am Jesse Barnes wrote: > > >> So if we leave the lookup reference around from the GTT mapping ioctl, > > >> that would take care of new mappings. And if we added/removed > > >> references at VM open/close time, we should be covered for fork. But is > > >> it ok to add a new unref in the finish ioctl for GTT mapped objects? I > > >> don't think so, because we don't know for sure if the caller was the one > > >> that created the new fake offset (which would be one way of detecting > > >> whether it was GTT mapped). Seems like we need a new unmap ioctl? Or we > > >> could put the mapping ref/unref in libdrm, where it would be tracked on > > >> a per-process basis... > > > > > > Ah but maybe we should just tear down the fake offset at unmap time; then > > > we'd be able to use it as an existence test for the mapping and get the > > > refcounting right. The last thing I thought of was whether we'd be ok in > > > a map_gtt -> crash case. I *think* the vm_close code will deal with > > > that, if we do a deref there? > > > > Yes, an mmap() is always paired with a vm_close(), and the vm_close() > > also happens in a crash situation. > > This one should cover the cases you found. > - ref at map time will keep the object around so fault shouldn't fail > - additional threads will take their refs in vm_open/close > - unmap will unref and remove mmap_offset allowing object to be freed sw_finish doesn't mean unmap (note that it doesn't actually unmap). If you want to actually unmap, that should be done with munmap. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] radeon-rewrite branch merging.
On Thu, 2009-02-12 at 05:29 +, Dave Airlie wrote: > Hi, > > So I have a goal to get a radeon driver that works on a bufmgr and that > then can be used on non-mm/mm, and also where I can make DRI2 and FBOs > work. > > So with that in mind and not wanting to write this 3 times, I've done a > major refactoring of the radeon/r200/r300 drivers. > > I've refactored all the: > buffer management, > buffer swap + copy, > texture and mipmap management, > command submission handling, > state + atom emission > dma buffers, > lock code, > > into common files for all 3 drivers, and re-used the same code in nearly > the same ways across all 3. > > So far I've been working on getting the legacy buffer/command code into > shape so I can merge this in place of the current drivers without > suffering any major regressions. Then start adding the code necessary for > DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to > merge, I'd like people to bash on it, and report any major regressions > above the current r100/r200/r300 codebases with these drivers. > > In order to get the mm/dri2 stuff working, I mainly need to > 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon > for this stuff at all I've made wrappers that I just need to use some > magic to hook up. > 2. add userspace clear paths for r100/r200. > 3. fix lockups from DRI2 lockless :) > 4. make it go fast. > > Most of the code was written by Nicolai and Jerome, I've just spent 2-3 > weeks moving it around the place until it works!! > > I've done a series of piglit regressions and I have one or two to fix, but > it seems to be only a couple left. > > Also any suggestions for things I should use to test this? I've mainly > been doing piglit + gears + ipers + openarena when I can. You might want to just steal intel_clear.c for the userspace clear path. Bonus points if you actually move it somewhere appropriate in Mesa. sauerbraten's a nice open-source game that works the driver a lot harder than openarena does. When you get to fbos, the gl branch of my cairo tree plus the gl branch of my cairogears tree is mostly memory management and fbo handling right now (until I fix it, then we'll hopefully need a more complicated testcase than gears to actually hit it hard). -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] BSD DRM updates
I've got diffs to get BSD DRM almost compiling for tdfx and mga up on my site. Check bsd-2-0-0-branch diffs (and the drm_agpsupport.h file, I didn't feel like merging linux and bsd agp into a single file right now). They are untested, but getting it to compile is a big step. Code tweaks I see still needing to be done are changing "return -ERR" type things to "DRM_OS_RETURN( ERR )" and dealing with inlines. I'll try out the drivers now that I've got the first set of diffs up. It's in the 4.3-STABLE section with today's date. http://www.teleport.com/~anholt/devel/dri -- Eric Anholt [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-2-0-0-branch)
It helps with some hangs related to unbinding of AGP textures. It would happen the second time you started X, if I recall correctly. We were letting areas get unbound twice. What problems are people having on BSD DRI at this point? P.S. I can't seem to send mail to you ( [EMAIL PROTECTED] ), "unrouteable mail domain" > > apply Eric's fixes for AGP support > > I went looking through dri-devel a bit to see if I could find more > information, not much luck. What was fixed? > > (here's hoping for a very good answer.. hehe) -- Eric Anholt [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Voodoo5 on FreeBSD
I figured out (kind of) why the v5 causes segfaults in GL apps on FreeBSD. It seems that when we try to dlopen() the extra symbols for v5, the dlopen passes but the subsequent dlsym()s fail, so we end up executing these null pointers at the first glide extension call. By dlopening my libglide explicitly, I've got the v5 up and running, though not very fast (10 fps with my tuxracer settings that get 8fps on a G400 and 7fps on a v3) and with some odd effects (mouse delays by a second in GL apps). I think the multihead branch will fix this in a much more friendly way, though I haven't checked it out yet. Still, for those of you on FreeBSD with v5s not working, changing the first NULL of the dlopen in g3ext.c to the path to your libglide will get you working until a better fix comes through. Did anyone out there have the v5 working in a different way? I seem to remember someone saying they did, but it doesn't seem to be in my mailbox. -- Eric Anholt [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Well, trunk kernel modules won't compile, but bsd-2-0-0-branch will usually compile and run most of the cards (rage128 is really slow, and i810 is not supported). I have patches for compiling the kernel modules, and a port of them, up at my webpage: http://gladstone.uoregon.edu/~eanholt/dri/ I also will have patches up for the non-kernel part of the build really soon now. On Tuesday 11 September 2001 03:00, you wrote: > What's the status of the bsd-2-0-0-branch branch vs the main trunk? I > didn't see an real differences between the two. Which one should I be > using to base my FreeBSD-current and ATI Rage Mobility DRI build on? > > Joe -- Eric Anholt [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Progress of mesa-3.5 tree? Update to Mesa-3.6/4.0
Would it be possible to set up an area on the webpage for people to pledge money towards certain projects (e.g. pageflipping on voodoo, glideless DRI driver for 3dfx, V5 SLI, tnl support for radeon, pseudodma ragepro driver)? I think a few people would be willing to put up some money for that, perhaps enough to get at least some poor college students working on these projects. On Friday 14 September 2001 17:32, you wrote: > On Friday 14 Sep 2001 6:58 pm, you wrote: > > I think people need to take a step back and have a think about how much > > money it costs to support top-class developers like those work/have > > worked on the DRI. We're talking hundreds of thousands of dollars a > > year. Unless > > Definitely. I can't see that ever being a way forward, unless it's in a > cosource style "price per feature" model. e.g. People club together to > raise $1000 to pay developer X to implement SLI for the V5. (Obviously > there are no specs available and so on, so that example is merely an > example) > > > the IHVs (or other companies) want to support it, I seriously doubt the > > open-source 3D graphics world will progress much further. Is the > > G400/r128 class of hardware relevant anymore? That's the last generation > > to see anything approaching full support by open-source drivers. > > Chicken + egg. > No specs, no development effort. No visible development effort, no > incentive to release specs. And the current consolidation of the graphics > hardware market does us no favours. > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Eric Anholt [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Xpert]Radeon 2D accel very slow when DRI is enabled.
I've had a couple of FreeBSD DRI and Radeon users complain about this too. I had always chalked it up to some bug in our drivers and I was waiting to get a Radeon myself to check it out. On Tuesday 20 November 2001 16:29, Mike A. Harris wrote: > On 20 Nov 2001, Owen Taylor wrote: > >Date: 20 Nov 2001 09:39:40 -0500 > > From: Owen Taylor <[EMAIL PROTECTED]> > > >To: Mike A. Harris <[EMAIL PROTECTED]> > >Cc: DRI devel list <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > > Hui Yu <[EMAIL PROTECTED]> > >Content-Type: text/plain; charset=us-ascii > >Subject: Re: [Xpert]Radeon 2D accel very slow when DRI is enabled. > > > > > >It's a little suprising to me that removing some (fairly unimportant) > >accelerations makes 2D "painfully slow"; except for a few things > >like blits and solid area fills, acceleration just doesn't matter > >much any more. What applications were you testing with? > > konsole, mozilla, any other application that is maximized. You > name it. I can watch it draw the whole screen and count out > loud. > > In 1600x1200x24 It takes 1 full second to draw the screen, or a > good 3/4 of a second. That is definitely not accelerated. > Again, disabling DRI, the MMIO accel makes everything fly. > > >I've seen DRI slow 2D down to a "crawl", but that's only been > >in memory limited situations where there isn't enough remaining > >offscreen memory for pixmaps, so drawing to them isn't accelerated > >at all. (Not even CopyArea and solid fills.) > > 64Mb DDR Radeon here, and 1Gb of system RAM. AGP aperture set to > 64Mb, and AGP 2x is being used. MTRR not functional on > serverworks. -- Eric Anholt [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
Just to alert others, I'm seeing this error in radeon_cp_indirect and r128_cce_indirect of the X server pid using buffer owned by 0. It's bsd-2-0-0-branch as of a few days ago. Everything still runs, but slowly. This is only happening to me on R128/Radeon, not MGA or 3dfx. > > root@ambre:~# tail -1 /var/log/syslog > > Nov 29 11:55:10 ambre kernel: [drm:r128_cce_vertex] *ERROR* process > > 1024 using buffer owned by 0 > > > > Is there any more information I can provide? Strace logs? Some more heavy > > debugging, maybe? > > What's the kernel message printed when loading the module, in particular > the version? The only thing I could think of is that you're using an > Alan Cox kernel and have configured it for the wrong XFree86 version or > something. -- Eric Anholt [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mesa-4-0-branch Imakefile fixes
BSD make is choking on some of the mesa Imakefiles in mesa-4-0-branch. A patch is attached, which I think is correct. Index: xc/lib/GL/mesa/src/math/Imakefile === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/math/Attic/Imakefile,v retrieving revision 1.1.4.3 diff -u -r1.1.4.3 Imakefile --- xc/lib/GL/mesa/src/math/Imakefile 2002/01/29 19:42:27 1.1.4.3 +++ xc/lib/GL/mesa/src/math/Imakefile 2002/02/04 21:48:17 @@ -52,7 +52,7 @@ -I../../../include INCLUDES = $(MESA_INCLUDES) $(DRI_INCLUDES) - SRCS = m_debug_clip.c \ +SRCS = m_debug_clip.c \ m_debug_norm.c \ m_debug_xform.c \ m_debug_vertex.c \ @@ -63,7 +63,7 @@ m_vertices.c \ m_xform.c - OBJS = m_debug_clip.o \ +OBJS = m_debug_clip.o \ m_debug_norm.o \ m_debug_xform.o \ m_debug_vertex.o \ Index: xc/lib/GL/mesa/src/swrast/Imakefile === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/swrast/Attic/Imakefile,v retrieving revision 1.1.4.3 diff -u -r1.1.4.3 Imakefile --- xc/lib/GL/mesa/src/swrast/Imakefile 2002/01/29 19:42:27 1.1.4.3 +++ xc/lib/GL/mesa/src/swrast/Imakefile 2002/02/04 21:48:17 @@ -73,7 +73,7 @@ -I../../../include INCLUDES = $(MESA_INCLUDES) $(DRI_INCLUDES) - SRCS = s_aaline.c \ +SRCS = s_aaline.c \ s_aatriangle.c \ s_accum.c \ s_alpha.c \ @@ -104,7 +104,7 @@ s_triangle.c \ s_zoom.c - OBJS = s_aaline.o \ + OBJS = s_aaline.o \ s_aatriangle.o \ s_accum.o \ s_alpha.o \ Index: xc/lib/GL/mesa/src/tnl/Imakefile === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/tnl/Attic/Imakefile,v retrieving revision 1.1.4.3 diff -u -r1.1.4.3 Imakefile --- xc/lib/GL/mesa/src/tnl/Imakefile 2002/01/29 19:42:28 1.1.4.3 +++ xc/lib/GL/mesa/src/tnl/Imakefile 2002/02/04 21:48:17 @@ -88,7 +88,7 @@ t_vb_texmat.c \ t_vb_vertex.c - OBJS = t_array_api.o \ + OBJS = t_array_api.o \ t_array_import.o \ t_context.o \ t_eval_api.o \ Index: xc/lib/GL/mesa/src/tnl_dd/Imakefile === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/tnl_dd/Attic/Imakefile,v retrieving revision 1.1.4.3 diff -u -r1.1.4.3 Imakefile --- xc/lib/GL/mesa/src/tnl_dd/Imakefile 2002/01/29 19:42:28 1.1.4.3 +++ xc/lib/GL/mesa/src/tnl_dd/Imakefile 2002/02/04 21:48:17 @@ -44,10 +44,10 @@ -I$(MESASRCDIR)/include \ -I../../../include - INCLUDES = $(MESA_INCLUDES) $(DRI_INCLUDES) - SRCS = +INCLUDES = $(MESA_INCLUDES) $(DRI_INCLUDES) +SRCS = - OBJS = +OBJS = #ifdef i386Architecture ASM_SRCS = Index: xc/programs/Xserver/GL/mesa/src/math/Imakefile === RCS file: /cvsroot/dri/xc/xc/programs/Xserver/GL/mesa/src/math/Attic/Imakefile,v retrieving revision 1.1.4.2 diff -u -r1.1.4.2 Imakefile --- xc/programs/Xserver/GL/mesa/src/math/Imakefile 2001/10/30 21:57:16 1.1.4.2 +++ xc/programs/Xserver/GL/mesa/src/math/Imakefile 2002/02/04 21:48:18 @@ -42,7 +42,7 @@ m_vertices.c \ m_xform.c - OBJS = m_debug_clip.o \ + OBJS = m_debug_clip.o \ m_debug_norm.o \ m_debug_vertex.o \ m_debug_xform.o \ Index: xc/programs/Xserver/GL/mesa/src/swrast/Imakefile === RCS file: /cvsroot/dri/xc/xc/programs/Xserver/GL/mesa/src/swrast/Attic/Imakefile,v retrieving revision 1.1.4.2 diff -u -r1.1.4.2 Imakefile --- xc/programs/Xserver/GL/mesa/src/swrast/Imakefile 2001/10/30 21:57:16 1.1.4.2 +++ xc/programs/Xserver/GL/mesa/src/swrast/Imakefile 2002/02/04 21:48:18 @@ -96,7 +96,7 @@ s_triangle.c \ s_zoom.c - OBJS = s_aaline.o \ + OBJS = s_aaline.o \ s_aatriangle.o \ s_accum.o \ s_alpha.o \ Index: xc/programs/Xserver/GL/mesa/src/tnl/Imakefile === RCS file: /cvsroot/dri/xc/xc/programs/Xserver/GL/mesa/src/tnl/Attic/Imakefile,v retrieving revision 1.1.4.2 diff -u -r1.1.4.2 Imakefile --- xc/programs/Xserver/GL/mesa/src/tnl/Imakefile 2001/10/30 21:57:17 1.1.4.2 +++ xc/programs/Xserver/GL/mesa/src/tnl/Imakefile 2002/02/04 21:48:18 @@ -65,7 +65,7 @@ t_vb_texmat.c \ t_vb_vertex.c - OBJS = t_array_api.o \ + OBJS = t_array_api.o \ t_array_import.o \ t_context.o \ t_eval_api.o \
Re: [PATCH] i915: Fix i2c init message
On Wed, 2009-09-30 at 14:26 -0600, Tim Gardner wrote:
> >From 8ef5591fa4392b4228b0be97013a8218f267ef90 Mon Sep 17 00:00:00 2001
> From: Tim Gardner
> Date: Wed, 30 Sep 2009 14:08:15 -0600
> Subject: [PATCH] i915: Fix i2c init message
>
> BugLink: http://bugs.launchpad.net/bugs/409361
>
> This message appears to be informational only.
Less than that, it appears to be debug only. Shall I just whack it to
DRM_DEBUG?
Signed-off-by: Tim Gardner
> Cc: sta...@kernel.org
> ---
> drivers/gpu/drm/i915/intel_dp.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2b914d7..d0f950c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -400,7 +400,7 @@ intel_dp_i2c_init(struct intel_output *intel_output,
> const char *name)
> {
> struct intel_dp_priv *dp_priv = intel_output->dev_priv;
>
> - DRM_ERROR("i2c_init %s\n", name);
> + DRM_INFO("i2c_init %s\n", name);
> dp_priv->algo.running = false;
> dp_priv->algo.address = 0;
> dp_priv->algo.aux_ch = intel_dp_i2c_aux_ch;
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerry® 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-12, 2009. Register now!
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 0/8] drmmode overlay support v3
On Tue, 2009-09-15 at 22:57 +0200, Daniel Vetter wrote: > Hi all, > > Latest version of my overlay kms work. I've added the new stuff as separated > patches for easier testing in case something blows up. > > Please review. > > Thanks, Daniel > > Daniel Vetter (8): > [drm]: make drm_mode_object_find typesafe > [drm/i915]: add i915_lp_ring_sync helper > [drm/i915]: kill superflous IS_I855 macro > [drm/i915] implement drmmode overlay support v4 > [drm/i915] fully switch off overlay when not in use > [drm/i915] implement fastpath for overlay flip waiting > [drm/i915] implement interruptible sleeps in the overlay code > [drm/i915] kill i915_lp_ring_sync OK, I've finally pulled this for -next, with a bit of hand resolving of conflicts. I debated, because of the somewhat unusual series of adding the ring sync, implementing, fixing the ring sync use, then removing ring sync. Often, that sort of stuff gets flattened out in the commit history. However, in this case I think it's OK as overlays are touchy and bisectability for "is the interruptible stuff working correctly" may prove useful. Then I noticed that you'd told me that there was newer stuff in your gitorious tree. Only, that stuff claims to be older (v3), and doesn't have some of the patches above. So I've pushed my merge to drm-overlay of my tree for review -- is it what you think should land? > drivers/gpu/drm/drm_crtc.c |3 +- > drivers/gpu/drm/i915/Makefile|1 + > drivers/gpu/drm/i915/i915_dma.c |7 + > drivers/gpu/drm/i915/i915_drv.h |8 +- > drivers/gpu/drm/i915/i915_gem.c | 37 +- > drivers/gpu/drm/i915/i915_reg.h |5 + > drivers/gpu/drm/i915/intel_display.c | 45 +- > drivers/gpu/drm/i915/intel_drv.h | 39 + > drivers/gpu/drm/i915/intel_overlay.c | 1420 > ++ > include/drm/drm_crtc.h |3 +- > include/drm/drm_os_linux.h |2 +- > include/drm/i915_drm.h | 71 ++ > 12 files changed, 1620 insertions(+), 21 deletions(-) > create mode 100644 drivers/gpu/drm/i915/intel_overlay.c > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Come build with us! The BlackBerry® 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-12, 2009. Register now! 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/i915: overlay: kill one more unnecessary uninterruptible sleep
On Sun, 2009-10-04 at 15:00 +0200, Daniel Vetter wrote:
> I've simply overlooked one case in the conversion to interruptible
> sleeps. Rectify this.
>
> Also delete a leftover debug printk.
OK, I'm confused about what this patch is about. I thought you were
going to check if the patch series I applied was the right one or not,
given that it was older than your comment "please pull my tree instead
of the patch series I sent out" on IRC.
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_overlay.c | 17 +++--
> 1 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_overlay.c
> b/drivers/gpu/drm/i915/intel_overlay.c
> index 972d715..f1bf0b0 100644
> --- a/drivers/gpu/drm/i915/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/intel_overlay.c
> @@ -286,16 +286,15 @@ static int intel_overlay_wait_flip(struct intel_overlay
> *overlay)
> RING_LOCALS;
>
> if (overlay->last_flip_req != 0) {
> - ret = i915_do_wait_request(dev, overlay->last_flip_req, 0);
> - if (ret != 0)
> - return ret;
> -
> - overlay->last_flip_req = 0;
> + ret = i915_do_wait_request(dev, overlay->last_flip_req, 1);
> + if (ret == 0) {
> + overlay->last_flip_req = 0;
>
> - tmp = I915_READ(ISR);
> + tmp = I915_READ(ISR);
>
> - if (!(tmp & I915_OVERLAY_PLANE_FLIP_PENDING_INTERRUPT))
> - return 0;
> + if (!(tmp & I915_OVERLAY_PLANE_FLIP_PENDING_INTERRUPT))
> + return 0;
> + }
> }
>
> /* synchronous slowpath */
> @@ -439,8 +438,6 @@ int intel_overlay_recover_from_interrupt(struct
> intel_overlay *overlay,
> return ret;
>
> case SWITCH_OFF_STAGE_2:
> - printk("switch off 2\n");
> -
> BUG_ON(!overlay->vid_bo);
> obj = overlay->vid_bo->obj;
>
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On Thu, 2009-10-22 at 17:11 -0700, Suresh Siddha wrote: > On Thu, 2009-10-22 at 16:10 -0700, Jesse Barnes wrote: > > On Thu, 22 Oct 2009 14:47:30 -0700 > > Suresh Siddha wrote: > > > > > On Thu, 2009-10-22 at 08:34 -0700, Eric Anholt wrote: > > > > Can we just not create the _wc sysfs entry if we don't have PAT? I > > > > don't think there's userland relying on its presence as opposed to > > > > the non-_wc entry. > > > > > > Yes indeed. Jesse do you see an issue with this? This is simple and > > > clean. Thanks Eric. > > > > Yeah, I think that will be fine. In fact, older versions of > > libpciaccess will behave better if we do it that way (iirc it only > > allocates an MTRR if the resource_wc file doesn't exist or fails to get > > mapped). > > Eric, care to send the patch? I don't have a patch, I was just suggesting a way to handle the submitter's problem that won't involve complicated changes that nobody else will be testing since everyone *should* have a graphics driver for their graphics hardware. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] DRI2 synchronization and swap bits
On Fri, 2009-10-30 at 10:59 -0700, Jesse Barnes wrote: > I've put up some trees (after learning my lesson about working in the > main tree) with the latest DRI2 sync/swap bits: > git://git.freedesktop.org/home/jbarnes/xserver master branch > git://git.freedesktop.org/home/jbarnes/mesa master branch > > They includes support for some new DRI2 requests (proto for which is in > the dri2-swapbuffers branch of dri2proto), including: > DRI2SwapBuffers > DRI2GetMSC > DRI2WaitMSC > and > DRI2WaitSBC > > These allow us to support GLX extensions like SGI_video_sync, > OML_swap_control and SGI_swap_interval. > > There have been a few comments about the protocol so far: > 1) DRI2SwapBuffers > a) Concern about doing another round trip to fetch new buffers > following the swap. > I think this is a valid concern, we could potentially respond > from the swap with the new buffers, but this would make some > memory saving optimizations more difficult (e.g. freeing > buffers if no drawing comes in for a short time after the swap). You're doing one round-trip anyway, and if users are concerned about the second one, go use XCB already. (We need to go fix Mesa to do that). -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: > 2009/11/6 Kristian Høgsberg : > > Hi, > > > > This has come up a few time and it's something I think makes a lot of > > sense. Since all driver development (afaik) now happens in linux > > kernel tree, it makes sense to drop the driver bits from the drm.git > > repo. I've put up a repo under > > Actually, I don't think a separate libdrm makes much sense. We don't > want to add yet another outside component and ask ourselves questions > like "how do I maintain compatibility" (which, incidentally, have > already been raised). > > Given this, IMO libdrm live somewhere alongside the kernel. > Furthermore when pulling outside stuff we driver devs can do a > kernel+DRM+libdrm pull at the same time which is a win. > > And also users don't have to wonder where/how to pick the right > libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Our code used to be that way before we fixed libdrm to be "only use kernel code that's going upstream, and never regress it". Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. This is why I've also argued against having libdrm not install the ioctl headers. It seems like the argument is mostly that having libdrm keep a copy of the kernel headers in the repo is bad because people might cp the file wrong. If the cost of not keeping them in the repo is having the libdrm and its consumers be ifdef hell, I will keep a cp in the repo. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: > On Sun, Nov 8, 2009 at 19:18, Eric Anholt wrote: > > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: > >> 2009/11/6 Kristian Høgsberg : > >> > Hi, > >> > > >> > This has come up a few time and it's something I think makes a lot of > >> > sense. Since all driver development (afaik) now happens in linux > >> > kernel tree, it makes sense to drop the driver bits from the drm.git > >> > repo. I've put up a repo under > >> > >> Actually, I don't think a separate libdrm makes much sense. We don't > >> want to add yet another outside component and ask ourselves questions > >> like "how do I maintain compatibility" (which, incidentally, have > >> already been raised). > >> > >> Given this, IMO libdrm live somewhere alongside the kernel. > >> Furthermore when pulling outside stuff we driver devs can do a > >> kernel+DRM+libdrm pull at the same time which is a win. > >> > >> And also users don't have to wonder where/how to pick the right > >> libdrm. You get the right one with your kernel. > > > > This is a bad idea. libdrm with the kernel means that users and > > distributions can't trivially update libdrm. So all of the users of > > libdrm end up being an ifdeffed nightmare of both compile-time and > > runtime detection. > > Why do you need to update libdrm separately from the kernel? Is there > so much that's in libdrm that does not also require a new drm? Newer > libdrm functionality usually also requires a new drm... > > > Our code used to be that way before we fixed libdrm > > to be "only use kernel code that's going upstream, and never regress > > it". Things have improved in the last few years for upstream drivers, > > and I don't want to regress them with moving libdrm to the kernel. > > Again I don't see what kind of changes you have in mind. You just say > "regress". I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: > On Sun, Nov 8, 2009 at 20:02, Eric Anholt wrote: > > On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: > >> On Sun, Nov 8, 2009 at 19:18, Eric Anholt wrote: > >> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: > >> >> 2009/11/6 Kristian Høgsberg : > >> >> > Hi, > >> >> > > >> >> > This has come up a few time and it's something I think makes a lot of > >> >> > sense. Since all driver development (afaik) now happens in linux > >> >> > kernel tree, it makes sense to drop the driver bits from the drm.git > >> >> > repo. I've put up a repo under > >> >> > >> >> Actually, I don't think a separate libdrm makes much sense. We don't > >> >> want to add yet another outside component and ask ourselves questions > >> >> like "how do I maintain compatibility" (which, incidentally, have > >> >> already been raised). > >> >> > >> >> Given this, IMO libdrm live somewhere alongside the kernel. > >> >> Furthermore when pulling outside stuff we driver devs can do a > >> >> kernel+DRM+libdrm pull at the same time which is a win. > >> >> > >> >> And also users don't have to wonder where/how to pick the right > >> >> libdrm. You get the right one with your kernel. > >> > > >> > This is a bad idea. libdrm with the kernel means that users and > >> > distributions can't trivially update libdrm. So all of the users of > >> > libdrm end up being an ifdeffed nightmare of both compile-time and > >> > runtime detection. > >> > >> Why do you need to update libdrm separately from the kernel? Is there > >> so much that's in libdrm that does not also require a new drm? Newer > >> libdrm functionality usually also requires a new drm... > >> > >> > Our code used to be that way before we fixed libdrm > >> > to be "only use kernel code that's going upstream, and never regress > >> > it". Things have improved in the last few years for upstream drivers, > >> > and I don't want to regress them with moving libdrm to the kernel. > >> > >> Again I don't see what kind of changes you have in mind. You just say > >> "regress". > > > > I need to enable a new feature in the driver by relying on a new kernel > > interface. This happens at least once per kernel version (every ~3 > > months), and we're currently retaining backwards compatibility to > > kernels a year old. > > > > Today, this ends up easy. In my driver components (Mesa and > > xf86-video-intel) I pkg-config version assert on on the new version of > > libdrm with the new headers. I do a runtime detection of the new > > feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl > > interface as appropriate. An example of this would be > > kernel_exec_fencing in 2.6.29, which impacts many files in the driver. > > > > If userland doesn't get to assert new libdrm/interface header presence, > > then in addition to the runtime detection, I have to ifdef all use of > > the new interfaces. Now, if we screw up the ifdefs (which used to > > happen regularly), people's builds don't work because they have old > > kernels. > > > > People obviously thought that situation sucked in the past, as we saw in > > both the intel and radeon drivers where pieces of the drm headers were > > just spammed right into the files using them, under ifdefs. This did > > result in actual divergence from the kernel definitions and real bugs, > > unlike today's situation where diff can confirm for me that we're using > > exactly the same interfaces between userland and kernel. > > > > Okay, well in any case nothing in what you mentioned prevents the > libdrm from living with the kernel. We could keep the compat stuff > here, and we still have the advantages I mentioned. > > So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: > On Sun, Nov 8, 2009 at 23:33, Eric Anholt wrote: > > On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: > >> On Sun, Nov 8, 2009 at 20:02, Eric Anholt wrote: > >> > On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: > >> >> On Sun, Nov 8, 2009 at 19:18, Eric Anholt wrote: > >> >> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: > >> >> >> 2009/11/6 Kristian Høgsberg : > >> >> >> > Hi, > >> >> >> > > >> >> >> > This has come up a few time and it's something I think makes a lot > >> >> >> > of > >> >> >> > sense. Since all driver development (afaik) now happens in linux > >> >> >> > kernel tree, it makes sense to drop the driver bits from the > >> >> >> > drm.git > >> >> >> > repo. I've put up a repo under > >> >> >> > >> >> >> Actually, I don't think a separate libdrm makes much sense. We don't > >> >> >> want to add yet another outside component and ask ourselves questions > >> >> >> like "how do I maintain compatibility" (which, incidentally, have > >> >> >> already been raised). > >> >> >> > >> >> >> Given this, IMO libdrm live somewhere alongside the kernel. > >> >> >> Furthermore when pulling outside stuff we driver devs can do a > >> >> >> kernel+DRM+libdrm pull at the same time which is a win. > >> >> >> > >> >> >> And also users don't have to wonder where/how to pick the right > >> >> >> libdrm. You get the right one with your kernel. > >> >> > > >> >> > This is a bad idea. libdrm with the kernel means that users and > >> >> > distributions can't trivially update libdrm. So all of the users of > >> >> > libdrm end up being an ifdeffed nightmare of both compile-time and > >> >> > runtime detection. > >> >> > >> >> Why do you need to update libdrm separately from the kernel? Is there > >> >> so much that's in libdrm that does not also require a new drm? Newer > >> >> libdrm functionality usually also requires a new drm... > >> >> > >> >> > Our code used to be that way before we fixed libdrm > >> >> > to be "only use kernel code that's going upstream, and never regress > >> >> > it". Things have improved in the last few years for upstream drivers, > >> >> > and I don't want to regress them with moving libdrm to the kernel. > >> >> > >> >> Again I don't see what kind of changes you have in mind. You just say > >> >> "regress". > >> > > >> > I need to enable a new feature in the driver by relying on a new kernel > >> > interface. This happens at least once per kernel version (every ~3 > >> > months), and we're currently retaining backwards compatibility to > >> > kernels a year old. > >> > > >> > Today, this ends up easy. In my driver components (Mesa and > >> > xf86-video-intel) I pkg-config version assert on on the new version of > >> > libdrm with the new headers. I do a runtime detection of the new > >> > feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl > >> > interface as appropriate. An example of this would be > >> > kernel_exec_fencing in 2.6.29, which impacts many files in the driver. > >> > > >> > If userland doesn't get to assert new libdrm/interface header presence, > >> > then in addition to the runtime detection, I have to ifdef all use of > >> > the new interfaces. Now, if we screw up the ifdefs (which used to > >> > happen regularly), people's builds don't work because they have old > >> > kernels. > >> > > >> > People obviously thought that situation sucked in the past, as we saw in > >> > both the intel and radeon drivers where pieces of the drm headers were > >> > just spammed right into the files using them, under ifdefs. This did > >> > result in actual divergence from the kernel definitions and real bugs, > >> > unlike today's situation where diff can confirm
Re: RFC: libdrm repo
On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: > 2009/11/6 Kristian Høgsberg : > > Hi, > > > > This has come up a few time and it's something I think makes a lot of > > sense. Since all driver development (afaik) now happens in linux > > kernel tree, it makes sense to drop the driver bits from the drm.git > > repo. > > Ok, here's an update to the proposal. I've rebased the libdrm branch > in people.freedesktop.org/~krh/libdrm.git to include a copy of > $kernel_source/usr/include/drm as a toplevel include/drm directory in > git. I also added a makefile rule to copy a new version of the > headers from a kernel git repo and commit it with a message describing > the version it was copied from. The location of the kernel repo is > given at ./configure time with the --with-kernel-source argument. > > By adding the makefile rule, I'd like to encourage people to not hand > edit the headers and to commit updates of the header files > independently from other changes. And of course, updates to the > headers should still follow the rules we have now; only copy over new > changes once they're in drm-next (I think, or is that in Linus' > tree?). > > Anyway, I think this should address the concerns raised in the thread > and if there's no other problems, I can put this into place today. > I'll merge the couple of changes on master since I branched for this > work and I'll put a mesa/drm.git symlink in place to point to > libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG][BISECTED][RESENT] Ogre3d produces black screen on Intel 965GM
On Wed, 25 Nov 2009 22:38:30 +0100, Dariush Forouher wrote: > Hi everyone, > > applications using the ogre3d library (www.ogre3d.org) only show > black screens instead of fancy 3D graphics on current 2.6.32-rc8. > On 2.6.31 they worked fine. > > In the error case the kernel reports errors like this: > > [drm:i915_gem_object_pin_and_relocate] *ERROR* Relocation beyond target > object bounds: obj 8800d74c3b40 target 91 delta 4096 size 4096. [...] > I bisected it down to the following commit: > > commit cd0b9fb400ba775737bdc3874c4cbee4047e66d8 > Author: Chris Wilson > Date: Tue Sep 15 23:23:18 2009 +0100 > > drm/i915: Check that the relocation points to within the target [...] > Reverting the commit manually makes the problem disappear. > > cheers > Dariush > > > Platform: AMD64 > Distro: Debian testing > GPU: Intel 965GM > xserver: 1.6.5 > xorg-intel: 2.9.0 > libdrm: 2.4.14 > OGRE: 1.6.4 You didn't mention the most important software version for 3D issues: that of Mesa. There were bugs there that this safety check caught. commit a82da7fa263c7fb6b902285994136890e6dc3278 Author: Eric Anholt Date: Sun Oct 11 11:04:09 2009 -0700 i965: Fix the bounds emitted in the vertex buffer packets. It's the address of the last valid byte, not the address of the first invalid byte. This should also fix problems with rendering with the new sanity checks in the kernel. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/i915: add GETPARAM request for page flipping
On Thu, 19 Nov 2009 10:49:07 -0800, Jesse Barnes wrote: > From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 > From: Jesse Barnes > Date: Wed, 18 Nov 2009 04:31:47 + > Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping > > Add a GETPARAM request for checking if page flipping is supported. > Useful for the 2D driver to enable the flipping path. > > Signed-off-by: Jesse Barnes OK, I've applied this series in what I'm guessing was the desired order: 1) pageflipping support 2) core fixup 3) getparam to say it's ready Also, something seems wonky with your patches. The git am gives me: anh...@gaiman:anholt/src/linux-2.6% git log commit b0f57d0ff95c957b278d7a82d9ebdea395652cfa Author: Jesse Barnes Date: Thu Nov 19 10:49:07 2009 -0800 drm/i915: add GETPARAM request for page flipping From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes Signed-off-by: Eric Anholt Are you not using git send-email? -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Fix sync to vblank when VGA output is turned off
On Mon, 09 Nov 2009 12:51:22 +0800, Li Peng wrote: > In current vblank-wait implementation, if we turn off VGA output, > drm_wait_vblank will still wait on the disabled pipe until timeout, > because vblank on the pipe is assumed be enabled. This would cause > slow system response on some system such as moblin. > > This patch resolve the issue by adding a drm helper function > drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up > any waiting queue and save last vblank counter before turning off > crtc. It also slightly change drm_vblank_get to ensure that we will > will return immediately if trying to wait on a disabled pipe. > > Signed-off-by: Li Peng Applied. Thanks! -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/intel: refactor DP i2c support and DP common header to drm helper
On Fri, 4 Dec 2009 11:08:00 +1000, Dave Airlie wrote: > From: Dave Airlie > > Both radeon and nouveau can re-use this code so move it up a level > so they can. However the hw interfaces for aux ch are different > enough that the code to translate from mode, address, bytes > to actual hw interfaces isn't generic, so move that code into the > Intel driver. Sounds like a good plan to me. The patch is all conflicty, though. Care to pull my tree and apply an updated version just after you do so? Acked-by: Eric Anholt pgpESYIeTGych.pgp Description: PGP signature -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Disable all the possibles output/crtcs before entering KMS mode
On Fri, 4 Dec 2009 23:22:51 +0100, Rafał Miłecki wrote: > 2009/12/4 Dave Airlie : > > On Fri, 2009-12-04 at 20:05 +0800, yakui.z...@intel.com wrote: > >> From: Zhao Yakui > >> > >> Disable all the possible outputs/crtcs before entering KMS mode. > > > > We need a bit more info than this for such a large change? > > > > At one point we wanted to do smooth startup for LVDS panels, > > so that we read back the mode and avoided reconfiguring them > > this sort of change would totally go against it. > > > > Also I thought Arjan wanted to avoid slowdowns on startup, > > which I would expect this to add to. > > We have something like drm_disable_unused_functions. Isn't that > supposed to make what you introduce there? At least at KMS booting > when we don't have encoders/crtcs/outputs configured it should work > for that. Am I wrong? Yeah, drm_helper_disable_unused_functions with everything set to disconnected should do this. And if we want to get flicker-free transitions, then we could read out current state for some outputs and set our current state accordingly before calling that. It's something I've wanted to do since the original UMS work. But it is true that if we aren't reading current state out, we do need to turn everything off before modesetting. The clocks can get very angry at you otherwise, and you get things worse than a flicker at boot. (So, my review of this patch is: close, but just use drm_helper_disable_unused_functions instead of making a new function) pgpyjh6Th0l7V.pgp Description: PGP signature -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915/crt: Always attempt ddc on both GPIOA and GPIOD
On Tue, 8 Dec 2009 17:24:21 +0100, Helge Bahmann wrote: > The small attached patch fixes a failure to fetch EDID for a newly connected > display, when the previously connected display did not provide EDID. > > Overall I have found that hot-plugging displays with different resolutions at > run-time does not work too well with KMS, once a mode gets added to a > connector, it apparently never goes away, which means that replacing a > display > with a smaller one at run-time is problematic. Is there any work in progress > to improve that? This patch looks good. However, patches to the Linux kernel require a Signed-off-by indicating your acceptance of the Developer's Certificate of Origin, described in linux-2.6/Documentation/SubmittingPatches. Could you resend with that? pgpdKXUuo7wQM.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
