A64-uQ7 support and more reliable clock-setup #2
Conversation
This file contains 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
added 3 commits
February 2, 2017 23:49
Increasing the operating clocks may increase the current draw (or require a higher voltage for certain voltage rails). To ensure that we never run into a problem in this area, the initialisation sequence is reordered to first perform the PMIC setup and then reprogram the clocking. X-AffectedPlatforms: A64-uQ7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Initialisation of clocks on Allwinner's CPUs has always been a bit tricky and should follow the following guidance: 1. Bus clock dividers should be adjusted first to keep the bus clocks within their operating limits for both the new frequency _before_ changing the PLL (compare to section 3.3.6.2. in the A64 User's Guide v1.0). 2. PLLs should first be setup (with the enable-bit cleared), then be enabled and finally polled for the stable-bit to indicate the a PLL lock (compare how boot0 and Allwinner's linux releases have been changing PLLs for the A31 and subsequent chips). 3. Additionally Allwinner always injects extra delays after the PLL lock has triggered and after the clock source is changed. Without these changes, the A64 will not reliably come up beyond the clock initialisation w/ the recurrence of failure differing between individual parts (i.e. seemingly process-dependent). Note, that these changes and the observed failures are in line with our experience on the A31 and A80. X-AffectedPlatforms: A64-uQ7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
For the A64-uQ7 we should set up DCDC5 (DDR) to 1.36V and DCDC4 to 1.2V (for the Micrel GbE PHY). Note that a higher DCDC5 setting (i.e. 1.5V) will also work safely, but we expect a power-saving under high system load from using the lower DDR3L voltage supported by our RAM. Per my discussion with Andre, board-specific power initialisation should eventually be conditionalised on the FDT, as seen by the ATF. However, this will require the ATF to be rebased to a more current ATF source bae first. X-AffectedPlatforms: A64-uQ7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
apritzel
reviewed
Feb 2, 2017
There was a problem hiding this comment.
Is DCDC4 on per default on your board? The manual isn't clear about the reset state.
Also do you connect the DC5SET correctly (to VINT) on your board? In this case we should not need to actually program DCDC5. I do this just because the Pine64 got this obviously wrong (floating=1.24V instead of 1.36V). I changed my branch already to only correct from 1.24V to 1.36V to cover this case, which should work on any board (except for those using LPDDR3).
Also please add a comments about the DCDC4 enabling.
And please understand that I can't merge this before we can somehow detect boards.
Thanks! Andre
apritzel
reviewed
Feb 3, 2017
There was a problem hiding this comment.
That looks pretty good, but I need to digest the details first and merge it with my changes I made meanwhile.
Do you have an idea why we actually need to change the CPU clock source to LOSC for the change? This PLL should be able to do this while being live, right? At least this is my understanding of "supports dynamic frequency scaling" from the manual.
Thanks,
Andre.
|
Andre,
You may be right that we may not always have to switch away for PLL_CPUX and PLL_DDR1, as the manual states:
1) In practical application, other PLLs doesn’t support dynamic frequency scaling except for PLL_CPUX and PLL_DDR1;
I would nonetheless expect some level of instability on the PLL’s output that could glitch dependent clocks.
It’s not uncommon to support DVFS with a requirement to reparent during the transition time (for example, see drivers/cpufreq/imx6q-cpufreq.c for how it’s done on the i.MX6 which also supports DVFS).
The code in the linux-3.4 and -3.10 drops received with the A64 release doesn’t explicitly do this either, but boot0 still does.
As we don’t see the actual code that’s used in ARISC (we could disassemble and work our way through it, but it doesn’t appear worth it), I don’t know what Allwinner does on their end.
Given that there’s a difference between the PLL_CPUX and PLL_DDRx in that the PLL_DDRx have the PLL_DDR0_CFG_UPDATE/SDRPLL_UPD bits, I’d rather go with the conservative method of reparenting twice.
I’d vote to optimise later, but start with what we know is safe.
Cheers,
Phil.
… On 03 Feb 2017, at 01:02, Andre Przywara ***@***.***> wrote:
@apritzel commented on this pull request.
That looks pretty good, but I need to digest the details first and merge it with my changes I made meanwhile.
Do you have an idea why we actually need to change the CPU clock source to LOSC for the change? This PLL should be able to do this while being live, right? At least this is my understanding of "supports dynamic frequency scaling" from the manual.
Thanks,
Andre.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#2 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOShnkWYUpQlFAm_n7XDzqhsnsCHwq1tks5rYm6rgaJpZM4L1wet>.
|
|
DC5SET is defaulted to 1.5V as this is supported by both DDR3 and DDR3L.
We plan to update this to 1.36V whenever DDR3L is used (the default at the moment), based on the FDT contents.
As I mentioned, the changes to sunxi_power.c really need the FDT support to land before making sense...
… On 03 Feb 2017, at 00:58, Andre Przywara ***@***.***> wrote:
@apritzel commented on this pull request.
Is DCDC4 on per default on your board? The manual isn't clear about the reset state.
Also do you connect the DC5SET correctly (to VINT) on your board? In this case we should not need to actually program DCDC5. I do this just because the Pine64 got this obviously wrong (floating=1.24V instead of 1.36V). I changed my branch already to only correct from 1.24V to 1.36V to cover this case, which should work on any board (except for those using LPDDR3).
Also please add a comments about the DCDC4 enabling.
And please understand that I can't merge this before we can somehow detect boards.
Thanks! Andre
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#2 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOShngp0E7LD9NifUlQY8FTp9gVxg5Ggks5rYm2YgaJpZM4L1wet>.
|
|
I merged the first two patches, while doing some cosmetic changes and dropping the (broken) CPU frequency print. |
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.
Andre,
Here's the changes we have in our tree for the A64-uQ7 (Lynx).
Note that the changes to the init-sequence and clocking significantly improve the reliability of the boot process.
Cheers,
Philipp.