Repository navigation
clk: mediatek: mt6589: msdcpll_208m is msdcpll / 2, not / 8 - #89
Merged
Merged
Conversation
The MSDC source tap of MSDCPLL is the VCO divided by 8, taken before the /4 post divider. "msdcpll" (390 MHz here) already includes that post divider, so the tap is msdcpll / 2 (195 MHz), not msdcpll / 8 (48.75 MHz). With 1/8 the clock framework believed every MSDC source ran at a quarter of its real rate, so mtk-sd chose dividers that ran each bus about four times faster than requested. The eMMC asked for 24 MHz ran at about 97 MHz. That explains the data CRC errors on the eMMC and on the SDIO bus of the MT6628. Tested on the Lenovo B8000-H (MT8389). The clock summary before the change showed msdcpll at 390000000 and msdcpll_208m at 48750000. Since 27 Sep 2026 our kernels have carried this change, with the eMMC root and the MT6628 Wi-Fi on MSDC3 (SDIO) in daily use. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Mikhail Nevskiy <trudenboy0@gmail.com>
This was referenced Oct 28, 2026
Member
Root cause was fixed in dev branch (with bug factor refactor) |
Member
|
fix: 85c8f8f fix other divs based on it for now |
based on 85c8f8f Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
msdcpll_208misFACTOR(..., "msdcpll", 1, 8)in this tree. The MSDC source tap of MSDCPLL is the VCO divided by 8, taken before the /4 post divider.msdcpllalready includes that post divider (390 MHz here), so the tap ismsdcpll / 2= 195 MHz, notmsdcpll / 8= 48.75 MHz.With 1/8 the clock framework believes every MSDC source runs at a quarter of its real rate. mtk-sd then picks dividers that run each bus about 4x faster than requested. On our tablet the eMMC asked for 24 MHz ran at about 97 MHz. That explained our eMMC and SDIO data CRC errors, and it may be the 200 MHz MSDC instability you mentioned. The clock summary before the change (
msdcpll 390000000,msdcpll_208m 48750000) is indocs/msdc-live-regs-2026-09-27.txt.This assumes the /4 post divider that LK programs and the kernel does not change; with another post divider the factor would differ. The name
208mcomes from a 1664 MHz VCO (VCO/8 = 208 MHz); LK runs the VCO at 1560 MHz, hence 195 MHz.Only the clock is changed here. The MSDC3 SDIO pins and supply for the MT6628 belong with the B8000-H MT6628 nodes, once the binding is in this branch.
Tested: Lenovo B8000-H (MT8389). Our kernels have carried this since 27 Sep 2026, with the eMMC root and the MT6628 Wi-Fi on MSDC3 in daily use. Rebased from our tree (blade/v7.1 @ 7dd2454 + our patches) and build-tested on current blade/v7.1; not yet booted on this base. You planned to test it at 200 MHz yourself; that is the check I can't do here, since our eMMC runs at 50 MHz and our SDIO at 25 MHz.
Assisted-by: Claude:claude-opus-5-5