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
