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@xxxxxxxxxxxxxxx> wrote: >On Wed, 20 Aug 2014, "Wilde, Martin" <martin.wilde@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
