On 02/23/2012 06:15 PM, Linus Torvalds wrote:
On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson<chris@xxxxxxxxxxxxxxxxxx> wrote:
i2c retries if sees an EGAIN, drm_do_probe_ddc_edid retries until it
gets a result and *then* drm_do_get_edid retries until it gets a result
it is happy with. All in all, that is a lot of processor intensive
looping in cases where we do not expect and cannot get valid data - for
example on Intel with disconnected hardware we will busy-spin until we
hit the i2c timeout. This is then repeated for every connector when
querying the current status of outputs.
Sadly, this doesn't seem to make any difference to my case. My xrandr
stays at 0.555s even with this patch.
Perhaps a stupid question, but does you tree has
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=9292f37e1f5c79400254dca46f83313488093825
from Dave's drm-next?
If it has, it would be the 1st time that I see xrandr take longer than
.5s with that patch on an Intel GPU. We even added a check for this into
intel-gpu-tools to warn us if any machine takes that long, and none had
hit it so far. So if this is the case here, there is something Mac
Mini-specific indeed to investigate.
-Eugeni
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
