Skip to contentSkip to conversation

ARM: mach-shmobile: sh7377 and G4EVM pinmux support

PATCH In review NISHIMOTO Hiroki 2 participants 2 messages Feb 12, 2010 – Feb 15, 2010

Subsystems (4)
Arm (32-bit) Arm sub-architectures SuperH Arm/RISC-V/Renesas architecture
lore
Share & tools
lore

NISHIMOTO Hiroki

author
#0 lore raw

PATCH 1/1 ARM: mach-shmobile: sh7377 and G4EVM pinmux support

Add support for the sh 7377 pinmux using drivers/sh/pfc.c and some LEDs on G4EVM.

Signed-off-by NISHIMOTO Hiroki <[email protected]>
---
 arch/arm/mach-shmobile/Kconfig               |    1 +
 arch/arm/mach-shmobile/Makefile              |    1 +
 arch/arm/mach-shmobile/board-g4evm.c         |   24 +
 arch/arm/mach-shmobile/include/mach/common.h |    1 +
 arch/arm/mach-shmobile/include/mach/sh7377.h |  360 ++++++
 arch/arm/mach-shmobile/pfc-sh7377.c          | 1766 ++++++++++++++++++++++++++
 6 files changed, 2153 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/include/mach/sh7377.h
 create mode 100644 arch/arm/mach-shmobile/pfc-sh7377.c
arch/arm/mach-shmobile/Kconfig +1 -0
index 639df5f..a96c25a 100644
@@ -36,6 +36,7 @@ config MACH_G3EVM
 config MACH_G4EVM
 	bool "G4EVM board"
 	depends on ARCH_SH7377
+	select ARCH_REQUIRE_GPIOLIB
 
 config MACH_AP4EVB
 	bool "AP4EVB board"
arch/arm/mach-shmobile/Makefile +1 -0
index 9ef2630..ce01951 100644
@@ -12,6 +12,7 @@ obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o clock-sh7367.o intc-sh7372.o
 
 # Pinmux setup
 pfc-$(CONFIG_ARCH_SH7367)	:= pfc-sh7367.o
+pfc-$(CONFIG_ARCH_SH7377)	:= pfc-sh7377.o
 obj-$(CONFIG_GENERIC_GPIO)	+= $(pfc-y)
 
 # Board objects
arch/arm/mach-shmobile/board-g4evm.c +24 -0
index 0ddde03..ef4b0f5 100644
@@ -27,6 +27,8 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/physmap.h>
 #include <linux/io.h>
+#include <linux/gpio.h>
+#include <mach/sh7377.h>
 #include <mach/common.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>

@@ -113,6 +115,28 @@ static void __init g4evm_map_io(void)
 
 static void __init g4evm_init(void)
 {
+	sh7377_pinmux_init();
+
+	/* Lit DS14 LED */
+	gpio_request(GPIO_PORT109, NULL);
+	gpio_direction_output(GPIO_PORT109, 1);
+	gpio_export(GPIO_PORT109, 1);
+
+	/* Lit DS15 LED */
+	gpio_request(GPIO_PORT110, NULL);
+	gpio_direction_output(GPIO_PORT110, 1);
+	gpio_export(GPIO_PORT110, 1);
+
+	/* Lit DS16 LED */
+	gpio_request(GPIO_PORT112, NULL);
+	gpio_direction_output(GPIO_PORT112, 1);
+	gpio_export(GPIO_PORT112, 1);
+
+	/* Lit DS17 LED */
+	gpio_request(GPIO_PORT113, NULL);
+	gpio_direction_output(GPIO_PORT113, 1);
+	gpio_export(GPIO_PORT113, 1);
+
 	sh7377_add_standard_devices();
 
 	platform_add_devices(g4evm_devices, ARRAY_SIZE(g4evm_devices));
arch/arm/mach-shmobile/include/mach/common.h +1 -0
index a484600..d6f927b 100644
@@ -13,6 +13,7 @@ extern void sh7367_pinmux_init(void);
 extern void sh7377_init_irq(void);
 extern void sh7377_add_early_devices(void);
 extern void sh7377_add_standard_devices(void);
+extern void sh7377_pinmux_init(void);
 
 extern void sh7372_init_irq(void);
 extern void sh7372_add_early_devices(void);
arch/arm/mach-shmobile/include/mach/sh7377.h new file +360 -0

360 lines not on this page · raw message

arch/arm/mach-shmobile/pfc-sh7377.c new file +1766 -0

1,766 lines not on this page · raw message

Signature · 1 line
1.6.3.3
#1 lore raw
Quoted 2 lines · NISHIMOTO Hiroki

Add support for the sh 7377 pinmux using drivers/sh/pfc.c and some LEDs on G4EVM.

Quoted 2 lines · NISHIMOTO Hiroki

Add G4EVM platform data and a magic setup sequence to initialize the r8a66597 block aka USBHS in sh7377.

I'll add these for the 2.6.34 queue, however..

Quoted 5 lines
(quoted diff) +1 -0
@@ -137,6 +179,23 @@ static void __init g4evm_init(void)
 	gpio_direction_output(GPIO_PORT113, 1);
 	gpio_export(GPIO_PORT113, 1);
 
+	/* USBHS */

Review static void __init g4evm_init(void) · line 192

Quoted 10 lines
(quoted diff) +10 -0
+	gpio_request(GPIO_FN_VBUS_0, NULL);
+	gpio_request(GPIO_FN_PWEN, NULL);
+	gpio_request(GPIO_FN_OVCN, NULL);
+	gpio_request(GPIO_FN_OVCN2, NULL);
+	gpio_request(GPIO_FN_EXTLP, NULL);
+	gpio_request(GPIO_FN_IDIN, NULL);
+
+	/* enable clock in SMSTPCR3 */
+	__raw_writel(__raw_readl(0xe615013c) & ~(1 << 22), 0xe615013c);
+

This is unacceptable (and yes, I realize you are just copying this verbatim from G3, so I am not singling anyone out). We have the clock framework for a reason, and the only reason to do these sort of hacks is because the clock framework support hasn't been sufficiently developed for this CPU.

I'll make it simple -- I will not be applying any additional patches that toggle clock or module stop bits independently outside of the clock framework. If the clock framework isn't being treated as a priority now, this is just going to turn in to a complete mess. The clock framework should be the only thing that is a priority for these parts at the moment, and any effort put in to workarounds is just going to be dropped on the floor.

The clock framework is a requirement, not a suggestion. Failure to adhere to this simple principle and organize priorities accordingly will result in no additional blocks being clocked. Prioritize accordingly.

In any event, as the merge window is nigh upon us, this should provide ample opportunity to get the clock framework implemented properly for 2.6.35, at which point we can start enabling other blocks again.