From: Chris Wilson <chris@chris-wilson.co.uk>
To: "Wilde, Martin" <martin.wilde@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: Responsiveness Changes to i915 Driver
Date: Wed, 20 Aug 2014 19:12:49 +0100 [thread overview]
Message-ID: <20140820181249.GJ12830@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <D01A2DBE.3DC72%martin.wilde@intel.com>
On Wed, Aug 20, 2014 at 06:03:52PM +0000, Wilde, Martin wrote:
> Hi Jani - the DRM_DEBUG_KMS is part of the DRM_DEBUG_CODE preprocessor
> macro and thus not available unavailable in a non-debug build kernel from
> my understanding.
>
> The issue we have seen many times is that the BIOS (firmware) team does
> not set the T3 value correctly in the VBT table of the BIOS (or they use
> the VESA default of 200ms and the panel is really a 50ms panel) and thus
> there is no way to quickly determine what value was set unless you build a
> debug kernel version that is typically beyond the scope of the BIOS team
> (we have also had problems tracking down who in the BIOS team made the
> setting). For example in the latest Coreboot firmware for Rambi
> Chromebook, someone set the VBT T3 value to 500 instead of 200. This was
> not detected until I ran the S3 resume test and noticed the S3 resume time
> was 300ms too long. Having the INFO message available in dmesg output
> allowed me to quickly see the value was set wrong and address it without
> having to do a debug build or do debugging to find the issue. Additionally
> having the INFO message can be used by the firmware team to verify their
> setting is correct. We are also asking the Windows Gfx driver to do the
> same as it happens more frequently than we thought. Until we have fully
> implemented HDP detection in the drivers, this issue will continue
> happening.
>
> So the request is to expose this as an INFO message to allow quick
> detection/verification of correct setting as VBT settings can be set
> in-correctly in a firmware update and not easily detected without special
> kernel builds. This allows the QA team to track platform settings that
> effect the responsive time of mobile platforms.
>
> Let me know if you have further questions and thanks for feedback
I would suggest a /debugfs/.../i915_panel_capabilities and/or
i915_vbt_capabilites.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2014-08-20 18:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-14 23:52 Responsiveness Changes to i915 Driver Wilde, Martin
2014-08-15 6:26 ` Chris Wilson
2014-08-19 21:33 ` Wilde, Martin
2014-08-20 9:36 ` Jani Nikula
2014-08-20 18:03 ` Wilde, Martin
2014-08-20 18:12 ` Chris Wilson [this message]
2014-08-21 7:26 ` Jani Nikula
2014-08-27 20:33 ` Wilde, Martin
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=20140820181249.GJ12830@nuc-i3427.alporthouse.com \
--to=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=martin.wilde@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.