* [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP support
2011-06-30 9:47 [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP prototype support Magnus Damm
@ 2011-08-26 6:43 ` Magnus Damm
2011-09-23 5:52 ` [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SM support Magnus Damm
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Magnus Damm @ 2011-08-26 6:43 UTC (permalink / raw)
To: linux-sh
From: Magnus Damm <damm@opensource.se>
This patch adds sh7372 A3SP power domain support.
The sh7372 A3SP hardware power domain contains a
wide range of I/O devices. The list of I/O devices
include SCIF serial ports, DMA Engine hardware,
SD and MMC controller hardware, USB controllers
and I2C master controllers.
This patch adds the A3SP low level code which
powers the hardware power domain on and off. It
also ties in platform devices to the pm domain
support code.
It is worth noting that the serial console is
hooked up to SCIFA0 on most sh7372 boards, and
the SCIFA0 port is included in the A3SP hardware
power domain. For this reason we cannot output
debug messages from the low level power control
code in the case of A3SP.
This patch seems to work quite fine except for
Suspend-to-RAM that is broken with this patch
applied. QoS support is needed in drivers before
we can enable the A3SP power control on the fly.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
Depends on USB-DMAC patches by Morimoto-san.
arch/arm/mach-shmobile/board-ap4evb.c | 4 ++++
arch/arm/mach-shmobile/board-mackerel.c | 8 ++++++++
arch/arm/mach-shmobile/include/mach/sh7372.h | 1 +
arch/arm/mach-shmobile/pm-sh7372.c | 19 +++++++++++++++----
arch/arm/mach-shmobile/setup-sh7372.c | 14 ++++++++++++++
5 files changed, 42 insertions(+), 4 deletions(-)
--- 0006/arch/arm/mach-shmobile/board-ap4evb.c
+++ work/arch/arm/mach-shmobile/board-ap4evb.c 2011-08-26 12:44:29.000000000 +0900
@@ -1408,6 +1408,10 @@ static void __init ap4evb_init(void)
sh7372_add_device_to_domain(&sh7372_a4lc, &lcdc_device);
sh7372_add_device_to_domain(&sh7372_a4mp, &fsi_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &sh_mmcif_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi0_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi1_device);
+
hdmi_init_pm_clock();
fsi_init_pm_clock();
sh7372_pm_init();
--- 0006/arch/arm/mach-shmobile/board-mackerel.c
+++ work/arch/arm/mach-shmobile/board-mackerel.c 2011-08-26 12:44:29.000000000 +0900
@@ -1588,6 +1588,14 @@ static void __init mackerel_init(void)
sh7372_add_device_to_domain(&sh7372_a4lc, &lcdc_device);
sh7372_add_device_to_domain(&sh7372_a4lc, &hdmi_lcdc_device);
sh7372_add_device_to_domain(&sh7372_a4mp, &fsi_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &usbhs0_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &usbhs1_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &sh_mmcif_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi0_device);
+#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+ sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi1_device);
+#endif
+ sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi2_device);
hdmi_init_pm_clock();
sh7372_pm_init();
--- 0004/arch/arm/mach-shmobile/include/mach/sh7372.h
+++ work/arch/arm/mach-shmobile/include/mach/sh7372.h 2011-08-26 12:44:29.000000000 +0900
@@ -493,6 +493,7 @@ extern struct sh7372_pm_domain sh7372_a4
extern struct sh7372_pm_domain sh7372_d4;
extern struct sh7372_pm_domain sh7372_a3rv;
extern struct sh7372_pm_domain sh7372_a3ri;
+extern struct sh7372_pm_domain sh7372_a3sp;
extern struct sh7372_pm_domain sh7372_a3sg;
extern void sh7372_init_pm_domain(struct sh7372_pm_domain *sh7372_pd);
--- 0011/arch/arm/mach-shmobile/pm-sh7372.c
+++ work/arch/arm/mach-shmobile/pm-sh7372.c 2011-08-26 12:44:29.000000000 +0900
@@ -92,8 +92,10 @@ static int pd_power_down(struct generic_
}
}
- pr_debug("sh7372 power domain down 0x%08x -> PSTR = 0x%08x\n",
- mask, __raw_readl(PSTR));
+ /* we cannot output debug message for A3SP */
+ if (genpd != &sh7372_a3sp.genpd)
+ pr_debug("sh7372 power domain down 0x%08x -> PSTR = 0x%08x\n",
+ mask, __raw_readl(PSTR));
return 0;
}
@@ -122,8 +124,10 @@ static int pd_power_up(struct generic_pm
ret = -EIO;
out:
- pr_debug("sh7372 power domain up 0x%08x -> PSTR = 0x%08x\n",
- mask, __raw_readl(PSTR));
+ /* we cannot output debug message for A3SP */
+ if (genpd != &sh7372_a3sp.genpd)
+ pr_debug("sh7372 power domain up 0x%08x -> PSTR = 0x%08x\n",
+ mask, __raw_readl(PSTR));
return ret;
}
@@ -216,6 +220,10 @@ struct sh7372_pm_domain sh7372_a3ri = {
.bit_shift = 8,
};
+struct sh7372_pm_domain sh7372_a3sp = {
+ .bit_shift = 11,
+};
+
struct sh7372_pm_domain sh7372_a3sg = {
.bit_shift = 13,
};
@@ -450,6 +458,9 @@ void __init sh7372_pm_init(void)
__raw_writel(0x0000a501, DBGREG9);
__raw_writel(0x00000000, DBGREG1);
+ /* do not convert A3SM, A3SP, A3SG, A4R power down into A4S */
+ __raw_writel(0, PDNSEL);
+
sh7372_suspend_init();
sh7372_cpuidle_init();
}
--- 0004/arch/arm/mach-shmobile/setup-sh7372.c
+++ work/arch/arm/mach-shmobile/setup-sh7372.c 2011-08-26 12:44:29.000000000 +0900
@@ -993,6 +993,7 @@ void __init sh7372_add_standard_devices(
sh7372_init_pm_domain(&sh7372_a3rv);
sh7372_init_pm_domain(&sh7372_a3ri);
sh7372_init_pm_domain(&sh7372_a3sg);
+ sh7372_init_pm_domain(&sh7372_a3sp);
platform_add_devices(sh7372_early_devices,
ARRAY_SIZE(sh7372_early_devices));
@@ -1003,6 +1004,19 @@ void __init sh7372_add_standard_devices(
sh7372_add_device_to_domain(&sh7372_a3rv, &vpu_device);
sh7372_add_device_to_domain(&sh7372_a4mp, &spu0_device);
sh7372_add_device_to_domain(&sh7372_a4mp, &spu1_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &scif0_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &scif1_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &scif2_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &scif3_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &scif4_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &scif5_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &scif6_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &iic1_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &dma0_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &dma1_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &dma2_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &usb_dma0_device);
+ sh7372_add_device_to_domain(&sh7372_a3sp, &usb_dma1_device);
}
void __init sh7372_add_early_devices(void)
^ permalink raw reply [flat|nested] 7+ messages in thread* [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SM support
2011-06-30 9:47 [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP prototype support Magnus Damm
2011-08-26 6:43 ` [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP support Magnus Damm
@ 2011-09-23 5:52 ` Magnus Damm
2012-03-07 5:53 ` [PATCH 02/03] ARM: mach-shmobile: sh7372 generic board support via DT Magnus Damm
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Magnus Damm @ 2011-09-23 5:52 UTC (permalink / raw)
To: linux-sh
From: Magnus Damm <damm@opensource.se>
This patch adds sh7372 A3SM power domain support.
The sh7372 A3SM hardware power domain contains the
ARM Cortex-A8 CPU Core including L2 cache. This
sleep mode can be seen as a one step deeper sleep
mode from the already existing Core Standby mode.
To wake up from A3SM sleep only a few wakeup sources
are supported - so the regular INTC controller will
not be able to help us unfortunately.
The code in this patch will enter A3SM sleep via the
regular Suspend-to-RAM interface in the case of only
wakeups supported by A3SM are enabled. If unsupported
wakeups are enabled then Core Standby will be used
instead.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
To be able to enter A3SM you need to apply MSTP patches
for MSIOF, CMT and USB-DMAC. You may also have to
disable the serial console on the kernel command line.
arch/arm/mach-shmobile/include/mach/common.h | 3
arch/arm/mach-shmobile/pm-sh7372.c | 209 +++++++++++++++++++++++++-
arch/arm/mach-shmobile/sleep-sh7372.S | 55 ++++++
3 files changed, 256 insertions(+), 11 deletions(-)
--- 0002/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h 2011-08-26 13:02:46.000000000 +0900
@@ -35,7 +35,8 @@ extern void sh7372_add_standard_devices(
extern void sh7372_clock_init(void);
extern void sh7372_pinmux_init(void);
extern void sh7372_pm_init(void);
-extern void sh7372_resume_core_standby(void);
+extern void sh7372_resume_core_standby_a3sm(void);
+extern int sh7372_do_idle_a3sm(unsigned long unused);
extern struct clk sh7372_extal1_clk;
extern struct clk sh7372_extal2_clk;
--- 0002/arch/arm/mach-shmobile/pm-sh7372.c
+++ work/arch/arm/mach-shmobile/pm-sh7372.c 2011-08-26 13:03:38.000000000 +0900
@@ -18,6 +18,8 @@
#include <linux/pm_runtime.h>
#include <linux/platform_device.h>
#include <linux/delay.h>
+#include <linux/irq.h>
+#include <linux/bitrev.h>
#include <asm/system.h>
#include <asm/io.h>
#include <asm/tlbflush.h>
@@ -25,14 +27,48 @@
#include <mach/common.h>
#include <mach/sh7372.h>
-#define SMFRAM 0xe6a70000
+/* DBG */
+#define DBGREG1 0xe6100020
+#define DBGREG9 0xe6100040
+
+/* CPGA */
#define SYSTBCR 0xe6150024
-#define SBAR 0xe6180020
-#define APARMBAREA 0xe6f10020
+#define MSTPSR0 0xe6150030
+#define MSTPSR1 0xe6150038
+#define MSTPSR2 0xe6150040
+#define MSTPSR3 0xe6150048
+#define MSTPSR4 0xe615004c
+#define PLLC01STPCR 0xe61500c8
+/* SYSC */
#define SPDCR 0xe6180008
#define SWUCR 0xe6180014
+#define SBAR 0xe6180020
+#define WUPSMSK 0xe618002c
+#define WUPSMSK2 0xe6180048
#define PSTR 0xe6180080
+#define WUPSFAC 0xe6180098
+#define IRQCR 0xe618022c
+#define IRQCR2 0xe6180238
+#define IRQCR3 0xe6180244
+#define IRQCR4 0xe6180248
+#define PDNSEL 0xe6180254
+
+/* INTC */
+#define ICR1A 0xe6900000
+#define ICR2A 0xe6900004
+#define ICR3A 0xe6900008
+#define ICR4A 0xe690000c
+#define INTMSK00A 0xe6900040
+#define INTMSK10A 0xe6900044
+#define INTMSK20A 0xe6900048
+#define INTMSK30A 0xe690004c
+
+/* MFIS */
+#define SMFRAM 0xe6a70000
+
+/* AP-System Core */
+#define APARMBAREA 0xe6f10020
#define PSTR_RETRIES 100
#define PSTR_DELAY_US 10
@@ -195,7 +231,7 @@ static int sh7372_do_idle_core_standby(u
static void sh7372_enter_core_standby(void)
{
/* set reset vector, translate 4k */
- __raw_writel(__pa(sh7372_resume_core_standby), SBAR);
+ __raw_writel(__pa(sh7372_resume_core_standby_a3sm), SBAR);
__raw_writel(0, APARMBAREA);
/* enter sleep mode with SYSTBCR to 0x10 */
@@ -207,7 +243,151 @@ static void sh7372_enter_core_standby(vo
__raw_writel(0, SBAR);
}
+static void sh7372_enter_a3sm_common(int pllc0_on)
+{
+ /* set reset vector, translate 4k */
+ __raw_writel(__pa(sh7372_resume_core_standby_a3sm), SBAR);
+ __raw_writel(0, APARMBAREA);
+
+ if (pllc0_on)
+ __raw_writel(0, PLLC01STPCR);
+ else
+ __raw_writel(1 << 28, PLLC01STPCR);
+
+ __raw_writel(0, PDNSEL); /* power-down A3SM only, not A4S */
+ __raw_readl(WUPSFAC); /* read wakeup int. factor before sleep */
+ cpu_suspend(0, sh7372_do_idle_a3sm);
+ __raw_readl(WUPSFAC); /* read wakeup int. factor after wakeup */
+
+ /* disable reset vector translation */
+ __raw_writel(0, SBAR);
+}
+
+static int sh7372_a3sm_valid(unsigned long *mskp, unsigned long *msk2p)
+{
+ unsigned long mstpsr0, mstpsr1, mstpsr2, mstpsr3, mstpsr4;
+ unsigned long msk, msk2;
+
+ /* check active clocks to determine potential wakeup sources */
+
+ mstpsr0 = __raw_readl(MSTPSR0);
+ if ((mstpsr0 & 0x00000003) != 0x00000003) {
+ pr_debug("sh7372 mstpsr0 0x%08lx\n", mstpsr0);
+ return 0;
+ }
+
+ mstpsr1 = __raw_readl(MSTPSR1);
+ if ((mstpsr1 & 0xff079b7f) != 0xff079b7f) {
+ pr_debug("sh7372 mstpsr1 0x%08lx\n", mstpsr1);
+ return 0;
+ }
+
+ mstpsr2 = __raw_readl(MSTPSR2);
+ if ((mstpsr2 & 0x000741ff) != 0x000741ff) {
+ pr_debug("sh7372 mstpsr2 0x%08lx\n", mstpsr2);
+ return 0;
+ }
+
+ mstpsr3 = __raw_readl(MSTPSR3);
+ if ((mstpsr3 & 0x1a60f010) != 0x1a60f010) {
+ pr_debug("sh7372 mstpsr3 0x%08lx\n", mstpsr3);
+ return 0;
+ }
+
+ mstpsr4 = __raw_readl(MSTPSR4);
+ if ((mstpsr4 & 0x00008cf0) != 0x00008cf0) {
+ pr_debug("sh7372 mstpsr4 0x%08lx\n", mstpsr4);
+ return 0;
+ }
+
+ msk = 0;
+ msk2 = 0;
+
+ /* make bitmaps of limited number of wakeup sources */
+
+ if ((mstpsr2 & (1 << 23)) = 0) /* SPU2 */
+ msk |= 1 << 31;
+
+ if ((mstpsr2 & (1 << 12)) = 0) /* MFI_MFIM */
+ msk |= 1 << 21;
+
+ if ((mstpsr4 & (1 << 3)) = 0) /* KEYSC */
+ msk |= 1 << 2;
+
+ if ((mstpsr1 & (1 << 24)) = 0) /* CMT0 */
+ msk |= 1 << 1;
+
+ if ((mstpsr3 & (1 << 29)) = 0) /* CMT1 */
+ msk |= 1 << 1;
+
+ if ((mstpsr4 & (1 << 0)) = 0) /* CMT2 */
+ msk |= 1 << 1;
+
+ if ((mstpsr2 & (1 << 13)) = 0) /* MFI_MFIS */
+ msk2 |= 1 << 17;
+
+ *mskp = msk;
+ *msk2p = msk2;
+
+ return 1;
+}
+
+static void sh7372_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
+{
+ u16 tmp, irqcr1, irqcr2;
+ int k;
+
+ irqcr1 = 0;
+ irqcr2 = 0;
+
+ /* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
+ for (k = 0; k <= 7; k++) {
+ tmp = (icr >> ((7 - k) * 4)) & 0xf;
+ irqcr1 |= (tmp & 0x03) << (k * 2);
+ irqcr2 |= (tmp >> 2) << (k * 2);
+ }
+
+ *irqcr1p = irqcr1;
+ *irqcr2p = irqcr2;
+}
+
+static void sh7372_setup_a3sm(unsigned long msk, unsigned long msk2)
+{
+ u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
+ unsigned long tmp;
+
+ /* read IRQ0A -> IRQ15A mask */
+ tmp = bitrev8(__raw_readb(INTMSK00A));
+ tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
+
+ /* setup WUPSMSK from clocks and external IRQ mask */
+ msk = (~msk & 0xc030000f) | (tmp << 4);
+ __raw_writel(msk, WUPSMSK);
+
+ /* propage level/edge trigger for external IRQ 0->15 */
+ sh7372_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
+ sh7372_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
+ __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
+ __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
+
+ /* read IRQ16A -> IRQ31A mask */
+ tmp = bitrev8(__raw_readb(INTMSK20A));
+ tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
+
+ /* setup WUPSMSK2 from clocks and external IRQ mask */
+ msk2 = (~msk2 & 0x00030000) | tmp;
+ __raw_writel(msk2, WUPSMSK2);
+
+ /* propage level/edge trigger for external IRQ 16->31 */
+ sh7372_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
+ sh7372_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
+ __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
+ __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
+}
+
+
#ifdef CONFIG_CPU_IDLE
+
static void sh7372_cpuidle_setup(struct cpuidle_device *dev)
{
struct cpuidle_state *state;
@@ -235,9 +415,25 @@ static void sh7372_cpuidle_init(void) {}
#endif
#ifdef CONFIG_SUSPEND
+
static int sh7372_enter_suspend(suspend_state_t suspend_state)
{
- sh7372_enter_core_standby();
+ unsigned long msk, msk2;
+
+ /* check active clocks to determine potential wakeup sources */
+ if (sh7372_a3sm_valid(&msk, &msk2)) {
+
+ /* convert INTC mask and sense to SYSC mask and sense */
+ sh7372_setup_a3sm(msk, msk2);
+
+ /* enter A3SM sleep with PLLC0 off */
+ pr_debug("entering A3SM\n");
+ sh7372_enter_a3sm_common(0);
+ } else {
+ /* default to Core Standby that supports all wakeup sources */
+ pr_debug("entering Core Standby\n");
+ sh7372_enter_core_standby();
+ }
return 0;
}
@@ -249,9 +445,6 @@ static void sh7372_suspend_init(void)
static void sh7372_suspend_init(void) {}
#endif
-#define DBGREG1 0xe6100020
-#define DBGREG9 0xe6100040
-
void __init sh7372_pm_init(void)
{
/* enable DBG hardware block to kick SYSC */
--- 0002/arch/arm/mach-shmobile/sleep-sh7372.S
+++ work/arch/arm/mach-shmobile/sleep-sh7372.S 2011-08-26 13:19:38.000000000 +0900
@@ -36,7 +36,58 @@
.align 12
.text
- .global sh7372_resume_core_standby
-sh7372_resume_core_standby:
+ .global sh7372_resume_core_standby_a3sm
+sh7372_resume_core_standby_a3sm:
ldr pc, 1f
1: .long cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
+
+ .global sh7372_do_idle_a3sm
+sh7372_do_idle_a3sm:
+ /*
+ * Clear the SCTLR.C bit to prevent further data cache
+ * allocation. Clearing SCTLR.C would make all the data accesses
+ * strongly ordered and would not hit the cache.
+ */
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 << 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
+ /* disable L2 cache in the aux control register */
+ mrc p15, 0, r10, c1, c0, 1
+ bic r10, r10, #2
+ mcr p15, 0, r10, c1, c0, 1
+
+ /*
+ * Invalidate data cache again.
+ */
+ ldr r1, kernel_flush
+ blx r1
+ /*
+ * The kernel doesn't interwork: v7_flush_dcache_all in particluar will
+ * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
+ * This sequence switches back to ARM. Note that .align may insert a
+ * nop: bx pc needs to be word-aligned in order to work.
+ */
+ THUMB( .thumb )
+ THUMB( .align )
+ THUMB( bx pc )
+ THUMB( nop )
+ .arm
+
+ /* Data memory barrier and Data sync barrier */
+ dsb
+ dmb
+
+#define SPDCR 0xe6180008
+#define A3SM (1 << 12)
+
+ /* A3SM power down */
+ ldr r0, =SPDCR
+ ldr r1, £SM
+ str r1, [r0]
+1:
+ b 1b
+
+kernel_flush:
+ .word v7_flush_dcache_all
^ permalink raw reply [flat|nested] 7+ messages in thread* [PATCH 02/03] ARM: mach-shmobile: sh7372 generic board support via DT
2011-06-30 9:47 [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP prototype support Magnus Damm
2011-08-26 6:43 ` [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP support Magnus Damm
2011-09-23 5:52 ` [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SM support Magnus Damm
@ 2012-03-07 5:53 ` Magnus Damm
2012-03-07 13:41 ` Arnd Bergmann
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Magnus Damm @ 2012-03-07 5:53 UTC (permalink / raw)
To: linux-sh
From: Magnus Damm <damm@opensource.se>
Add generic DT board support for the sh7372 SoC.
SCIF serial ports and timers are kept as regular
platform devices. Other on-chip and on-board devices
should be configured via the device tree.
Tested on the mackerel board via kexec using a zImage
kernel with an appended dtb.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/setup-sh7372.c | 39 +++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
--- 0034/arch/arm/mach-shmobile/setup-sh7372.c
+++ work/arch/arm/mach-shmobile/setup-sh7372.c 2012-03-06 14:04:36.000000000 +0900
@@ -1082,3 +1082,42 @@ void __init sh7372_add_early_devices(voi
/* override timer setup with soc-specific code */
shmobile_timer.init = sh7372_earlytimer_init;
}
+
+#ifdef CONFIG_USE_OF
+
+void __init sh7372_add_early_devices_dt(void)
+{
+ shmobile_setup_delay(800, 1, 3); /* Cortex-A8 @ 800MHz */
+
+ early_platform_add_devices(sh7372_early_devices,
+ ARRAY_SIZE(sh7372_early_devices));
+
+ /* setup early console here as well */
+ shmobile_setup_console();
+}
+
+void __init sh7372_add_standard_devices_dt(void)
+{
+ /* clocks are setup late during boot in the case of DT */
+ sh7372_clock_init();
+
+ platform_add_devices(sh7372_early_devices,
+ ARRAY_SIZE(sh7372_early_devices));
+}
+
+static const char *sh7372_boards_compat_dt[] __initdata = {
+ "renesas,sh7372",
+ NULL,
+};
+
+DT_MACHINE_START(SH7372_DT, "Generic SH7372 (Flattened Device Tree)")
+ .map_io = sh7372_map_io,
+ .init_early = sh7372_add_early_devices_dt,
+ .init_irq = sh7372_init_irq,
+ .handle_irq = shmobile_handle_irq_intc,
+ .init_machine = sh7372_add_standard_devices_dt,
+ .timer = &shmobile_timer,
+ .dt_compat = sh7372_boards_compat_dt,
+MACHINE_END
+
+#endif /* CONFIG_USE_OF */
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 02/03] ARM: mach-shmobile: sh7372 generic board support via DT
2011-06-30 9:47 [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP prototype support Magnus Damm
` (2 preceding siblings ...)
2012-03-07 5:53 ` [PATCH 02/03] ARM: mach-shmobile: sh7372 generic board support via DT Magnus Damm
@ 2012-03-07 13:41 ` Arnd Bergmann
2012-03-09 13:12 ` Magnus Damm
2012-03-09 21:41 ` Arnd Bergmann
5 siblings, 0 replies; 7+ messages in thread
From: Arnd Bergmann @ 2012-03-07 13:41 UTC (permalink / raw)
To: linux-sh
On Wednesday 07 March 2012, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> Add generic DT board support for the sh7372 SoC.
>
> SCIF serial ports and timers are kept as regular
> platform devices. Other on-chip and on-board devices
> should be configured via the device tree.
>
> Tested on the mackerel board via kexec using a zImage
> kernel with an appended dtb.
This looks good as a start, very nice!
>
> arch/arm/mach-shmobile/setup-sh7372.c | 39 +++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
I think so far everyone has added the device tree source files to the kernel
when they did the conversion. I'd suggest you do that, too.
> --- 0034/arch/arm/mach-shmobile/setup-sh7372.c
> +++ work/arch/arm/mach-shmobile/setup-sh7372.c 2012-03-06 14:04:36.000000000 +0900
> @@ -1082,3 +1082,42 @@ void __init sh7372_add_early_devices(voi
> /* override timer setup with soc-specific code */
> shmobile_timer.init = sh7372_earlytimer_init;
> }
> +
> +#ifdef CONFIG_USE_OF
> +
> +void __init sh7372_add_early_devices_dt(void)
> +{
> + shmobile_setup_delay(800, 1, 3); /* Cortex-A8 @ 800MHz */
> +
> + early_platform_add_devices(sh7372_early_devices,
> + ARRAY_SIZE(sh7372_early_devices));
> +
> + /* setup early console here as well */
> + shmobile_setup_console();
> +}
Are these always 800MHz? Maybe it would be better to read the "clock-frequency"
property from the root node and use the value that is given for a particular
board.
Arnd
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 02/03] ARM: mach-shmobile: sh7372 generic board support via DT
2011-06-30 9:47 [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP prototype support Magnus Damm
` (3 preceding siblings ...)
2012-03-07 13:41 ` Arnd Bergmann
@ 2012-03-09 13:12 ` Magnus Damm
2012-03-09 21:41 ` Arnd Bergmann
5 siblings, 0 replies; 7+ messages in thread
From: Magnus Damm @ 2012-03-09 13:12 UTC (permalink / raw)
To: linux-sh
Hi Arnd,
On Wed, Mar 7, 2012 at 10:41 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 07 March 2012, Magnus Damm wrote:
>> From: Magnus Damm <damm@opensource.se>
>>
>> Add generic DT board support for the sh7372 SoC.
>>
>> SCIF serial ports and timers are kept as regular
>> platform devices. Other on-chip and on-board devices
>> should be configured via the device tree.
>>
>> Tested on the mackerel board via kexec using a zImage
>> kernel with an appended dtb.
>
> This looks good as a start, very nice!
Thanks for checking the code! I appreciate your input!
>> arch/arm/mach-shmobile/setup-sh7372.c | 39 +++++++++++++++++++++++++++++++++
>> 1 file changed, 39 insertions(+)
>
> I think so far everyone has added the device tree source files to the kernel
> when they did the conversion. I'd suggest you do that, too.
Sure, that indeed sounds like a good idea. I intend to hack on V2 next
week and that is most likely a good time to include dts and dtsi
files. At this point they are rather boring due to interrupt bindings
not working, so we cannot even hook up board specific ethernet
controllers via the device tree due to lack of interrupts. My plan is
to hack up some IRQ domain prototype code to play more with the DT and
also create some proper dts/dtsi files.
>> --- 0034/arch/arm/mach-shmobile/setup-sh7372.c
>> +++ work/arch/arm/mach-shmobile/setup-sh7372.c 2012-03-06 14:04:36.000000000 +0900
>> @@ -1082,3 +1082,42 @@ void __init sh7372_add_early_devices(voi
>> /* override timer setup with soc-specific code */
>> shmobile_timer.init = sh7372_earlytimer_init;
>> }
>> +
>> +#ifdef CONFIG_USE_OF
>> +
>> +void __init sh7372_add_early_devices_dt(void)
>> +{
>> + shmobile_setup_delay(800, 1, 3); /* Cortex-A8 @ 800MHz */
>> +
>> + early_platform_add_devices(sh7372_early_devices,
>> + ARRAY_SIZE(sh7372_early_devices));
>> +
>> + /* setup early console here as well */
>> + shmobile_setup_console();
>> +}
>
> Are these always 800MHz? Maybe it would be better to read the "clock-frequency"
> property from the root node and use the value that is given for a particular
> board.
You are correct that the CPU frequency may change depending on a few
things. At this point the actual hardware is configured to use with
whatever value the boot loader has setup for us, which should work
well with the worst case loops-per-jiffy value based on the spec of
the SoC.
My idea with the code above is keep it as simple as possible and be
fail safe. So the 800 Mhz value in this case is coming from the sh7372
data sheet as the maximum allowed frequency for sh7372. The point in
setting the maximum allowed frequency is to come up with a OK worst
case loops per jiffy value without using any timer during early boot.
The non-DT mach-shmobile platforms are using early platform driver
code to allow setting up a timer early during boot, and this timer is
then used with the common calibrate delay loops-per-jiffy calculation
code. With this shmobile_setup_delay() function we can delay the timer
creation until whenever the normal driver model code is setting up
drivers. This should make it easy to use DT for timers too.
So, as you pointed out, the frequency setting may not be fixed. Both
the boot loader setting may be different and we may also use frequency
scaling over time to adjust the frequency. Whenever we change the
frequency we do want to update the loops-per-jiffy to reflect the new
value. Ideally I'd like to use the common calibrate delay code to
figure out the timing in a generic way, and this is something that
certainly can be done whenever the full driver model is up and
running. Or at least we could have some shared ARM core specific delay
presets somewhere under arch/arm.
Initially my patch had some late initcall that recalculated the delay
after the driver model (and also timers) have been initialized. This
looked like it would work in theory and it would match well with
whatever that needs to be done together with cpu frequency scaling.
This sounds a bit like what you requested. However, it seems to me
that the generic calibrate delay code that ARM is using doesn't allow
updating the loops-per-jiffy value! The loops-per-jiffy value is
stored in a static per-cpu variable and the code does not seem to like
recalculating the delay after the first time. Perhaps someone is
working on fixing that up. Architectures like blackfin do their own
thing and do not make use of the generic calibrate delay code, and I
believe they update the loops-per-jiffy directly from their cpufreq
drivers. ARM platforms that do frequency scaling must use some other
technique.
Anyway, so based on this I decided to go with a static worst case
frequency value to calculate a safe loops-per-jiffy value and at the
same time add "adjust generic calibrate delay code to allow updating
frequency over time" to my TODO list. I feel it is better to solve
that issue in a generic way and use the common calibrate delay code to
calculate a proper delay value instead of extending my local
mach-shmobile code more.
Does it sound sane?
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 02/03] ARM: mach-shmobile: sh7372 generic board support via DT
2011-06-30 9:47 [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP prototype support Magnus Damm
` (4 preceding siblings ...)
2012-03-09 13:12 ` Magnus Damm
@ 2012-03-09 21:41 ` Arnd Bergmann
5 siblings, 0 replies; 7+ messages in thread
From: Arnd Bergmann @ 2012-03-09 21:41 UTC (permalink / raw)
To: linux-sh
On Friday 09 March 2012, Magnus Damm wrote:
> >> arch/arm/mach-shmobile/setup-sh7372.c | 39 +++++++++++++++++++++++++++++++++
> >> 1 file changed, 39 insertions(+)
> >
> > I think so far everyone has added the device tree source files to the kernel
> > when they did the conversion. I'd suggest you do that, too.
>
> Sure, that indeed sounds like a good idea. I intend to hack on V2 next
> week and that is most likely a good time to include dts and dtsi
> files. At this point they are rather boring due to interrupt bindings
> not working, so we cannot even hook up board specific ethernet
> controllers via the device tree due to lack of interrupts. My plan is
> to hack up some IRQ domain prototype code to play more with the DT and
> also create some proper dts/dtsi files.
Ok. Note that a number of people are currently working on IRQ controller
bindings for various platforms, and some of that is now in the arm-soc
tree but not in v3.3. Best look at what others are doing so you don't
end up duplicating too much work.
> >> --- 0034/arch/arm/mach-shmobile/setup-sh7372.c
> >> +++ work/arch/arm/mach-shmobile/setup-sh7372.c 2012-03-06 14:04:36.000000000 +0900
> >> @@ -1082,3 +1082,42 @@ void __init sh7372_add_early_devices(voi
> >> /* override timer setup with soc-specific code */
> >> shmobile_timer.init = sh7372_earlytimer_init;
> >> }
> >> +
> >> +#ifdef CONFIG_USE_OF
> >> +
> >> +void __init sh7372_add_early_devices_dt(void)
> >> +{
> >> + shmobile_setup_delay(800, 1, 3); /* Cortex-A8 @ 800MHz */
> >> +
> >> + early_platform_add_devices(sh7372_early_devices,
> >> + ARRAY_SIZE(sh7372_early_devices));
> >> +
> >> + /* setup early console here as well */
> >> + shmobile_setup_console();
> >> +}
> >
> > Are these always 800MHz? Maybe it would be better to read the "clock-frequency"
> > property from the root node and use the value that is given for a particular
> > board.
>
> You are correct that the CPU frequency may change depending on a few
> things. At this point the actual hardware is configured to use with
> whatever value the boot loader has setup for us, which should work
> well with the worst case loops-per-jiffy value based on the spec of
> the SoC.
>
> My idea with the code above is keep it as simple as possible and be
> fail safe. So the 800 Mhz value in this case is coming from the sh7372
> data sheet as the maximum allowed frequency for sh7372. The point in
> setting the maximum allowed frequency is to come up with a OK worst
> case loops per jiffy value without using any timer during early boot.
> The non-DT mach-shmobile platforms are using early platform driver
> code to allow setting up a timer early during boot, and this timer is
> then used with the common calibrate delay loops-per-jiffy calculation
> code. With this shmobile_setup_delay() function we can delay the timer
> creation until whenever the normal driver model code is setting up
> drivers. This should make it easy to use DT for timers too.
Ok.
> Initially my patch had some late initcall that recalculated the delay
> after the driver model (and also timers) have been initialized. This
> looked like it would work in theory and it would match well with
> whatever that needs to be done together with cpu frequency scaling.
> This sounds a bit like what you requested. However, it seems to me
> that the generic calibrate delay code that ARM is using doesn't allow
> updating the loops-per-jiffy value! The loops-per-jiffy value is
> stored in a static per-cpu variable and the code does not seem to like
> recalculating the delay after the first time. Perhaps someone is
> working on fixing that up. Architectures like blackfin do their own
> thing and do not make use of the generic calibrate delay code, and I
> believe they update the loops-per-jiffy directly from their cpufreq
> drivers. ARM platforms that do frequency scaling must use some other
> technique.
I think we do the same on ARM, at least that's what I got from reading
drivers/cpufreq/omap-cpufreq.c, which updates
per_cpu(cpu_data, i).loops_per_jiffy in a loop when changing the
frequency.
> Anyway, so based on this I decided to go with a static worst case
> frequency value to calculate a safe loops-per-jiffy value and at the
> same time add "adjust generic calibrate delay code to allow updating
> frequency over time" to my TODO list. I feel it is better to solve
> that issue in a generic way and use the common calibrate delay code to
> calculate a proper delay value instead of extending my local
> mach-shmobile code more.
>
> Does it sound sane?
Yes, sounds good for now.
Arnd
^ permalink raw reply [flat|nested] 7+ messages in thread