Message ID | cover.1403681315.git.horms+renesas@verge.net.au |
---|---|
State | New |
Headers | show |
On Wed, Jun 25, 2014 at 1:05 PM, Simon Horman <horms+renesas@verge.net.au> wrote: > From: Benoit Cousson <bcousson@baylibre.com> > > Mark all SoCs in shmobile as CPUFreq capable > on multiplatform build only. > > Signed-off-by: Benoit Cousson <bcousson@baylibre.com> > [gaku.inami.xw@bp.renesas.com: Move the definition of cpufreq capable] > Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > --- > arch/arm/mach-shmobile/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig > index dbd954e..c32fa7c 100644 > --- a/arch/arm/mach-shmobile/Kconfig > +++ b/arch/arm/mach-shmobile/Kconfig > @@ -12,6 +12,8 @@ config ARCH_SHMOBILE_MULTI > select NO_IOPORT_MAP > select PINCTRL > select ARCH_REQUIRE_GPIOLIB > + select ARCH_HAS_CPUFREQ > + select ARCH_HAS_OPP https://lkml.org/lkml/2014/6/2/714 http://patchwork.ozlabs.org/patch/356780/
On Wed, Jun 25, 2014 at 02:26:24PM +0530, Viresh Kumar wrote: > On Wed, Jun 25, 2014 at 1:05 PM, Simon Horman > <horms+renesas@verge.net.au> wrote: > > From: Benoit Cousson <bcousson@baylibre.com> > > > > Mark all SoCs in shmobile as CPUFreq capable > > on multiplatform build only. > > > > Signed-off-by: Benoit Cousson <bcousson@baylibre.com> > > [gaku.inami.xw@bp.renesas.com: Move the definition of cpufreq capable] > > Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > --- > > arch/arm/mach-shmobile/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig > > index dbd954e..c32fa7c 100644 > > --- a/arch/arm/mach-shmobile/Kconfig > > +++ b/arch/arm/mach-shmobile/Kconfig > > @@ -12,6 +12,8 @@ config ARCH_SHMOBILE_MULTI > > select NO_IOPORT_MAP > > select PINCTRL > > select ARCH_REQUIRE_GPIOLIB > > + select ARCH_HAS_CPUFREQ > > + select ARCH_HAS_OPP > > https://lkml.org/lkml/2014/6/2/714 > http://patchwork.ozlabs.org/patch/356780/ I believe this patch was queued up before those patches hit Linus's tree. In the case of ARCH_HAS_CPUFREQ, a subsequent patch in this pull-request, "ARM: shmobile: Remove ARCH_HAS_CPUFREQ config for shmobile", removes it. Inami-san, could you see about making a patch to remove ARCH_HAS_OPP too?
On 25 June 2014 14:56, Simon Horman <horms@verge.net.au> wrote: > In the case of ARCH_HAS_CPUFREQ, a subsequent patch in > this pull-request, "ARM: shmobile: Remove ARCH_HAS_CPUFREQ config for shmobile", > removes it. Hmm.. I fail to see why you are adding it in the first place then ?
On Wed, Jun 25, 2014 at 03:00:08PM +0530, Viresh Kumar wrote: > On 25 June 2014 14:56, Simon Horman <horms@verge.net.au> wrote: > > In the case of ARCH_HAS_CPUFREQ, a subsequent patch in > > this pull-request, "ARM: shmobile: Remove ARCH_HAS_CPUFREQ config for shmobile", > > removes it. > > Hmm.. I fail to see why you are adding it in the first place then ? Because it seemed to be right thing to do when the patch was written and accepted.
On 25 June 2014 17:08, Simon Horman <horms@verge.net.au> wrote: > Because it seemed to be right thing to do when the patch was written > and accepted. But it isn't merged yet, just drop irrelevant patches. Wouldn't make any sense to get these into kernel.
On Wed, Jun 25, 2014 at 05:09:59PM +0530, Viresh Kumar wrote: > On 25 June 2014 17:08, Simon Horman <horms@verge.net.au> wrote: > > Because it seemed to be right thing to do when the patch was written > > and accepted. > > But it isn't merged yet, just drop irrelevant patches. Wouldn't make any > sense to get these into kernel. Its been sitting in next and as I understand things it is frowned upon to rebase branches that are in next unless it is really necessary.
Hello. On 06/25/2014 11:35 AM, Simon Horman wrote: > From: Magnus Damm <damm+renesas@opensource.se> > Add R-Car Gen2 CMA memory reservation code that can be > shared between multiple SoCs and boards. At this point > r8a7790 and r8a7791 are supported. > The top 256MiB of the legacy 32-bit physical memory space > is assigned to a separate CMA area that may be assigned > to various devices later on. > Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > [horms+renesas@verge.net.au: rebased] > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> [...] > diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c > index fdc714e..544b9bf 100644 > --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c > +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c > @@ -20,8 +20,11 @@ > > #include <linux/clk/shmobile.h> > #include <linux/clocksource.h> > +#include <linux/device.h> > +#include <linux/dma-contiguous.h> > #include <linux/io.h> > #include <linux/kernel.h> > +#include <linux/of_fdt.h> > #include <asm/mach/arch.h> > #include "common.h" > #include "rcar-gen2.h" Hm, this part looks incomplete. I thought you were going to add CMA code here? WBR, Sergei
On Wed, Jun 25, 2014 at 07:18:09PM +0400, Sergei Shtylyov wrote: > Hello. > > On 06/25/2014 11:35 AM, Simon Horman wrote: > > >From: Magnus Damm <damm+renesas@opensource.se> > > >Add R-Car Gen2 CMA memory reservation code that can be > >shared between multiple SoCs and boards. At this point > >r8a7790 and r8a7791 are supported. > > >The top 256MiB of the legacy 32-bit physical memory space > >is assigned to a separate CMA area that may be assigned > >to various devices later on. > > >Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > >[horms+renesas@verge.net.au: rebased] > >Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > [...] > > >diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c > >index fdc714e..544b9bf 100644 > >--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c > >+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c > >@@ -20,8 +20,11 @@ > > > > #include <linux/clk/shmobile.h> > > #include <linux/clocksource.h> > >+#include <linux/device.h> > >+#include <linux/dma-contiguous.h> > > #include <linux/io.h> > > #include <linux/kernel.h> > >+#include <linux/of_fdt.h> > > #include <asm/mach/arch.h> > > #include "common.h" > > #include "rcar-gen2.h" > > Hm, this part looks incomplete. I thought you were going to add CMA code here? Thanks, something does indeed seem to have gone wrong there.
[Cc Olof] On Thu, Jun 26, 2014 at 08:47:08AM +0900, Simon Horman wrote: > On Wed, Jun 25, 2014 at 07:18:09PM +0400, Sergei Shtylyov wrote: > > Hello. > > > > On 06/25/2014 11:35 AM, Simon Horman wrote: > > > > >From: Magnus Damm <damm+renesas@opensource.se> > > > > >Add R-Car Gen2 CMA memory reservation code that can be > > >shared between multiple SoCs and boards. At this point > > >r8a7790 and r8a7791 are supported. > > > > >The top 256MiB of the legacy 32-bit physical memory space > > >is assigned to a separate CMA area that may be assigned > > >to various devices later on. > > > > >Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > > >[horms+renesas@verge.net.au: rebased] > > >Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > > > [...] > > > > >diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c > > >index fdc714e..544b9bf 100644 > > >--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c > > >+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c > > >@@ -20,8 +20,11 @@ > > > > > > #include <linux/clk/shmobile.h> > > > #include <linux/clocksource.h> > > >+#include <linux/device.h> > > >+#include <linux/dma-contiguous.h> > > > #include <linux/io.h> > > > #include <linux/kernel.h> > > >+#include <linux/of_fdt.h> > > > #include <asm/mach/arch.h> > > > #include "common.h" > > > #include "rcar-gen2.h" > > > > Hm, this part looks incomplete. I thought you were going to add CMA code here? > > Thanks, something does indeed seem to have gone wrong there. I suspect that this is the result of an error on my part when I rebased the code on top of v3.16-rc1 before making it available to next. The missing code appears to lie in "ARM: shmobile: rcar-gen2: Update for of_get_flat_dt_prop() update". Olof, I'd prefer not to rebase my branches in next. But if you'd like me to do so to clean up this problem then let me know.
Hi Simon-san, (2014/06/25 18:26), Simon Horman wrote: > On Wed, Jun 25, 2014 at 02:26:24PM +0530, Viresh Kumar wrote: >> On Wed, Jun 25, 2014 at 1:05 PM, Simon Horman >> <horms+renesas@verge.net.au> wrote: >>> From: Benoit Cousson <bcousson@baylibre.com> >>> >>> Mark all SoCs in shmobile as CPUFreq capable >>> on multiplatform build only. >>> >>> Signed-off-by: Benoit Cousson <bcousson@baylibre.com> >>> [gaku.inami.xw@bp.renesas.com: Move the definition of cpufreq capable] >>> Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> >>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> >>> --- >>> arch/arm/mach-shmobile/Kconfig | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig >>> index dbd954e..c32fa7c 100644 >>> --- a/arch/arm/mach-shmobile/Kconfig >>> +++ b/arch/arm/mach-shmobile/Kconfig >>> @@ -12,6 +12,8 @@ config ARCH_SHMOBILE_MULTI >>> select NO_IOPORT_MAP >>> select PINCTRL >>> select ARCH_REQUIRE_GPIOLIB >>> + select ARCH_HAS_CPUFREQ >>> + select ARCH_HAS_OPP >> https://lkml.org/lkml/2014/6/2/714 >> http://patchwork.ozlabs.org/patch/356780/ > I believe this patch was queued up before those patches hit Linus's tree. > > In the case of ARCH_HAS_CPUFREQ, a subsequent patch in > this pull-request, "ARM: shmobile: Remove ARCH_HAS_CPUFREQ config for shmobile", > removes it. > > Inami-san, could you see about making a patch to remove ARCH_HAS_OPP too? Sorry for late reply. I posted this patch to linux-sh ML on May 29. At that time, I couldn't see a patch to remove ARCH_HAS_CPUFREQ. However, I should have noticed this modification earlier.
On Wed, Jun 25, 2014 at 04:35:24PM +0900, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC updates for v3.17. > > This pull request is based on 'Renesas ARM Based SoC Header Cleanup for v3.17', > tagged as header-cleanup-for-v3.17, which I have already sent a > pull-request for. > > The following changes since commit 62872989bdbf1245d7239b9f4c05a8ee7c775ed5: > > ARM: shmobile: Move rcar-gen2.h, cleanup r8a7790 case (2014-06-17 17:09:40 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-for-v3.17 > > for you to fetch changes up to 3ed66ec5ced8b801cb851b2b8548301df94f8f54: > > ARM: shmobile: Remove ARCH_HAS_CPUFREQ config for shmobile (2014-06-23 09:53:55 +0900) > > ---------------------------------------------------------------- > Renesas ARM Based SoC Updates for v3.17 > > * Use shmobile_init_late on r8a7791 and r8a7790 whien booting using DT-only > * Support Core-Standby for Suspend to RAM on r8a7791 and r8a7790 SoCs > * Shared CMA reservation for R-Car Gen2 SoCs > * Add r8a7791 SYSC power management support This branch also seems to contain a bunch of bugfixes? Did they get merged into the wrong base, or what's going on? > Benoit Cousson (1): > ARM: shmobile: Mark all SoCs in shmobile as CPUFreq, capable > > Gaku Inami (1): > ARM: shmobile: Remove ARCH_HAS_CPUFREQ config for shmobile The latter patch fixes the former, why not just fold them in? > Geert Uytterhoeven (3): > ARM: shmobile: rcar-gen2: Update for of_get_flat_dt_prop() update > ARM: shmobile: rcar-gen2: Use "1ULL" instead of "(u64)1" > ARM: shmobile: rcar-gen2: Remove useless copied section for LongTrail The last two seem to be small bug fixes/cleanups. They should probably go in a cleanup branch unless there are conflicts with new development. Even then, we tend to prefer to order it with the cleanups/fixes before new development (where it doesn't cause extra complications). > > Magnus Damm (3): > ARM: shmobile: Use shmobile_init_late() on r8a7790 DT-only > ARM: shmobile: Use shmobile_init_late() on r8a7791 DT-only > ARM: shmobile: Add shared R-Car Gen2 CMA reservation code > > Simon Horman (1): > ARM: shmobile: rcar-gen2: correct return value of shmobile_smp_apmu_suspend_init > > Vincent Stehlé (1): > ARM: shmobile: rcar-gen2: update call to dma_contiguous_reserve_area Again those two patches seem to be fixes, the former to a patch in this very branch. > keita kobayashi (4): > ARM: shmobile: r8a7791 SYSC setup code > ARM: shmobile: APMU: Add Core-Standby-state for Suspend to RAM > ARM: shmobile: r8a7790: Support Core-Standby for Suspend to RAM > ARM: shmobile: r8a7791: Support Core-Standby for Suspend to RAM Anyway, I've merged it in as it is. Keep some of the above stuff in mind for future releases though. -Olof
On Mon, Jul 07, 2014 at 10:07:08PM -0700, Olof Johansson wrote: > On Wed, Jun 25, 2014 at 04:35:24PM +0900, Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > > > Please consider these Renesas ARM based SoC updates for v3.17. > > > > This pull request is based on 'Renesas ARM Based SoC Header Cleanup for v3.17', > > tagged as header-cleanup-for-v3.17, which I have already sent a > > pull-request for. > > > > The following changes since commit 62872989bdbf1245d7239b9f4c05a8ee7c775ed5: > > > > ARM: shmobile: Move rcar-gen2.h, cleanup r8a7790 case (2014-06-17 17:09:40 +0900) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-for-v3.17 > > > > for you to fetch changes up to 3ed66ec5ced8b801cb851b2b8548301df94f8f54: > > > > ARM: shmobile: Remove ARCH_HAS_CPUFREQ config for shmobile (2014-06-23 09:53:55 +0900) > > > > ---------------------------------------------------------------- > > Renesas ARM Based SoC Updates for v3.17 > > > > * Use shmobile_init_late on r8a7791 and r8a7790 whien booting using DT-only > > * Support Core-Standby for Suspend to RAM on r8a7791 and r8a7790 SoCs > > * Shared CMA reservation for R-Car Gen2 SoCs > > * Add r8a7791 SYSC power management support > > This branch also seems to contain a bunch of bugfixes? Did they get merged into > the wrong base, or what's going on? > > > Benoit Cousson (1): > > ARM: shmobile: Mark all SoCs in shmobile as CPUFreq, capable > > > > Gaku Inami (1): > > ARM: shmobile: Remove ARCH_HAS_CPUFREQ config for shmobile > > The latter patch fixes the former, why not just fold them in? > > > Geert Uytterhoeven (3): > > ARM: shmobile: rcar-gen2: Update for of_get_flat_dt_prop() update > > ARM: shmobile: rcar-gen2: Use "1ULL" instead of "(u64)1" > > ARM: shmobile: rcar-gen2: Remove useless copied section for LongTrail > > The last two seem to be small bug fixes/cleanups. They should probably go in a > cleanup branch unless there are conflicts with new development. Even then, we > tend to prefer to order it with the cleanups/fixes before new development > (where it doesn't cause extra complications). > > > > > Magnus Damm (3): > > ARM: shmobile: Use shmobile_init_late() on r8a7790 DT-only > > ARM: shmobile: Use shmobile_init_late() on r8a7791 DT-only > > ARM: shmobile: Add shared R-Car Gen2 CMA reservation code > > > > Simon Horman (1): > > ARM: shmobile: rcar-gen2: correct return value of shmobile_smp_apmu_suspend_init > > > > Vincent Stehlé (1): > > ARM: shmobile: rcar-gen2: update call to dma_contiguous_reserve_area > > Again those two patches seem to be fixes, the former to a patch in this very > branch. > > > keita kobayashi (4): > > ARM: shmobile: r8a7791 SYSC setup code > > ARM: shmobile: APMU: Add Core-Standby-state for Suspend to RAM > > ARM: shmobile: r8a7790: Support Core-Standby for Suspend to RAM > > ARM: shmobile: r8a7791: Support Core-Standby for Suspend to RAM > > Anyway, I've merged it in as it is. Keep some of the above stuff in mind > for future releases though. Thanks, I will try to tune my processes to produce cleaner branches for you.