[Intel-gfx] Suggestions on fixing fill_modes ioctl() delays under i915

[Dan Aloni]

Hello,

I'd like to assist in fixing an issue that is quite nagging concerning the
i915 driver. I wasn't sure whether to classify this as a bug, but it's
something worth considering. Let me explain.

When I first used the i915 driver on my Lenovo X220 laptop, I noticed that
every time I run xrandr, or when any X client tries to query the display
modes, the X server hangs for a second or so. Using systemtap, I was able
to track the hang to the Intel DRM driver, around the area in which it
talks over i2C in order to query the modes from display
controller. More specifically, drm_mode_getconnector() is calling i915's
->fill_modes() and it waits there for awhile.

Now you might ask why it is annoying. Well, for instance, say you are
debugging an SDL application. Those type of applications usually result in
the GET_CONTROLLERS ioctl() being called by the X server, and re-running
the same application in a development cycle makes this issue
quite noticeable.

To make my work bearable, I came as far as adding a sysfs kernel module
parameter to DRM for the purpose of force-disabling the condition of the
call to fill_mode(). Now imagine, I do 'echo  1  >
/sys/module/drm/parameters/dont_fill_modes', and voila, xrandr works like
charm, SDL apps don't get stuck on init. Good until I disconnect my laptop
from the display port, or until it suspends. YUCK. Of course we don't want
this approach, it's an ugly hack.

I am hoping that DRM/Intel developers might be able to come with a fix. I'd
be happy to leverage my kernel hacking skills for this. My setup is a Linux
3.2.11 vanilla, xserver-xorg 1:7.6+4ubuntu3.2, x86_64 on Lenovo X220,
PCI_ID 8086:0126 (rev 09). Problem is 100% reproducible, and happens
whether I'm directly connected without a docking station via DisplayPort,
or whether I'm using a docking station with a display connected to it by
DVI.

Thanks.
- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120416/4a27f692/attachment.html>