From: Jani Nikula <jani.nikula@linux.intel.com>
To: Marco Nenciarini <mnencia@kcore.it>, Jakub Bystron <jb@elitecode.cz>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
Aaron Esau <aaron1esau@gmail.com>,
Imre Deak <imre.deak@intel.com>,
Mika Kahola <mika.kahola@intel.com>
Subject: Re: [BUG] xe: Meteor Lake 7d55 eDP PHY A/DPLL state mismatch, flip_done timeout
Date: Thu, 21 May 2026 22:26:03 +0300 [thread overview]
Message-ID: <fd9fb7205ddce152b54d9dbfe10606cc2289f412@intel.com> (raw)
In-Reply-To: <ag9HiZKGsQcBRBot@spark.kcore.it>
On Thu, 21 May 2026, Marco Nenciarini <mnencia@kcore.it> wrote:
> Cross-reference: Aaron Esau (Cc'd) posted a 3-patch series targeting
> this on intel-gfx@ on 2026-05-09 [1]. The series received pushback
> from Imre, Jani N, and Mika arguing for catching the failure pre-commit
> so the atomic_commit can fail cleanly at check time rather than
> mid-commit. The series is currently stalled. With Jakub's report,
> Aaron's report, and mine, the bug reproduces on at least three
> independent setups across i915 and xe, ARL-H and MTL, with and without
> an active NVIDIA driver.
>
> On the NVIDIA framing: Aaron's cover letter attributed the MSGBUS
> unresponsiveness to the NVIDIA dGPU not participating in S0ix
> (NVreg_EnableS0ixPowerManagement). That framing has two cracks. My
> reproduction has S0ix participation enabled AND NVIDIA runtime PM
> fully disabled (NVreg_DynamicPowerManagement=0x00, dGPU stays in D0
> since boot, never enters D3), yet the bug still fires. Jakub's setup
> has xe forcing the iGPU and no active NVIDIA driver in dmesg. So
> whatever platform-side condition causes the PHY to wedge, the NVIDIA
> module parameters are not the lever, and the bug occurs without an
> active NVIDIA driver. The fix has to be on the i915/xe side.
Looks like Jakub sent the same message twice. I replied to the other one
[1], with references to existing gitlab issues.
I'll reiterate that 1) any combo with an out-of-tree module loaded gets
no priority, 2) MTL/ARL with the xe driver doesn't get much priority,
and 3) the proposed series from Aaron is not viable.
That said, it does look like a regression with MTL/ARL and the i915
driver and without out-of-tree modules loaded, and we're looking into
it.
BR,
Jani.
[1] https://lore.kernel.org/r/fb38414a888f689b96135f65706c2125059e53ca@intel.com
--
Jani Nikula, Intel
prev parent reply other threads:[~2026-05-21 19:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <TDn3cEkpVu-dBI63qMzn4sYGIkclsctG5pYDF70-dxuekRCixI_FpRQmeJL6UjZH_MtI8PBkjEsJxc93SEV9OmQvlT_CCrD2-qDb8Ss8X-Q=@elitecode.cz>
2026-05-21 17:57 ` [BUG] xe: Meteor Lake 7d55 eDP PHY A/DPLL state mismatch, flip_done timeout Marco Nenciarini
2026-05-21 19:26 ` Jani Nikula [this message]
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=fd9fb7205ddce152b54d9dbfe10606cc2289f412@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=aaron1esau@gmail.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jb@elitecode.cz \
--cc=mika.kahola@intel.com \
--cc=mnencia@kcore.it \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox