Tegra124 CL-DVFS / DFLL clocksource + cpufreq
Get series with b4
b4 am 20150414210938.19585.25150@quantumVersions newest first · linked by author and title
- v8 Latest posting 2/20 of 18 patches 0 repliesNew
- v8 posting 1/21 of 18 patches 7 repliesSuperseded
Patches in v8 posting 2/2 No applies recorded yet
None of the 18 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v8 yet.
Cover letter [PATCH v8 00/18] Tegra124 CL-DVFS / DFLL clocksource + cpufreq
Quoting Thierry Reding (2015-04-14 07:43:41)
Quoted 22 lines · Michael Turquette
Quoted 21 lines
Quoting Thierry Reding (2015-03-11 03:07:43)
Quoted 7 lines
Hi Mike,
Have you had a chance to look at these changes to the Tegra clock driver? If you're fine with it, I'd like to take these patches through the Tegra tree because the rest of the series depends on them. I can provide a stable branch in case we need to base other Tegra clock changes on top of this.
Hi Thierry,
Clock patches (and corresponding DT binding descriptions and changes to DTS) look fine to me. Please add:
I did have a question about the beahvior of
clk_putin one of Mikko's patches but it should not gate this series. I'm just trying to find out if we have a bug in the framework or if the Tegra driver is a special case.
Quoted 8 lines
Quoted 1 line
Also I do not think a stable branch is necessary.
Given how this didn't work at all for v4.1, why don't we try to do this the conventional way for v4.2? What I propose is that I collect all the patches that I've had in these branches into a single branch that I can send you shortly after v4.1-rc1. Then you can pull that into the clock tree when you're happy and I can pull that into the Tegra tree again if needed to resolve dependencies.
Sounds fine, so long as you do not rebase your branch.
Quoted 9 lines
One problem that I foresee is that the EMC clock driver relies on some symbols exported by the EMC driver, so it will fail to build on its own if merged into the clock tree. Usually I'd say we can solve this by merging a stable branch from the Tegra tree into the clock tree, but if any of the ARM SoC maintainers then decides that, for whatever reason, the Tegra pull request isn't good enough, you'd need to either redo the clock tree or we slip in the changes via the clock tree anyway.
Quoted 6 lines
Perhaps a solution would be to implement stubs for the API exposed by the EMC driver and merge that through the clock tree, which should give us a tree that can be built but be a no-op at runtime. Then we can add the actual code to enable EMC scaling in the Tegra tree by providing a real implementation. That way we only have the Tegra tree depend on the clock tree.
That sounds OK, but it does create some extra work for you. Alternatively you can just take these patches through your tegra tree into arm-soc with my Ack (which is the reason I gave it out in the first place).
However if you have other clock patches which conflict then having the stable branch makes good sense. The choice is yours since it will be an extra burden on your to stub things out.
Regards,
Mike
Quoted 4 lines
How does that sound?
Thierry