We only have sufficient information for accurate (sub-frame) timestamping when the modesetting is under our control.
Reported-by: Chris Clayton chris2553@googlemail.com Signed-off-by: Chris Wilson chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/i915_drv.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 59eb19b..66796bb 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -752,6 +752,9 @@ static int __init i915_init(void) driver.driver_features &= ~DRIVER_MODESET; #endif
+ if (!(driver.driver_features & DRIVER_MODESET)) + driver.get_vblank_timestamp = NULL; + return drm_init(&driver); }
Hi Chris,
On Sunday 23 January 2011, Chris Wilson wrote:
With this patch (and the earlier one) applied, X still doesn't start. At the end of xorg's log file I see:
Fatal server error: Failure to wait for IRQ: No such device
and in the kernel log I see:
Jan 23 11:15:25 upstairs kernel: [drm] Initialized drm 1.1.0 20060810 Jan 23 11:15:26 upstairs kernel: pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Jan 23 11:15:26 upstairs kernel: pci 0000:00:02.0: setting latency timer to 64 Jan 23 11:15:26 upstairs kernel: ioremap error for 0xbdce0000-0xbdce3000, requested 0x10, got 0x0 Jan 23 11:15:26 upstairs kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Jan 23 11:15:26 upstairs kernel: [drm] No driver support for vblank timestamp query. Jan 23 11:15:26 upstairs kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Chris
On Sun, 23 Jan 2011 11:28:22 +0000, Chris Clayton chris2553@googlemail.com wrote:
Now we are getting closer! The X server has been caught red-handed trying to use an interrupt when the driver never enabled them. Ho hum.
The interrupts for UMS are only enabled between EnterVT/LeaveVT, but that code looks defunct. What version of xf86-video-intel are you using? -Chris
On Sunday 23 January 2011, Chris Wilson wrote:
On Sun, 23 Jan 2011 11:28:22 +0000, Chris Clayton chris2553@googlemail.com
wrote:
It's 2.7.1, which, IIRC, is the latest version that will build against all the other xorg libraries that are on my system. I'll do a quick check after lunch to see if any later versions will build without me going through dependency hell.
Thanks for your help so far,
Chris
-Chris
If the driver calls into the kernel to wait for a breadcrumb to pass, but hasn't enabled interrupts, fallback to polling the breadcrumb value.
Reported-by: Chris Clayton chris2553@googlemail.com Signed-off-by: Chris Wilson chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/i915_irq.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 98106b7..4b5a35c 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1293,12 +1293,12 @@ static int i915_wait_irq(struct drm_device * dev, int irq_nr) if (master_priv->sarea_priv) master_priv->sarea_priv->perf_boxes |= I915_BOX_WAIT;
- ret = -ENODEV; if (ring->irq_get(ring)) { DRM_WAIT_ON(ret, ring->irq_queue, 3 * DRM_HZ, READ_BREADCRUMB(dev_priv) >= irq_nr); ring->irq_put(ring); - } + } else if (wait_for(READ_BREADCRUMB(dev_priv) >= irq_nr, 3000)) + ret = -EBUSY;
if (ret == -EBUSY) { DRM_ERROR("EBUSY -- rec: %d emitted: %d\n",
On Sunday 23 January 2011, Chris Wilson wrote:
That's done it. With all three patches applied, X and KDE are starting now. Thanks for your work on this.
A couple of points though.
1. The latest patch applied but the following warning was spat out:
patching file drivers/gpu/drm/i915/i915_irq.c Hunk #1 succeeded at 1288 (offset -5 lines).
I guess we may be working with slightly different versions of the source.
2. The kernel log now contains the following:
r8169 0000:02:00.0: eth0: link up [drm] Initialized drm 1.1.0 20060810 irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: kworker/0:1 Not tainted 2.6.38-rc2+ #502 Call Trace: [<c1070a54>] ? __report_bad_irq.clone.2+0x24/0x90 [<c1070c17>] ? note_interrupt+0x157/0x190 [<c101b1cd>] ? ack_apic_level+0x5d/0x1e0 [<c107175b>] ? handle_fasteoi_irq+0xab/0xd0 [<c10716b0>] ? handle_fasteoi_irq+0x0/0xd0 <IRQ> [<c1004ddd>] ? do_IRQ+0x3d/0xc0 [<c1037f27>] ? irq_exit+0x57/0x70 [<c1019173>] ? smp_apic_timer_interrupt+0x53/0x90 [<c1003229>] ? common_interrupt+0x29/0x30 [<c119fbe9>] ? acpi_safe_halt+0x19/0x26 [<c119fc50>] ? acpi_idle_enter_c1+0x5a/0xa9 [<c1244d98>] ? cpuidle_idle_call+0x68/0xf0 [<c1001726>] ? cpu_idle+0x46/0x80 handlers: [<c129dd60>] (azx_interrupt+0x0/0x180) [<c12210d0>] (usb_hcd_irq+0x0/0x60) Disabling IRQ #16 pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 pci 0000:00:02.0: setting latency timer to 64 ioremap error for 0xbdce0000-0xbdce3000, requested 0x10, got 0x0 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Is this likely to be related the the irq issues your patch addressed or is it a separate thing that I should report separately?
Thanks again.
Chris
On Sun, 23 Jan 2011 15:38:41 +0000, Chris Clayton chris2553@googlemail.com wrote:
That's done it. With all three patches applied, X and KDE are starting now. Thanks for your work on this.
That's good to hear!
Minor drift as I now have a number of outstanding patches for 2.6.38.
It's the i915 IRQ alright, but I'm not sure what the cause is. An unexpected interrupt arrived, although you don't use any paths in the driver that use interrupts, nor should one be generated when all we are doing is initialising the device structs. Should just be a minor nuisance fortunately.
If you can open a bug report to track it and attach /sys/kernel/debug/dri/0/i915_gem_interrupts maybe we can work out from the interrupt that arrived, why it was triggered. -Chris
Hi Chris,
On Sunday 23 January 2011, Chris Wilson wrote:
On Sun, 23 Jan 2011 15:38:41 +0000, Chris Clayton chris2553@googlemail.com
wrote:
<snip>
OK, I haven't raised the bug report yet, but I now know how to create it - reboot via kexec which is what I must have done when I built and installed the kernel to test your patches. I guess not having booted via the bios is leaving the card in an odd state. Do you care any more, please? If you do, I'll open the bug report.
Chris
On Thu, 10 Feb 2011 19:58:12 +0000, Chris Clayton chris2553@googlemail.com wrote:
Please, I think we left my very small field of expertise so a bug may help attract the attention of those in the know... -Chris
dri-devel@lists.freedesktop.org
-
Chris Clayton -
Chris Wilson