> -----Original Message----- > From: Cole Leavitt <[email protected]> > Sent: Saturday, February 14, 2026 2:18 PM > To: Murthy, Arun R <[email protected]> > Cc: [email protected]; Kandpal, Suraj <[email protected]>; > Nikula, Jani <[email protected]>; Cole Leavitt <[email protected]> > Subject: Re: [PATCH v2 1/2] drm/i915/cx0_phy_regs: Include SoC and OS > turnaround time > > On Wed, 12 Feb 2026, Arun R Murthy <[email protected]> wrote: > > The port refclk enable timeout and the soc ready timeout value > > mentioned in the spec is the PHY timings and doesn't include the > > turnaround time from the SoC or OS. So add an overhead timeout value > > on top of the recommended timeouts from the PHY spec. > > Hi Arun, > > Thanks for the fix. I wanted to flag that I independently identified this > exact > issue and posted a detailed root cause analysis on the i915 GitLab tracker > five > days before this patch series. > > On February 7, 2026, I filed the analysis on GitLab issue #14713: > > https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14713#note_2739573 > > That comment includes the following findings, which directly correspond to > what this patch addresses: > > 1. Traced the error to intel_cx0_phy_lane_reset() in intel_cx0_phy.c > (line ~2911), where the driver writes the PCLK_REFCLK_REQUEST bit to > XELPDP_PORT_CLOCK_CTL and polls for PCLK_REFCLK_ACK with a timeout > of XELPDP_REFCLK_ENABLE_TIMEOUT_US = 1 (1 us). > > 2. Identified that this calls __intel_wait_for_register() with > fast_timeout_us=1 and slow_timeout_ms=0 -- a single spin-poll with > no slow-path fallback. > > 3. Compared the 1 us refclk timeout against other timeouts in the same > PHY init sequence: > > XELPDP_PORT_BUF_SOC_READY_TIMEOUT_US = 100 us > XELPDP_PORT_RESET_START_TIMEOUT_US = 5 us > XELPDP_PCLK_PLL_ENABLE_TIMEOUT_US = 3200 us > XELPDP_PORT_RESET_END_TIMEOUT_MS = 15 ms > > The 1 us value is an outlier by 1-3 orders of magnitude compared to > every other timeout in the same code path. > > 4. Recommended increasing XELPDP_REFCLK_ENABLE_TIMEOUT_US to ~100 us > or adding a slow-path ms fallback, consistent with how other waits > in the same function are structured. > > This analysis was performed on a Lenovo ThinkPad P16 Gen 3 with an Arrow > Lake-S Core Ultra 9 275HX (device ID 7d67) running kernel 6.19.0-rc8. The PHY > A refclk failure reproduced on every boot at ~8.5s after i915 init, during > the eDP > panel probe path. > > Your patch does the right thing -- increasing the timeout values and adding > SoC/OS overhead. Since my analysis identified the root cause and > recommended the same fix direction, I'd appreciate attribution: > > Reported-by: Cole Leavitt <[email protected]> > Yes, definitely would provide credits to you in this patch.
Thanks and Regards, Arun R Murthy --------------------
