Skip to contentSkip to conversation

Renesas ARM Based SoC Soc Updates for v3.19

GIT PULL New Simon Horman 5 participants 13 messages Nov 4, 2014 – Dec 4, 2014

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC soc updates for v3.19.

The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:

Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v3.19

for you to fetch changes up to 3794705aeb318c431c07072f04380c78cc5a84ac:

ARM: shmobile: Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled (2014-10-28 08:43:03 +0900)

----------------------------------------------------------------
Renesas ARM Based SoC Soc Updates for v3.19

* Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled
* Add CA7 arch_timer initialization for r8a7794
* Handle CA7 arch timer delay
* Add shmobile_init_late() to sh7372
- This is consistent with other shmobile SoCs

----------------------------------------------------------------
Geert Uytterhoeven (1):
ARM: shmobile: sh7372: Add shmobile_init_late()

Laurent Pinchart (1):
ARM: shmobile: Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled

Magnus Damm (1):
ARM: shmobile: Handle CA7 arch timer delay

Ulrich Hecht (1):
ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794

 arch/arm/mach-shmobile/Kconfig           |  1 +
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 72 ++++++++++++++++++++++----------
 arch/arm/mach-shmobile/setup-sh7372.c    |  1 +
 arch/arm/mach-shmobile/timer.c           | 23 ++++++----
 4 files changed, 66 insertions(+), 31 deletions(-)
#1 lore raw

PATCH 1/4 ARM: shmobile: Handle CA7 arch timer delay

From: Magnus Damm <[email protected]>

Update the delay code to include arch timer checks for CA7. From a arch timer availability perspective CA7 should be treated same as CA15.

---
 arch/arm/mach-shmobile/timer.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)
arch/arm/mach-shmobile/timer.c +15 -8
index 87c6be1..32ee335 100644
@@ -45,6 +45,7 @@ void __init shmobile_init_delay(void)
 	struct device_node *np, *cpus;
 	bool is_a7_a8_a9 = false;
 	bool is_a15 = false;
+	bool has_arch_timer = false;
 	u32 max_freq = 0;
 
 	cpus = of_find_node_by_path("/cpus");
@@ -57,12 +58,16 @@ void __init shmobile_init_delay(void)
 		if (!of_property_read_u32(np, "clock-frequency", &freq))
 			max_freq = max(max_freq, freq);
 
-		if (of_device_is_compatible(np, "arm,cortex-a7") ||
-		    of_device_is_compatible(np, "arm,cortex-a8") ||
-		    of_device_is_compatible(np, "arm,cortex-a9"))
+		if (of_device_is_compatible(np, "arm,cortex-a8") ||
+		    of_device_is_compatible(np, "arm,cortex-a9")) {
 			is_a7_a8_a9 = true;
-		else if (of_device_is_compatible(np, "arm,cortex-a15"))
+		} else if (of_device_is_compatible(np, "arm,cortex-a7")) {
+			is_a7_a8_a9 = true;
+			has_arch_timer = true;
+		} else if (of_device_is_compatible(np, "arm,cortex-a15")) {
 			is_a15 = true;
+			has_arch_timer = true;
+		}
 	}
 
 	of_node_put(cpus);
@@ -70,10 +75,12 @@ void __init shmobile_init_delay(void)
 	if (!max_freq)
 		return;
 
-	if (is_a7_a8_a9)
-		shmobile_setup_delay_hz(max_freq, 1, 3);
-	else if (is_a15 && !IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
-		shmobile_setup_delay_hz(max_freq, 2, 4);
+	if (!has_arch_timer || !IS_ENABLED(CONFIG_ARM_ARCH_TIMER)) {
+		if (is_a7_a8_a9)
+			shmobile_setup_delay_hz(max_freq, 1, 3);
+		else if (is_a15)
+			shmobile_setup_delay_hz(max_freq, 2, 4);
+	}
 }
 
 static void __init shmobile_late_time_init(void)
Signature · 1 line
2.1.1
#2 lore raw

PATCH 2/4 ARM: shmobile: sh7372: Add shmobile_init_late()

In reply to Simon Horman

From: Geert Uytterhoeven <[email protected]>

Extend sh7372 SoC machine vector to include shmobile_init_late() so Suspend-to-RAM and CPUIdle are setup as expected.

---
 arch/arm/mach-shmobile/setup-sh7372.c | 1 +
 1 file changed, 1 insertion(+)
arch/arm/mach-shmobile/setup-sh7372.c +1 -0
index d646c8d..769ff00 100644
@@ -1012,6 +1012,7 @@ DT_MACHINE_START(SH7372_DT, "Generic SH7372 (Flattened Device Tree)")
 	.init_irq	= sh7372_init_irq,
 	.handle_irq	= shmobile_handle_irq_intc,
 	.init_machine	= sh7372_add_standard_devices_dt,
+	.init_late	= shmobile_init_late,
 	.dt_compat	= sh7372_boards_compat_dt,
 MACHINE_END
 
Signature · 1 line
2.1.1
#3 lore raw

PATCH 3/4 ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794

In reply to Simon Horman

From: Ulrich Hecht <[email protected]>

On E2, the arch timer is hooked up to a different clock, and the CA7's arch timer CNTVOFF register must be initialized.

Based on work by Hisashi Nakamura.

---
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 72 ++++++++++++++++++++++----------
 1 file changed, 49 insertions(+), 23 deletions(-)
arch/arm/mach-shmobile/setup-rcar-gen2.c +49 -23
index 42d5b43..7ed9279 100644
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Magnus Damm
+ * Copyright (C) 2014  Ulrich Hecht
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -24,6 +25,7 @@
 #include <linux/dma-contiguous.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
+#include <linux/of.h>
 #include <linux/of_fdt.h>
 #include <asm/mach/arch.h>
 #include "common.h"
@@ -54,37 +56,61 @@ void __init rcar_gen2_timer_init(void)
 {
 #if defined(CONFIG_ARM_ARCH_TIMER) || defined(CONFIG_COMMON_CLK)
 	u32 mode = rcar_gen2_read_mode_pins();
+	bool is_e2 = (bool)of_find_compatible_node(NULL, NULL,
+		"renesas,r8a7794");
 #endif
 #ifdef CONFIG_ARM_ARCH_TIMER
 	void __iomem *base;
 	int extal_mhz = 0;
 	u32 freq;
 
-	/* At Linux boot time the r8a7790 arch timer comes up
-	 * with the counter disabled. Moreover, it may also report
-	 * a potentially incorrect fixed 13 MHz frequency. To be
-	 * correct these registers need to be updated to use the
-	 * frequency EXTAL / 2 which can be determined by the MD pins.
-	 */
-
-	switch (mode & (MD(14) | MD(13))) {
-	case 0:
-		extal_mhz = 15;
-		break;
-	case MD(13):
-		extal_mhz = 20;
-		break;
-	case MD(14):
-		extal_mhz = 26;
-		break;
-	case MD(13) | MD(14):
-		extal_mhz = 30;
-		break;
+	if (is_e2) {
+		freq = 260000000 / 8;	/* ZS / 8 */
+		/* CNTVOFF has to be initialized either from non-secure
+		 * Hypervisor mode or secure Monitor mode with SCR.NS==1.
+		 * If TrustZone is enabled then it should be handled by the
+		 * secure code.
+		 */
+		asm volatile(
+		"	cps	0x16\n"
+		"	mrc	p15, 0, r1, c1, c1, 0\n"
+		"	orr	r0, r1, #1\n"
+		"	mcr	p15, 0, r0, c1, c1, 0\n"
+		"	isb\n"
+		"	mov	r0, #0\n"
+		"	mcrr	p15, 4, r0, r0, c14\n"
+		"	isb\n"
+		"	mcr	p15, 0, r1, c1, c1, 0\n"
+		"	isb\n"
+		"	cps	0x13\n"
+			: : : "r0", "r1");
+	} else {
+		/* At Linux boot time the r8a7790 arch timer comes up
+		 * with the counter disabled. Moreover, it may also report
+		 * a potentially incorrect fixed 13 MHz frequency. To be
+		 * correct these registers need to be updated to use the
+		 * frequency EXTAL / 2 which can be determined by the MD pins.
+		 */
+
+		switch (mode & (MD(14) | MD(13))) {
+		case 0:
+			extal_mhz = 15;
+			break;
+		case MD(13):
+			extal_mhz = 20;
+			break;
+		case MD(14):
+			extal_mhz = 26;
+			break;
+		case MD(13) | MD(14):
+			extal_mhz = 30;
+			break;
+		}
+
+		/* The arch timer frequency equals EXTAL / 2 */
+		freq = extal_mhz * (1000000 / 2);
 	}
 
-	/* The arch timer frequency equals EXTAL / 2 */
-	freq = extal_mhz * (1000000 / 2);
-
 	/* Remap "armgcnt address map" space */
 	base = ioremap(0xe6080000, PAGE_SIZE);
 
Signature · 1 line
2.1.1
#4 lore raw

PATCH 3/4 ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794

Quoted 9 lines · On Tuesday 04 November 2014 10:50:08 Simon Horman wrote:

From: Ulrich Hecht <[email protected]>

On E2, the arch timer is hooked up to a different clock, and the CA7's arch timer CNTVOFF register must be initialized.

Based on work by Hisashi Nakamura.

This is one of the patches that broke allmodconfig in linux-next.

Can you apply the patch below before sending it to arm-soc?

Thanks,

Arnd

---

Quoted 1 line

From 8bf0a4cae3137411498ff23ca46f693e4c22a25b Mon Sep 17 00:00:00 2001

From: Arnd Bergmann <[email protected]>
Date: Tue, 11 Nov 2014 16:36:50 +0100
Subject: [PATCH] ARM: shmobile: always build rcar setup for armv7

In a combined ARMv6/v7 kernel, the setup-rcar-gen2.c cannot currently be compiled correctly because it uses the isb instruction that is not available on ARMv6. Adding the -march=armv7-a flag lets the compiler know that it is safe to build this file for ARMv7.

arch/arm/mach-shmobile/Makefile +1 -0
index 7d68eba53be3..b55cac0e5b2b 100644
@@ -35,6 +35,7 @@ cpu-y				:= platsmp.o headsmp.o
 
 # Shared SoC family objects
 obj-$(CONFIG_ARCH_RCAR_GEN2)	+= setup-rcar-gen2.o platsmp-apmu.o $(cpu-y)
+CFLAGS_setup-rcar-gen2.o	+= -march=armv7-a
 
 # SMP objects
 smp-y				:= $(cpu-y)
#5 lore raw

PATCH 3/4 ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794

Quoted 25 lines · Arnd Bergmann
Quoted 9 lines · On Tuesday 04 November 2014 10:50:08 Simon Horman wrote:

From: Ulrich Hecht <[email protected]>

On E2, the arch timer is hooked up to a different clock, and the CA7's arch timer CNTVOFF register must be initialized.

Based on work by Hisashi Nakamura.

This is one of the patches that broke allmodconfig in linux-next.

Can you apply the patch below before sending it to arm-soc?

Thanks,

Arnd

---
From 8bf0a4cae3137411498ff23ca46f693e4c22a25b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <[email protected]>
Date: Tue, 11 Nov 2014 16:36:50 +0100
Subject: [PATCH] ARM: shmobile: always build rcar setup for armv7

Quoted 7 lines

In a combined ARMv6/v7 kernel, the setup-rcar-gen2.c cannot currently be compiled correctly because it uses the isb instruction that is not available on ARMv6. Adding the -march=armv7-a flag lets the compiler know that it is safe to build this file for ARMv7.

Thanks, this is a better solution than "[RFT] ARM: shmobile: rcar-gen2:
Fix build breakage" (https://lkml.org/lkml/2014/10/31/338).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#6 lore raw

PATCH 3/4 ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794

Quoted 32 lines · Geert Uytterhoeven
Quoted 31 lines · Arnd Bergmann
Quoted 9 lines · On Tuesday 04 November 2014 10:50:08 Simon Horman wrote:

From: Ulrich Hecht <[email protected]>

On E2, the arch timer is hooked up to a different clock, and the CA7's arch timer CNTVOFF register must be initialized.

Based on work by Hisashi Nakamura.

This is one of the patches that broke allmodconfig in linux-next.

Can you apply the patch below before sending it to arm-soc?

Thanks,

Arnd

---
From 8bf0a4cae3137411498ff23ca46f693e4c22a25b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <[email protected]>
Date: Tue, 11 Nov 2014 16:36:50 +0100
Subject: [PATCH] ARM: shmobile: always build rcar setup for armv7

In a combined ARMv6/v7 kernel, the setup-rcar-gen2.c cannot currently be compiled correctly because it uses the isb instruction that is not available on ARMv6. Adding the -march=armv7-a flag lets the compiler know that it is safe to build this file for ARMv7.

Quoted 6 lines
Quoted 1 line

Thanks, this is a better solution than "[RFT] ARM: shmobile: rcar-gen2:
Fix build breakage" (https://lkml.org/lkml/2014/10/31/338).

Agreed.

Arnd, what is the best way to get this patch merged? Do you plan to take it or should I?

#7 lore raw

PATCH 3/4 ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794

Quoted 16 lines · On Wednesday 12 November 2014 08:59:55 Simon Horman wrote:
Quoted 16 lines
Quoted 5 lines

From 8bf0a4cae3137411498ff23ca46f693e4c22a25b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <[email protected]>
Date: Tue, 11 Nov 2014 16:36:50 +0100
Subject: [PATCH] ARM: shmobile: always build rcar setup for armv7

Quoted 7 lines

In a combined ARMv6/v7 kernel, the setup-rcar-gen2.c cannot currently be compiled correctly because it uses the isb instruction that is not available on ARMv6. Adding the -march=armv7-a flag lets the compiler know that it is safe to build this file for ARMv7.

Thanks, this is a better solution than "[RFT] ARM: shmobile: rcar-gen2:
Fix build breakage" (https://lkml.org/lkml/2014/10/31/338).

Quoted 8 lines
Quoted 1 line

Agreed.

Arnd, what is the best way to get this patch merged? Do you plan to take it or should I?

I believe the problem only exists in your tree at the moment, not in arm-soc, so please apply it on top of the branch that introduced the build error before sending it to arm-soc. If you have already sent a pull request but we haven't taken it yet, send an updated pull request that adds this patch.

Arnd

#8 lore raw

PATCH 3/4 ARM: shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794

Quoted 23 lines · Arnd Bergmann
Quoted 22 lines · On Wednesday 12 November 2014 08:59:55 Simon Horman wrote:
Quoted 11 lines
Quoted 11 lines

From 8bf0a4cae3137411498ff23ca46f693e4c22a25b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <[email protected]>
Date: Tue, 11 Nov 2014 16:36:50 +0100
Subject: [PATCH] ARM: shmobile: always build rcar setup for armv7

In a combined ARMv6/v7 kernel, the setup-rcar-gen2.c cannot currently be compiled correctly because it uses the isb instruction that is not available on ARMv6. Adding the -march=armv7-a flag lets the compiler know that it is safe to build this file for ARMv7.

Quoted 6 lines
Quoted 1 line

Thanks, this is a better solution than "[RFT] ARM: shmobile: rcar-gen2:
Fix build breakage" (https://lkml.org/lkml/2014/10/31/338).

Agreed.

Quoted 8 lines
Quoted 2 lines

Arnd, what is the best way to get this patch merged? Do you plan to take it or should I?

I believe the problem only exists in your tree at the moment, not in arm-soc, so please apply it on top of the branch that introduced the build error before sending it to arm-soc. If you have already sent a pull request but we haven't taken it yet, send an updated pull request that adds this patch.

Sure, will do.

#9 lore raw

PATCH 4/4 ARM: shmobile: Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled

In reply to Simon Horman

From: Laurent Pinchart <[email protected]>

Most IP cores on ARM Renesas platforms can only address 32 bits of physical memory for DMA. Without CONFIG_ZONE_DMA enabled and with the recent CMA highmem allocation support, the default CMA zone is reserved above the 4GiB limit when LPAE is enabled, resulting in various driver failures.

Fix the problem by selecting CONFIG_ZONE_DMA. Other options to investigate in the future would be to either enable IOMMU support or use custom CMA reservations for peripherals not supporting LPAE.

While not a strict dependency, the "[PATCH 0/4] Low/high memory CMA reservation fixes" series is also required to fix a different but related CMA allocation problem.

---
 arch/arm/mach-shmobile/Kconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm/mach-shmobile/Kconfig +1 -0
index 21f457b..6bc018f 100644
@@ -1,5 +1,6 @@
 config ARCH_SHMOBILE
 	bool
+	select ZONE_DMA if ARM_LPAE
 
 config PM_RCAR
 	bool
Signature · 1 line
2.1.1
#10 lore raw
In reply to Simon Horman
Quoted 8 lines · Simon Horman

----------------------------------------------------------------
Renesas ARM Based SoC Soc Updates for v3.19

* Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled
* Add CA7 arch_timer initialization for r8a7794
* Handle CA7 arch timer delay
* Add shmobile_init_late() to sh7372
- This is consistent with other shmobile SoCs

Pulled into next/soc.

Note that the CONFIG_ZONE_DMA change might not be the best solution, we should probably have CONFIG_ZONE_DMA32 instead as some other architectures do, so you can use the entire lowmem area for DMA allocations.

Arnd

#11 lore raw

Hi Arnd,

Quoted 9 lines · On Wednesday 19 November 2014 22:05:56 Arnd Bergmann wrote:
Quoted 8 lines · Simon Horman

----------------------------------------------------------------
Renesas ARM Based SoC Soc Updates for v3.19

* Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled
* Add CA7 arch_timer initialization for r8a7794
* Handle CA7 arch timer delay
* Add shmobile_init_late() to sh7372

Quoted 7 lines
Quoted 1 line

- This is consistent with other shmobile SoCs

Pulled into next/soc.

Note that the CONFIG_ZONE_DMA change might not be the best solution, we should probably have CONFIG_ZONE_DMA32 instead as some other architectures do, so you can use the entire lowmem area for DMA allocations.

I might be mistaken, but if the machine description doesn't set the dma_zone_size field, arm_dma_zone_size and arm_dma_limit are set to 0 and 0xffffffff respectively. This results in MAX_DMA_ADDRESS being set to 0xffffffff. Doesn't that allow using the entire lowmem area for DMA allocations ?

Signature · 3 lines
Regards,

Laurent Pinchart
#12 lore raw
Quoted 20 lines · On Thursday 27 November 2014 22:48:12 Laurent Pinchart wrote:

Hi Arnd,

Quoted 9 lines · On Wednesday 19 November 2014 22:05:56 Arnd Bergmann wrote:
Quoted 8 lines · Simon Horman

----------------------------------------------------------------
Renesas ARM Based SoC Soc Updates for v3.19

* Select CONFIG_ZONE_DMA when CONFIG_ARM_LPAE is enabled
* Add CA7 arch_timer initialization for r8a7794
* Handle CA7 arch timer delay
* Add shmobile_init_late() to sh7372

Quoted 7 lines
Quoted 1 line

- This is consistent with other shmobile SoCs

Pulled into next/soc.

Note that the CONFIG_ZONE_DMA change might not be the best solution, we should probably have CONFIG_ZONE_DMA32 instead as some other architectures do, so you can use the entire lowmem area for DMA allocations.

Quoted 5 lines

I might be mistaken, but if the machine description doesn't set the dma_zone_size field, arm_dma_zone_size and arm_dma_limit are set to 0 and 0xffffffff respectively. This results in MAX_DMA_ADDRESS being set to 0xffffffff. Doesn't that allow using the entire lowmem area for DMA allocations ?

Sorry for the late reply. I hadn't actually looked at the details this far, and I would assume that you are right.

Arnd