On Sun, 2010-08-15 at 21:01 -0700, Linus Torvalds wrote:
On Sun, Aug 15, 2010 at 8:30 PM, Dave Airlie airlied@redhat.com wrote:
At least we should replace mdelay with msleep in those functions.
How precise does the timing have to be? I think i2c is self-clocking, so it's ok to see big skews? Becuase msleep() can be off by quite a bit (mdelay can too, but it's _way_ more rare, and requires either a preemptible kernel or serious interrupt activity).
In this case it definitely doesn't matter, I expect msleep to be a much nicer to the system in general idea esp in routines we can all at runtime from userspace.
Can you get a boot with drm.debug=4?
Sure. That results in a truncated dmesg (with a 128k buffer). The thing seems to spew out something every ten seconds:
... [ 232.610044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) [ 232.624504] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00 (Success) [ 232.624517] [drm:intel_sdvo_detect], SDVO response 1 0 [ 232.624524] [drm:intel_sdvo_debug_write], SDVOB: W: 7A 01 (SDVO_CMD_SET_CONTROL_BUS_SWITCH) [ 242.672044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) [ 242.686503] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00 (Success) [ 242.686516] [drm:intel_sdvo_detect], SDVO response 1 0 [ 242.686523] [drm:intel_sdvo_debug_write], SDVOB: W: 7A 01 (SDVO_CMD_SET_CONTROL_BUS_SWITCH) [ 252.750044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) [ 252.764526] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00 (Success) [ 252.764539] [drm:intel_sdvo_detect], SDVO response 1 0 ...
It looks like it takes about 15 ms each time. But 15 ms each 10s doesn't seem to be enough to account for the load average. Maybe it gets synchronized with the timer tick or something, causing the load average to look artificially inflated (it also doesn't match up with kworker using 1%+ CPU time).
So maybe there is something else going on. Maybe the load average thing comes from some interaction with the new workqueue thing.
I'll send the whole dmesg to you in a private message, I don't think we want 128kB of crud on lkml.
I wonder are we picking up a bad SDVO, the insane code retries 50 times with a hard loop delay.
Well, I'm not seeing any failures, but maybe those don't get printed out?
Oh wierd, so not where I thought it was, I expect then the SDVO HDMI detection is completely insane,
intel_sdvo_hdmi_sink_detect looks to contain some really uninspiring code. Might be worth adding some debug in there to see if it sinks a lot of time.
Dave.