Skip to content

hw: wait for S2 PLL lock and propagate initialization errors - #340

Open
vrilutza wants to merge 2 commits into
patjak:masterfrom
vrilutza:pll-lock-check
Open

vrilutza wants to merge 2 commits into
patjak:masterfrom
vrilutza:pll-lock-check

Conversation

@vrilutza

@vrilutza vrilutza commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

The S2 PLL polling loop continues while S2_PLL_CMU_STATUS_LOCKED is set, although that bit means the PLL has locked. It can therefore report failure for a locked PLL and success before lock, with different paths into the later DDR setup.

The first commit polls while the bit is clear, keeping the existing retry limit and error return. The second propagates initialization errors through both callers: PLL initialization to DDR setup, then DDR setup to fthd_hw_init(). Initialization stops before DDR verification and ISP setup if the prerequisite fails.

The additional correction in this revision is the check in fthd_hw_init(). The earlier PR propagated the PLL error only as far as the DDR function, whose caller still discarded it. Checking only that first return value does not stop probe from continuing.

An extracted-function regression with stubbed hardware verifies that a DDR initialization failure stops the outer initialization path. This is a simulated error-path test, not an injected PLL failure on the physical camera. The revised combined driver has also captured successfully on MacBookPro14,1.

This fixes the inverted condition and ignored return values. It does not establish that the separate machine hangs during module reload or PCI reset are resolved; the earlier investigation did not establish that either.

Validation scope: this individual rebased branch builds against Linux 7.1.13+deb14-amd64 with W=1; the two existing compiler warnings remain. The complete nine-topic series previously passed 57/57 streaming-inclusive v4l2-compliance checks on MacBookPro14,1. Its final source tree is unchanged by the commit-message rewrite. The combined hardware tests are not nine separate hardware certifications, and no new module reload or hardware test was performed for this publication.

Revision: f97986919b0735831d80c76512d630d6daac2f3e.

The polling loop continues while the LOCKED bit is set, although the
register definition says that a set bit means the PLL has locked. It can
therefore time out on a locked PLL or report success before lock.

Continue polling while the bit is clear. A successful lock reaches the
existing bypass setup, while exhausting the retry limit returns the
existing error. This corrects the condition; it does not establish that
the separate machine hangs during module reload are resolved.

Based-on: patjak#340
DDR setup ignores the PLL initialization result, and fthd_hw_init()
ignores the DDR setup result in turn. An initialization failure can
therefore be followed by further DDR programming and memory access.

Return a PLL failure from DDR setup and propagate a DDR failure through
fthd_hw_init() before memory verification or ISP initialization. Both
callers must check the result for the failure to reach probe.

Successful initialization follows the existing path. A failed clock or
DDR setup now prevents the driver from continuing as if it succeeded.

Based-on: patjak#340
@vrilutza vrilutza changed the title hw: the S2 PLL lock check waits for the wrong condition hw: wait for S2 PLL lock and propagate initialization errors Sep 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant