From: Dave Airlie <airlied@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Airlie <airlied@linux.ie>,
Chris Wilson <chris@chris-wilson.co.uk>,
Zhao Yakui <yakui.zhao@intel.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Adam Jackson <ajax@redhat.com>,
linux-kernel@vger.kernel.org,
DRI mailing list <dri-devel@lists.freedesktop.org>
Subject: Re: Intel graphics CPU usage - SDVO detect bogosity?
Date: Mon, 16 Aug 2010 14:29:16 +1000 [thread overview]
Message-ID: <1281932956.3530.3.camel@clockmaker-el6> (raw)
In-Reply-To: <AANLkTim0RbgfJjb+Wn_LiK9suBTC-kmi9SiZskRpYy0T@mail.gmail.com>
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.
next prev parent reply other threads:[~2010-08-16 4:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-16 2:32 Intel graphics CPU usage - SDVO detect bogosity? Linus Torvalds
2010-08-16 2:51 ` Markus Trippelsdorf
2010-08-16 3:30 ` Dave Airlie
2010-08-16 4:01 ` Linus Torvalds
2010-08-16 4:29 ` Dave Airlie [this message]
2010-08-16 4:06 ` Andy Lutomirski
2010-08-16 4:27 ` Linus Torvalds
2010-08-16 14:27 ` Andy Lutomirski
2010-08-16 15:13 ` [Intel-gfx] " Adam Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1281932956.3530.3.camel@clockmaker-el6 \
--to=airlied@redhat.com \
--cc=airlied@linux.ie \
--cc=ajax@redhat.com \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=yakui.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox