drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Thu, 18 Aug 2022 19:22:23 +0000 (22:22 +0300)
committerVille Syrjälä <ville.syrjala@linux.intel.com>
Fri, 2 Sep 2022 14:23:46 +0000 (17:23 +0300)
commitd3a7051841f0a4bcb1ee26a1b721c6150cc4c2b1
tree679d0c9bbd093d1a838fa66e7e5cd6a44562969a
parent4e78d6023c15c6acce8fbe42e13027c460395522
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>
drivers/gpu/drm/i915/display/intel_bios.c