On 02/23/2012 06:15 PM, Linus Torvalds wrote:
On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilsonchris@chris-wilson.co.uk 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=9292f37... 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