From: Paz Zcharya <pazz@chromium.org>
To: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: intel-gfx@lists.freedesktop.org, jani.saarinen@intel.com,
ville.syrjala@linux.intel.com
Subject: Re: [PATCH 2/2] drm/i915: Implement vblank synchronized MBUS join changes
Date: Tue, 5 Mar 2024 19:54:24 +0000 [thread overview]
Message-ID: <Zed4cL-bvHEuIgs7@google.com> (raw)
In-Reply-To: <20240228080213.17441-3-stanislav.lisovskiy@intel.com>
On Wed, Feb 28, 2024 at 10:02:13AM +0200, Stanislav Lisovskiy wrote:
> Currently we can't change MBUS join status without doing a modeset,
> because we are lacking mechanism to synchronize those with vblank.
> However then this means that we can't do a fastset, if there is a need
> to change MBUS join state. Fix that by implementing such change.
> We already call correspondent check and update at pre_plane dbuf update,
> so the only thing left is to have a non-modeset version of that.
> If active pipes stay the same then fastset is possible and only MBUS
> join state/ddb allocation updates would be committed.
>
> v2: Implement additional changes according to BSpec.
> Vblank wait is needed after MBus/Dbuf programming in case if
> no modeset is done and we are switching from single to multiple
> displays, i.e mbus join state switches from "joined" to "non-joined"
> state. Otherwise vblank wait is not needed according to spec.
>
> v3: Split mbus and dbox programming into to pre/post plane update parts,
> how it should be done according to BSpec.
>
> v4: - Place "single display to multiple displays scenario" MBUS/DBOX programming
> after DDB reallocation, but before crtc enabling(that is where is has
> to be according to spec).
> - Check if crtc is still active, not only the old state.
> - Do a vblank wait if MBUX DBOX register was modified.
> - And of course do vblank wait only if crtc was active.
> - Do vblank wait only if we are not doing a modeset, if we are doing
> something before *commit_modeset_enables, because all crtcs might be
> disabled at this moment, so we will get WARN if try waiting for vblank
> then.
> - Still getting FIFO underrun so try waiting for vblank in pre_plane update
> as well.
> - Write also pipe that we need to sync with to MBUS_CTL register.
>
> v5: - Do vblank wait only for the first pipe, if mbus is joined
> - Check also if new/old_dbuf_state is not NULL, before getting single pipe
> and active pipes.
>
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Thank you for this patch, Stanislav!
We tested it on a MTL-U based Chromebook (Screebo),
using different configurations (eDP, eDP + HDMI, HDMI, etc.), and
it worked well -- joined the mbus + no visual issues or i915 errors.
Tested-by: Paz Zcharya <pazz@chromium.org>
Just a small note, checkpatch.pl is complaining about a few things.
I assume you probably saw it, but flagging just in case.
next prev parent reply other threads:[~2024-03-05 19:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 8:02 [PATCH 0/2] Enable fastset for mbus_join state change Stanislav Lisovskiy
2024-02-28 8:02 ` [PATCH 1/2] drm/i915: Update mbus in intel_dbuf_mbus_update and do it properly Stanislav Lisovskiy
2024-03-05 19:52 ` Paz Zcharya
2024-02-28 8:02 ` [PATCH 2/2] drm/i915: Implement vblank synchronized MBUS join changes Stanislav Lisovskiy
2024-03-05 19:54 ` Paz Zcharya [this message]
2024-03-08 10:07 ` Ville Syrjälä
2024-03-08 13:43 ` Lisovskiy, Stanislav
2024-03-08 15:11 ` Ville Syrjälä
2024-03-11 9:41 ` Lisovskiy, Stanislav
2024-02-28 8:45 ` ✗ Fi.CI.CHECKPATCH: warning for Enable fastset for mbus_join state change Patchwork
2024-02-28 8:56 ` ✓ Fi.CI.BAT: success " Patchwork
2024-02-28 23:21 ` ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zed4cL-bvHEuIgs7@google.com \
--to=pazz@chromium.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.saarinen@intel.com \
--cc=stanislav.lisovskiy@intel.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.