After some iterations of my patch to improve the edid detection timings, I finally posted the release-candidate version of it to the intel-gfx mailing list yesterday.
What is this patch about? In many cases, when you have a system with different video outputs (say, VGA, HDMI, DP, among others), sometimes a simple xrandr execution takes too long – sometimes even longer than 1 second (the famous BUG #41059).
The first two iterations of this fix managed to improve the timing by a huge margin – as much by a factor 100x actually in some cases. But the drawback is that the fix also managed to exclude some valid port connectors sometimes, so it wasn’t a valid fix after all.
After more investigation, I came to realize that what happens in some cases is that the pins used for detection are stuck while the the connector is not plugged in; and suddenly come to their senses when the connector is there. So we couldn’t just ignore those pins in all cases – even if they seem to be invalid, they could change their mind at some point.
So I came with two different sets of patches – one which fixes the issue directly in drm, and should benefit all the video cards using it for edid detection; and another which does the same thing but within the i915 driver. In both cases, I have experienced a 30%-300% improvements in output detection on all the machines I have tested, which also resulted in some seconds of boot-time optimizations in total. So it is a nice improvement in my opinion 
.
The advantage of the first approach is that it should work with each card; but the disadvantage is that I don’t have any non-intel cards around for a long time already – well, technically, for 6 months, since my ASUS G1S passed away after 4 years or use, 2 years of disk uptime according to S.M.A.R.T.. He was solely responsible for all the builds of 4 Mandriva releases (2010.2 and all the 2011 preliminar ones) – so indeed, it was a hero notebook.
But back to the topic – if by a chance you experience slow xrandr execution; or you think that your machine takes a long time to start X or during the boot while attempting to find out all the video output it has – give them a try! I’d be very interested in any feedback.
Does this also speed up the time taken when KMS loads in the kernel? Currently my new laptop spends 5 or 6 seconds to modeset then switches the backlight off. I’m going to raise a bug about the backlight problem.
Out of interest is your patch set on a git tree somewhere?
@Mike – yes, it should improve the kms loading time as well, and the boot time too.
There were some comments about backlight, but I think it is not caused by the i915 driver, but something ACPI-related. There was some discussion about it on irc some days ago, and there is a bug in bugzilla as well, but I don’t recall its number right away.
I still haven’t pushed those patches to any git tree, but I’ll do it and they should appear at http://cgit.freedesktop.org/~eugeni/kernel today or tomorrow
.
These patches seem to make things even slower for me
It takes longer for the screen to go black (ie the backlight going off when modesetting happens)
Sorry to paste this here but:
Linux agpgart interface v0.103 agpgart-intel 0000:00:00.0: Intel Sandybridge Chipset agpgart-intel 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable agpgart-intel 0000:00:00.0: detected 32768K stolen memory agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xb0000000 [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. VGA switcheroo: detected switching method \_SB_.PCI0.GFX0.ATPX handle radeon 0000:01:00.0: enabling device (0000 -> 0003) radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 radeon 0000:01:00.0: setting latency timer to 64 [drm] initializing kernel modesetting (TURKS 0×1002:0×6741 0x103C:0×3385). [drm] register mmio base: 0xC8700000 [drm] register mmio size: 131072 Refined TSC clocksource calibration: 1995.466 MHz. Switching to clocksource tsc
SYSTEM WAITS HERE FOR ABOUT 10 SECONDS MAYBE MORE
ATOM BIOS: HP/IEC radeon 0000:01:00.0: VRAM: 1024M 0×0000000000000000 – 0x000000003FFFFFFF (1024M used) radeon 0000:01:00.0: GTT: 512M 0×0000000040000000 – 0x000000005FFFFFFF mtrr: no more MTRRs available [drm] Detected VRAM RAM=1024M, BAR=128M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 4055218 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [TTM] Initializing pool allocator. [drm] radeon: 1024M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. radeon 0000:01:00.0: irq 43 for MSI/MSI-X radeon 0000:01:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading TURKS Microcode radeon 0000:01:00.0: WB enabled [drm] ring test succeeded in 3 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Internal thermal controller without fan control [drm] radeon: power management initialized No connectors reported connected with modes [drm] Cannot find any crtc or sizes – going 1024×768 [drm] fb mappable at 0xC0141000 [drm] vram apper at 0xC0000000 [drm] size 3145728 [drm] fb depth is 24 [drm] pitch is 4096 Console: switching to colour frame buffer device 128×48 fb0: radeondrmfb frame buffer device drm: registered panic notifier [drm] Initialized radeon 2.11.0 20080528 for 0000:01:00.0 on minor 0 i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 i915 0000:00:02.0: setting latency timer to 64 trr: type mismatch for b0000000,10000000 old: write-back new: write-combining [drm] MTRR allocation failed. Graphics performance may suffer. i915 0000:00:02.0: irq 44 for MSI/MSI-X [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. vga_switcheroo: enabled radeon atpx: version is 1 vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=none vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem i915: adapter i915 gmbus dpc not responding: -6 i915: adapter i915 gmbus dpd not responding: -6 fbcon: inteldrmfb (fb1) is primary device fbcon: Remapping primary device, fb1, to tty 1-63 [drm:ironlake_update_pch_refclk] ERROR enabling SSC on PCH fb1: inteldrmfb frame buffer device [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS acpi device:31: registered as cooling_device9 input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/LNXVIDEO:00/input/input3 ACPI: Video Device [PEGP] (multi-head: yes rom: no post: no) acpi device:3e: registered as cooling_device10 input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input4 ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 1
Sorry that really didn’t work properly http://pastebin.com/cPHsYjGi
@Mike – the patches are at http://cgit.freedesktop.org/~eugeni/kernel now, in two different branches – one for drm fix (which should benefit all the cards), and one for i915-specific (which does the same thing, but does not affects other graphical drivers).
Interesting – I cannot explain those delays, because they happen before the patched code should work.
Could you get dmesg output with timing values, so we could see what is the delay between messages?
OK here’s the vanilla: http://pastebin.com/zMpzni97
edid-i915 http://pastebin.com/2xKayahX
edid-drm appears to have crashed the machine. The backlight wouldn’t come on and I was unable to ssh in – I’m not sure how to collect the logs in that instance – when I tested both of your patches applied yesterday this didn’t happen