From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C9467EC0463 for ; Tue, 3 Mar 2026 09:44:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5945810E16A; Tue, 3 Mar 2026 09:44:42 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="adkkWctP"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9010C10E16A; Tue, 3 Mar 2026 09:44:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772531081; x=1804067081; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=ENM68047xPDieAI2ZYo9VTtRyFyahU4meJlMgy8he5c=; b=adkkWctPDEEPtsgzSnUsVRETCQY7jynT8pxJWTzhAUbVG0tTkktFA5Iz +oE9WuIxpAJarvGJV88k19gVO4lCJcEamFcNd05lFg8F7N1MXn1VGRIE/ LNULwvA4V4LHwB4GWx0GQM8ZdEpMZYps/AbFZT+Wdt5Ei+v8eI6wawQk1 s548it9FL4G8v7UNi5DczkXb8VtnODprlTBSLalKR9zKq/vfrPbqk0I6n 9EQT0ym6VCFI5vfPIKZPyzxBM2gaW8EwI3S7D+1NsEaQafQvQMWFpPjiA M/ouaxwy367jcf+gPUhtYnjhKfX39XXd6F1loqrRTi8xiYGWZRJEWv59s A==; X-CSE-ConnectionGUID: 8axJxt/aQhC26Q2SkQki1Q== X-CSE-MsgGUID: L3Zb/rz+Q2WsQ5RBxkp/2Q== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="73624654" X-IronPort-AV: E=Sophos;i="6.21,321,1763452800"; d="scan'208";a="73624654" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 01:44:39 -0800 X-CSE-ConnectionGUID: PQ4SssOcQEedhZosiRP2uw== X-CSE-MsgGUID: xJzCfTENQr6EqtosnOhFQA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,321,1763452800"; d="scan'208";a="217930880" Received: from klitkey1-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.246.21]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 01:44:35 -0800 From: Jani Nikula To: Manasi Navare Cc: Juasheem Sultan , intel-gfx@lists.freedesktop.org, intel_xe@lists.freedesktop.org, Rodrigo Vivi , Drew Davenport , Sean Paul , Samuel Jacob , Rajat Jain , ville.syrjala@linux.intel.com Subject: Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland References: <20260121204705.432290-1-jdsultan@google.com> <20260121204705.432290-3-jdsultan@google.com> <19ddb0a9aa900c51759cfa62b66bcbf079c4dde8@intel.com> Date: Tue, 03 Mar 2026 11:44:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, 02 Mar 2026, Manasi Navare wrote: > Hi @Jani Nikula : > > Before we file a fdo issue with complete debug logs to understand what the > FW is setting up the HW at, I wanted to understand a few more things in > terms of the final solution: > > - Ideally if the FW is setting up the initial state or programming the HW > registers for the initial splashscreen, for the initial commit when we do > the HW state readout, it should have the HW values programmed to some mode > parameters > - Then like you suggested, we would need to read out the HW state > - Could you elaborate on "1) reading out the hw state to sw > state? - Does that mean do the HW state readout and compute > pipe_config/crtc_state for that? > > - Then add some sanitization to have this computed pipe_config that will be > programmed to the HW > - Then ensure that both are same so that the intel fastset logic can apply > fastset? Let's start with the regular modesets, ignoring the probe for a bit. For every modeset, we have the old (current) state and the new state. These are both software states. We compare the states to determine whether a full modeset is required or not. This is mostly dependent on what the hardware can change on the fly. If we can bypass a full modeset, we call it a fastset. We write either the full new state (modeset) or just the changes (fastset) to the hardware, and the new state becomes the old (current) state. After that, we read back the hardware state to verify we did everything right. This is the state checker. The comparison is done using the same functions as for determining whether a full modeset is required. Rinse and repeat. At probe, we obviously don't have the old (current) software state. We create it by reading out the hardware state, using the same mechanisms as in the state checker. We call it the inherited state. We do the initial commit with that. Then we arrive at the first userspace/client initiated modeset. It goes through the same paths as the regular modeset. If we can get away with a fastset, we call it fastboot i.e. no full modeset at boot. That's the basic idea, anyway. Now the caveats. Sometimes GOP (or whatever pre-os) ends up using slightly different parameters for the same mode than the driver. Or we might not be able to read out everything. Or we lose accuracy in the sw->hw->sw changes. Or the pre-os enables stuff that it doesn't even use or care about. We wiggle around those issues using sanitization or ignoring small differences or simply bypassing some parts on the first modeset. Obviously, if there are gaps in the state readout in the first place, the inherited state will be incomplete, and likely leads to a full modeset. (And we also miss out on the state verification of those parts.) If the GOP (or pre-os) sets a mode, and the first modeset requests a completely different mode, you can't have fastboot either. The thing we absolutely can't do is what patch 2 here does. We can't simply copy over stuff from one state to another, and hope it works. It might appear to work by coincidence in some cases, but it is all wrong. It ignores the computed modeset parameters for the new state, even if userspace tries a completely different mode. It bypasses the comparison for whether a full modeset is needed or not. It's not discretional, it depends on what the hardware can change on the fly, and it's undocumented at best what happens when you try to change such things without a modeset. You can do a lot of debugging based on just looking at the debug output for the state comparison where we decide a fastset (and in this case fastboot) is not possible. Where does the differing info come from? Is there a readout in place? Is something completely zero in the readout, or are there minor differences? Do you get fastsets on the second and subsequent regular modesets? Etc. Etc. HTH, Jani. -- Jani Nikula, Intel