| Message ID | CACRpkdara5D=kvGVYu-WRh_JYK6Z9NKmQ-eniXsauxdzx-QJbA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Hi Linus, On Wed, Nov 09, 2016 at 09:10:35AM +0100, Linus Walleij wrote: > Hi ARM SoC folks, > > this adds DT-based cpufreq to the Integrator family. > > The corresponding cpufreq changes are merged by Rafael to the > cpufreq tree, and can go in orthogonally. > > However I have included the defconfig change turning on the feature > here as it makes all kind of logic sense to have these three patches > in succession: addin the DTS nodes and then turning on the DT > cpufreq. > > If you insist, of course I can send the defconfig patch separately. > I just think it makes more sense like this. > > Please pull it in so we get some rotation in linux-next for this! Hmm. I understand that it makes sense for your platform do turn on the option at the same time as adding the DT entries, but there's nothing that should require them to go in together (they just won't be used until both branches are in). We try to keep our categories of patches separate in the arm-soc tree; keeping SoC changes, driver changes, DT changes and defconfig changes is from a general code hygiene point of view beneficial and we encourage all platform maintainers to follow those guidelines. I also sympathize that it's extra annoying having to split just three patches across two branches. So, if it's easier we can just cherry-pick apart the patches here across the branches (your comment about next coverage makes me suspect you have no direct downstream users of this branch). If that's OK, let me know and I'll do that tomorrow. Cheers, -Olof
On Fri, Nov 18, 2016 at 8:25 AM, Olof Johansson <olof@lixom.net> wrote: > I also sympathize that it's extra annoying having to split just three > patches across two branches. So, if it's easier we can just cherry-pick > apart the patches here across the branches (your comment about next > coverage makes me suspect you have no direct downstream users of this > branch). If that's OK, let me know and I'll do that tomorrow. It's fine to cherry-pick, I can also send two separate branches (or just 2+1 stand-alone patches). Any way you like it :) just tell me what to do, all I want is to get this in for v4.10. Yours, Linus Walleij
On Fri, Nov 18, 2016 at 09:26:56AM +0100, Linus Walleij wrote: > On Fri, Nov 18, 2016 at 8:25 AM, Olof Johansson <olof@lixom.net> wrote: > > > I also sympathize that it's extra annoying having to split just three > > patches across two branches. So, if it's easier we can just cherry-pick > > apart the patches here across the branches (your comment about next > > coverage makes me suspect you have no direct downstream users of this > > branch). If that's OK, let me know and I'll do that tomorrow. > > It's fine to cherry-pick, I can also send two separate branches (or > just 2+1 stand-alone patches). > > Any way you like it :) just tell me what to do, all I want is to get this > in for v4.10. Cherry-picking is actually faster on our side than merging, so I've done that now. Queued into next/dt and next/defconfig for 4.10. Thanks! -Olof
On Fri, Nov 18, 2016 at 6:53 PM, Olof Johansson <olof@lixom.net> wrote: > On Fri, Nov 18, 2016 at 09:26:56AM +0100, Linus Walleij wrote: >> On Fri, Nov 18, 2016 at 8:25 AM, Olof Johansson <olof@lixom.net> wrote: >> >> > I also sympathize that it's extra annoying having to split just three >> > patches across two branches. So, if it's easier we can just cherry-pick >> > apart the patches here across the branches (your comment about next >> > coverage makes me suspect you have no direct downstream users of this >> > branch). If that's OK, let me know and I'll do that tomorrow. >> >> It's fine to cherry-pick, I can also send two separate branches (or >> just 2+1 stand-alone patches). >> >> Any way you like it :) just tell me what to do, all I want is to get this >> in for v4.10. > > Cherry-picking is actually faster on our side than merging, so I've done that > now. Queued into next/dt and next/defconfig for 4.10. Thanks Olof, much appreciated! Yours, Linus Walleij
Hi ARM SoC folks, this adds DT-based cpufreq to the Integrator family. The corresponding cpufreq changes are merged by Rafael to the cpufreq tree, and can go in orthogonally. However I have included the defconfig change turning on the feature here as it makes all kind of logic sense to have these three patches in succession: addin the DTS nodes and then turning on the DT cpufreq. If you insist, of course I can send the defconfig patch separately. I just think it makes more sense like this. Please pull it in so we get some rotation in linux-next for this! Yours, Linus Walleij The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git tags/armsoc-integrator-dts for you to fetch changes up to 023c8faf9bbc95b2d00768414f0f73076ca06dc9: ARM: defconfig: turn on the DT cpufreq for Integrator (2016-11-09 09:02:46 +0100) ---------------------------------------------------------------- This contains the DTS changes enabling DT-only cpufreq scaling on the Integrator family. ---------------------------------------------------------------- Linus Walleij (3): ARM: dts: Add Integrator/AP cpus node and operating points ARM: dts: Add Integrator/CP cpus node and operating points ARM: defconfig: turn on the DT cpufreq for Integrator arch/arm/boot/dts/integratorap.dts | 35 +++++++++++++++++++++++++++++++++++ arch/arm/boot/dts/integratorcp.dts | 26 ++++++++++++++++++++++++++ arch/arm/configs/integrator_defconfig | 1 + 3 files changed, 62 insertions(+)