Skip to content

fix MMCM parameter discovery - #210

Merged
quetric merged 1 commit into
devfrom
206-not-able-to-set-the-frequency-properly-via-devicesetfrequencyfreq
Sep 1, 2026
Merged

fix MMCM parameter discovery#210
quetric merged 1 commit into
devfrom
206-not-able-to-set-the-frequency-properly-via-devicesetfrequencyfreq

Conversation

@quetric

@quetric quetric commented Sep 1, 2026

Copy link
Copy Markdown
Collaborator

Improve MMCM parameter read-back and setting. More verbose logging of MMCM related activity in VRTD. Fixed #206

@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown

Coverage

component covered total vs dev
linker 1540 3863 39.9% no change
vrt 10889 14340 75.9% no change
vrtd 1513 4521 33.5% +0.4 pts

Lines covered at a1157f9, compared with the most recent successful dev run. Full HTML reports are attached to the test runs as artifacts.

@quetric
quetric merged commit e6a014b into dev Sep 1, 2026
3 checks passed
@quetric
quetric deleted the 206-not-able-to-set-the-frequency-properly-via-devicesetfrequencyfreq branch September 1, 2026 15:11
quetric added a commit that referenced this pull request Sep 2, 2026
clock_driver_wait_for_lock() read the lock bit from offset 0x33C, which
is not the status register. 0x33C is the second word of the CLKOUT0 leaf
register pair, holding the high-time count in both of its low bytes, so
the predicate tested bit 0 of the output divider's high-time count
rather than PLL lock. The status register is at offset 0x04 and reports
lock in bit 0, as the upstream Linux clocking wizard driver does.

The consequence was that candidate selection rejected any (M, D, O)
tuple whose high-time count was even, after stalling for the full
200 ms lock timeout. For a 365 MHz request this discarded the
best-ranked candidate and settled on one producing a different VCO
frequency; for requests where every candidate has an even high-time
count it failed outright. Requests that happened to work, such as
200 MHz, did so only because the first candidate had an odd count.

Read the status register instead, both when waiting for lock and when
dumping wizard state for diagnostics. The state dump also carried its
own copy of the leaf offset computation that still had the off-by-three
error corrected in #210; call the shared helper.

Fixes #206
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