summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorVille Syrjälä <ville.syrjala@linux.intel.com>2022-08-18 22:22:23 +0300
committerVille Syrjälä <ville.syrjala@linux.intel.com>2022-09-02 17:23:46 +0300
commitd3a7051841f0a4bcb1ee26a1b721c6150cc4c2b1 (patch)
tree679d0c9bbd093d1a838fa66e7e5cd6a44562969a /tools/perf/scripts/python/stackcollapse.py
parent4e78d6023c15c6acce8fbe42e13027c460395522 (diff)
drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers
The current scheme for generating the LFP data table pointers (when the block including them is missing from the VBT) expects the 0xffff sequence to only appear in the fp_timing terminator entries. However some VBTs also have extra 0xffff sequences elsewhere in the LFP data. When looking for the terminators we may end up finding those extra sequeneces insted, which means we deduce the wrong size for the fp_timing table. The code then notices the inconsistent looking values and gives up on the generated data table pointers, preventing us from parsing the LFP data table entirely. Let's give up on the "search for the terminators" approach and instead just hardcode the expected size for the fp_timing table. We have enough sanity checks in place to make sure we shouldn't end up parsing total garbage even if that size should change in the future (although that seems unlikely as the fp_timing and dvo_timing tables have been declared obsolete as of VBT version 229). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6592 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions