[Intel-gfx] Responsiveness Changes to i915 Driver

[Wilde, Martin]

Greetings,

Given the great ideas by Jani and Chris, I will not be requiring any
changes to the i915 driver.

I will use the /sys/module/drm/parameters/debug file to set a value of 14
as Jani indicates below. I have a python script to analyze the dmesg
output.

Thanks everyone for your excellent advice and guidance

Regards,

-martin



On 8/21/14, 12:26 AM, "Jani Nikula" <jani.nikula at linux.intel.com> wrote:

>On Wed, 20 Aug 2014, "Wilde, Martin" <martin.wilde at intel.com> 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
>
>Look, the exact same things could be said about almost all of the debug
>messages we have. One VBT value will not get special treatment, sorry.
>
>Are you aware that you can enable the debug messages by changing the
>value of the drm.debug module parameter? There's no need for special
>kernel builds or anything of the sort. Just add drm.debug=14 (it's a bit
>mask) to the kernel command line, or in the modprobe conf, or change it
>runtime at /sys/module/drm/parameters/debug. Make sure you also have
>high enough loglevel set.
>
>The debugfs has /sys/kernel/debug/dri/0/i915_opregion which includes the
>VBT. It's binary, but the intel-gpu-tools package has userspace tools
>(intel_bios_reader) to interpret the VBT contents and print them out. If
>it doesn't print the values you want, it's relatively easy to
>modify. The hardest part is likely conforming to the quirks of the VBT
>specification version changes.
>
>Indeed I think more effort should be put into validating the VBT
>contents in other ways than by the operating system, in advance, perhaps
>by the very tools that produce the VBT.
>
>Finally, if none of the above works for you, I'd go the route Chris
>suggested.
>
>
>Thanks,
>Jani.
>
>
>-- 
>Jani Nikula, Intel Open Source Technology Center