From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6A77310F2B9 for ; Wed, 15 Jun 2022 06:44:30 +0000 (UTC) From: Jani Nikula To: Ville Syrjala , igt-dev@lists.freedesktop.org In-Reply-To: <20220614233100.13834-1-ville.syrjala@linux.intel.com> References: <20220614233100.13834-1-ville.syrjala@linux.intel.com> Date: Wed, 15 Jun 2022 09:44:26 +0300 Message-ID: <87edzqxw6t.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [igt-dev] [PATCH i-g-t 00/23] tools/intel_vbt_decode: Improve the parser List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Latvala, Petri" Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" List-ID: On Wed, 15 Jun 2022, Ville Syrjala wrote: > From: Ville Syrj=C3=A4l=C3=A4 > > Change the igt VBT parser to make copies of the BDB data blocks > (just as we do in the kernel parser now). This makes it less > hazardous/confusing if your block definition don't happent to > match reality.=20 > > Eg. with the current scheme we could very easily misinterpret > random bits from other blocks/etc. as our block data by just > using an overly large structure for decoding. With the block > copies being at least as big as out struct definitions the > worst that can happen is that we just decode some extra zeroes > rather than some random other bits. > > The other thing I'm bringing over is the data pointer generation > stuff for modern VBTS (which lack the LFP data table pointes block). > That lets us keep decoding the LFP data block in exactly the > same way on old and new VBTs. > > And naturally we have massive gaps in what data the tool actually > parses from the VBT. So lots of patches to just parse more stuff. > I didn't do an exhaustive study on this topic, so still probably > missing some useful things. I glanced through all this, and it LGTM, but can't claim I did a detailed, thorough review. I also don't think it should really be necessary for this particular tool. If the changes work for you, it's good enough for me. Cc: Petri, good to go with that? BR, Jani. > > Ville Syrj=C3=A4l=C3=A4 (23): > tools/intel_vbt_decode: update vbt defs from kernel > tools/intel_vbt_decode: Decode more DVO ports > tools/intel_vbt_decode: Decode mode HDMI data rates > tools/intel_vbt_decode: Clean up SSC freq decoding > tools/intel_vbt_decode: Decode DP max link rate > tools/intel_vbt_decode: Unify panel type handling > tools/intel_vbt_decode: Dump the block size > tools/intel_vbt_decode: Decode the LFP power block > tools/intel_vbt_decode: Dump the LVDS panel options > tools/intel_vbt_decode: Decode new fast link training rate > tools/intel_vbt_decode: Parse the old fast link training rate > correctly > tools/intel_vbt_decode: Parse the new eDP max link rate > tools/intel_vbt_decode: Include BDB block header in hex dump > tools/intel_vbt_decode: Make copies of the BDB blocks > tools/intel_vbt_decode: Specify a minimum size for the BDB block copy > tools/intel_vbt_decode: Convert LFP data pointers to be relative to > the data block > tools/intel_vbt_decode: Simplify LVDS data block parsing > tools/intel_vbt_decode: Dump the panel PNP ID > tools/intel_vbt_decode: Decode the end of the LFP data > tools/intel_vbt_decode: Dump the LVDS data ptrs > tools/intel_vbt_decode: Validate LVDS data table pointers > tools/intel_vbt_decode: Generate LVDS data table pointes if not > provided > tools/intel_vbt_decode: Warn if we lack the full definiton of the BDB > block > > tools/intel_vbt_decode.c | 919 ++++++++++++++++++++++++++++++++++----- > tools/intel_vbt_defs.h | 254 ++++++++--- > 2 files changed, 1018 insertions(+), 155 deletions(-) --=20 Jani Nikula, Intel Open Source Graphics Center