* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Hi Olof,
The following changes since commit a9cc2c88aa9514296f868c9ea740b8addc7b8115:
Merge branches 'soc' and 'pinmux' into boards-base (2013-03-18 21:26:33 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards-for-v3.10
for you to fetch changes up to 48296a13e7f411402f080d0603724623fa3eee14:
ARM: shmobile: kzm9g: correct smsc regulator registration (2013-03-18 21:27:03 +0900)
----------------------------------------------------------------
Renesas ARM-based SoC board updates for v3.10
This is based on a merge of the following:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-pinmux-for-v3.10
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-for-v3.10
----------------------------------------------------------------
Arnd Bergmann (1):
ARM: shmobile: mark mackerel sh_mmcif_device __maybe_unused
Guennadi Liakhovetski (6):
ARM: shmobile: use GPIO SD-card detection on armadillo800eva
ARM: shmobile: switch SDHI0 to GPIO regulator on armadillo800eva
ARM: shmobile: streamline mackerel SD and MMC devices
ARM: shmobile: parse DT and configure pinmux early on kzm9g-reference
ARM: shmobile: SDHI and MMCIF interfaces to kzm9g-reference
ARM: shmobile: simplify kzm9g Kconfig dependencies
Kuninori Morimoto (1):
ARM: shmobile: marzen: Use gic_iid macro for ICCIAR / interrupt ID
Simon Horman (5):
ARM: shmobile: marzen: Reference DT implementation
ARM: shmobile: kzm9g: Reference DT implementation
ARM: shmobile: kzm9g: Remove warning about SMP
ARM: shmobile: kzm9g: Trim reference DT_MACHINE_START
ARM: shmobile: kzm9g: correct smsc regulator registration
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/r8a7779-marzen-reference.dts | 47 +++++++++
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 77 +++++++++++++++
arch/arm/mach-shmobile/Kconfig | 27 ++++++
arch/arm/mach-shmobile/Makefile | 2 +
arch/arm/mach-shmobile/board-armadillo800eva.c | 111 ++++++++++++++++++----
arch/arm/mach-shmobile/board-kzm9g-reference.c | 108 +++++++++++++++++++++
arch/arm/mach-shmobile/board-kzm9g.c | 4 +-
arch/arm/mach-shmobile/board-mackerel.c | 115 ++++++++++++-----------
arch/arm/mach-shmobile/board-marzen-reference.c | 75 +++++++++++++++
arch/arm/mach-shmobile/board-marzen.c | 12 +--
11 files changed, 496 insertions(+), 84 deletions(-)
create mode 100644 arch/arm/boot/dts/r8a7779-marzen-reference.dts
create mode 100644 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
create mode 100644 arch/arm/mach-shmobile/board-kzm9g-reference.c
create mode 100644 arch/arm/mach-shmobile/board-marzen-reference.c
^ permalink raw reply [flat|nested] 114+ messages in thread* [PATCH 01/13] ARM: shmobile: use GPIO SD-card detection on armadillo800eva
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Switch SDHI0 and SDHI1 SD-card interfaces on armadillo800eva to using GPIO
card detection, which provides maximum power saving and automatically
selects IRQ or polling mode, depending on the CD GPIO capability.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 04eff93..60694e8 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -579,10 +579,10 @@ static struct regulator_consumer_supply fixed3v3_power_consumers[] static struct sh_mobile_sdhi_info sdhi0_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI0_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI0_RX,
- .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |\
- MMC_CAP_NEEDS_POLL,
+ .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
.tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
- .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
+ .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
+ .cd_gpio = GPIO_PORT167,
};
static struct resource sdhi0_resources[] = {
@@ -623,7 +623,9 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
.dma_slave_rx = SHDMA_SLAVE_SDHI1_RX,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
.tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
- .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
+ .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
+ /* Port72 cannot generate IRQs, will be used in polling mode. */
+ .cd_gpio = GPIO_PORT72,
};
static struct resource sdhi1_resources[] = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 01/13] ARM: shmobile: use GPIO SD-card detection on armadillo800eva
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Switch SDHI0 and SDHI1 SD-card interfaces on armadillo800eva to using GPIO
card detection, which provides maximum power saving and automatically
selects IRQ or polling mode, depending on the CD GPIO capability.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 04eff93..60694e8 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -579,10 +579,10 @@ static struct regulator_consumer_supply fixed3v3_power_consumers[] =
static struct sh_mobile_sdhi_info sdhi0_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI0_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI0_RX,
- .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |\
- MMC_CAP_NEEDS_POLL,
+ .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
.tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
- .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
+ .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
+ .cd_gpio = GPIO_PORT167,
};
static struct resource sdhi0_resources[] = {
@@ -623,7 +623,9 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
.dma_slave_rx = SHDMA_SLAVE_SDHI1_RX,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
.tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
- .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
+ .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
+ /* Port72 cannot generate IRQs, will be used in polling mode. */
+ .cd_gpio = GPIO_PORT72,
};
static struct resource sdhi1_resources[] = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 02/13] ARM: shmobile: switch SDHI0 to GPIO regulator on armadillo800eva
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
When regulators are used with MMC devices, explicitly provided OCR masks
are ignored, they can be removed from platform data. Also switch SDHI0
from fixed regulator with hard-wired GPIO levels to a proper GPIO regulator
instance to enable dynamic voltage switching.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 101 ++++++++++++++++++++----
1 file changed, 86 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 60694e8..f322a18 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -28,8 +28,10 @@
#include <linux/platform_device.h>
#include <linux/gpio.h>
#include <linux/gpio_keys.h>
+#include <linux/regulator/driver.h>
#include <linux/pinctrl/machine.h>
#include <linux/regulator/fixed.h>
+#include <linux/regulator/gpio-regulator.h>
#include <linux/regulator/machine.h>
#include <linux/sh_eth.h>
#include <linux/videodev2.h>
@@ -555,17 +557,94 @@ static struct platform_device gpio_keys_device = {
},
};
-/* Fixed 3.3V regulator to be used by SDHI0, SDHI1, MMCIF */
-static struct regulator_consumer_supply fixed3v3_power_consumers[] -{
- REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.0"),
- REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.0"),
+/* Fixed 3.3V regulator to be used by SDHI1, MMCIF */
+static struct regulator_consumer_supply fixed3v3_power_consumers[] = {
REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.1"),
REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.1"),
REGULATOR_SUPPLY("vmmc", "sh_mmcif"),
REGULATOR_SUPPLY("vqmmc", "sh_mmcif"),
};
+/* Fixed 3.3V regulator to be used by SDHI0 */
+static struct regulator_consumer_supply vcc_sdhi0_consumers[] = {
+ REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.0"),
+};
+
+static struct regulator_init_data vcc_sdhi0_init_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vcc_sdhi0_consumers),
+ .consumer_supplies = vcc_sdhi0_consumers,
+};
+
+static struct fixed_voltage_config vcc_sdhi0_info = {
+ .supply_name = "SDHI0 Vcc",
+ .microvolts = 3300000,
+ .gpio = GPIO_PORT75,
+ .enable_high = 1,
+ .init_data = &vcc_sdhi0_init_data,
+};
+
+static struct platform_device vcc_sdhi0 = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &vcc_sdhi0_info,
+ },
+};
+
+/* 1.8 / 3.3V SDHI0 VccQ regulator */
+static struct regulator_consumer_supply vccq_sdhi0_consumers[] = {
+ REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.0"),
+};
+
+static struct regulator_init_data vccq_sdhi0_init_data = {
+ .constraints = {
+ .input_uV = 3300000,
+ .min_uV = 1800000,
+ .max_uV = 3300000,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vccq_sdhi0_consumers),
+ .consumer_supplies = vccq_sdhi0_consumers,
+};
+
+static struct gpio vccq_sdhi0_gpios[] = {
+ {GPIO_PORT17, GPIOF_OUT_INIT_LOW, "vccq-sdhi0" },
+};
+
+static struct gpio_regulator_state vccq_sdhi0_states[] = {
+ { .value = 3300000, .gpios = (0 << 0) },
+ { .value = 1800000, .gpios = (1 << 0) },
+};
+
+static struct gpio_regulator_config vccq_sdhi0_info = {
+ .supply_name = "vqmmc",
+
+ .enable_gpio = GPIO_PORT74,
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+
+ .gpios = vccq_sdhi0_gpios,
+ .nr_gpios = ARRAY_SIZE(vccq_sdhi0_gpios),
+
+ .states = vccq_sdhi0_states,
+ .nr_states = ARRAY_SIZE(vccq_sdhi0_states),
+
+ .type = REGULATOR_VOLTAGE,
+ .init_data = &vccq_sdhi0_init_data,
+};
+
+static struct platform_device vccq_sdhi0 = {
+ .name = "gpio-regulator",
+ .id = -1,
+ .dev = {
+ .platform_data = &vccq_sdhi0_info,
+ },
+};
+
/* SDHI0 */
/*
* FIXME
@@ -580,7 +659,6 @@ static struct sh_mobile_sdhi_info sdhi0_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI0_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI0_RX,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
- .tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
.cd_gpio = GPIO_PORT167,
};
@@ -622,7 +700,6 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI1_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI1_RX,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
- .tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
/* Port72 cannot generate IRQs, will be used in polling mode. */
.cd_gpio = GPIO_PORT72,
@@ -673,7 +750,6 @@ static const struct pinctrl_map eva_sdhi1_pinctrl_map[] = {
/* MMCIF */
static struct sh_mmcif_plat_data sh_mmcif_plat = {
.sup_pclk = 0,
- .ocr = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
.caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_8_BIT_DATA |
MMC_CAP_NONREMOVABLE,
@@ -926,6 +1002,8 @@ static struct platform_device *eva_devices[] __initdata = {
&fsi_wm8978_device,
&fsi_hdmi_device,
&i2c_gpio_device,
+ &vcc_sdhi0,
+ &vccq_sdhi0,
};
static const struct pinctrl_map eva_pinctrl_map[] = {
@@ -1060,13 +1138,6 @@ static void __init eva_init(void)
usb = &usbhsf_device;
}
- /* SDHI0 */
- gpio_request_one(17, GPIOF_OUT_INIT_LOW, NULL); /* SDHI0_18/33_B */
- gpio_request_one(74, GPIOF_OUT_INIT_HIGH, NULL); /* SDHI0_PON */
- gpio_request_one(75, GPIOF_OUT_INIT_HIGH, NULL); /* SDSLOT1_PON */
-
- /* we can use GPIO_FN_IRQ31_PORT167 here for SDHI0 CD irq */
-
/* CEU0 */
gpio_request(GPIO_FN_VIO0_D7, NULL);
gpio_request(GPIO_FN_VIO0_D6, NULL);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 02/13] ARM: shmobile: switch SDHI0 to GPIO regulator on armadillo800eva
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
When regulators are used with MMC devices, explicitly provided OCR masks
are ignored, they can be removed from platform data. Also switch SDHI0
from fixed regulator with hard-wired GPIO levels to a proper GPIO regulator
instance to enable dynamic voltage switching.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 101 ++++++++++++++++++++----
1 file changed, 86 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 60694e8..f322a18 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -28,8 +28,10 @@
#include <linux/platform_device.h>
#include <linux/gpio.h>
#include <linux/gpio_keys.h>
+#include <linux/regulator/driver.h>
#include <linux/pinctrl/machine.h>
#include <linux/regulator/fixed.h>
+#include <linux/regulator/gpio-regulator.h>
#include <linux/regulator/machine.h>
#include <linux/sh_eth.h>
#include <linux/videodev2.h>
@@ -555,17 +557,94 @@ static struct platform_device gpio_keys_device = {
},
};
-/* Fixed 3.3V regulator to be used by SDHI0, SDHI1, MMCIF */
-static struct regulator_consumer_supply fixed3v3_power_consumers[] =
-{
- REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.0"),
- REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.0"),
+/* Fixed 3.3V regulator to be used by SDHI1, MMCIF */
+static struct regulator_consumer_supply fixed3v3_power_consumers[] = {
REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.1"),
REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.1"),
REGULATOR_SUPPLY("vmmc", "sh_mmcif"),
REGULATOR_SUPPLY("vqmmc", "sh_mmcif"),
};
+/* Fixed 3.3V regulator to be used by SDHI0 */
+static struct regulator_consumer_supply vcc_sdhi0_consumers[] = {
+ REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.0"),
+};
+
+static struct regulator_init_data vcc_sdhi0_init_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vcc_sdhi0_consumers),
+ .consumer_supplies = vcc_sdhi0_consumers,
+};
+
+static struct fixed_voltage_config vcc_sdhi0_info = {
+ .supply_name = "SDHI0 Vcc",
+ .microvolts = 3300000,
+ .gpio = GPIO_PORT75,
+ .enable_high = 1,
+ .init_data = &vcc_sdhi0_init_data,
+};
+
+static struct platform_device vcc_sdhi0 = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &vcc_sdhi0_info,
+ },
+};
+
+/* 1.8 / 3.3V SDHI0 VccQ regulator */
+static struct regulator_consumer_supply vccq_sdhi0_consumers[] = {
+ REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.0"),
+};
+
+static struct regulator_init_data vccq_sdhi0_init_data = {
+ .constraints = {
+ .input_uV = 3300000,
+ .min_uV = 1800000,
+ .max_uV = 3300000,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vccq_sdhi0_consumers),
+ .consumer_supplies = vccq_sdhi0_consumers,
+};
+
+static struct gpio vccq_sdhi0_gpios[] = {
+ {GPIO_PORT17, GPIOF_OUT_INIT_LOW, "vccq-sdhi0" },
+};
+
+static struct gpio_regulator_state vccq_sdhi0_states[] = {
+ { .value = 3300000, .gpios = (0 << 0) },
+ { .value = 1800000, .gpios = (1 << 0) },
+};
+
+static struct gpio_regulator_config vccq_sdhi0_info = {
+ .supply_name = "vqmmc",
+
+ .enable_gpio = GPIO_PORT74,
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+
+ .gpios = vccq_sdhi0_gpios,
+ .nr_gpios = ARRAY_SIZE(vccq_sdhi0_gpios),
+
+ .states = vccq_sdhi0_states,
+ .nr_states = ARRAY_SIZE(vccq_sdhi0_states),
+
+ .type = REGULATOR_VOLTAGE,
+ .init_data = &vccq_sdhi0_init_data,
+};
+
+static struct platform_device vccq_sdhi0 = {
+ .name = "gpio-regulator",
+ .id = -1,
+ .dev = {
+ .platform_data = &vccq_sdhi0_info,
+ },
+};
+
/* SDHI0 */
/*
* FIXME
@@ -580,7 +659,6 @@ static struct sh_mobile_sdhi_info sdhi0_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI0_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI0_RX,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
- .tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
.cd_gpio = GPIO_PORT167,
};
@@ -622,7 +700,6 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI1_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI1_RX,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
- .tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
/* Port72 cannot generate IRQs, will be used in polling mode. */
.cd_gpio = GPIO_PORT72,
@@ -673,7 +750,6 @@ static const struct pinctrl_map eva_sdhi1_pinctrl_map[] = {
/* MMCIF */
static struct sh_mmcif_plat_data sh_mmcif_plat = {
.sup_pclk = 0,
- .ocr = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
.caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_8_BIT_DATA |
MMC_CAP_NONREMOVABLE,
@@ -926,6 +1002,8 @@ static struct platform_device *eva_devices[] __initdata = {
&fsi_wm8978_device,
&fsi_hdmi_device,
&i2c_gpio_device,
+ &vcc_sdhi0,
+ &vccq_sdhi0,
};
static const struct pinctrl_map eva_pinctrl_map[] = {
@@ -1060,13 +1138,6 @@ static void __init eva_init(void)
usb = &usbhsf_device;
}
- /* SDHI0 */
- gpio_request_one(17, GPIOF_OUT_INIT_LOW, NULL); /* SDHI0_18/33_B */
- gpio_request_one(74, GPIOF_OUT_INIT_HIGH, NULL); /* SDHI0_PON */
- gpio_request_one(75, GPIOF_OUT_INIT_HIGH, NULL); /* SDSLOT1_PON */
-
- /* we can use GPIO_FN_IRQ31_PORT167 here for SDHI0 CD irq */
-
/* CEU0 */
gpio_request(GPIO_FN_VIO0_D7, NULL);
gpio_request(GPIO_FN_VIO0_D6, NULL);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 03/13] ARM: shmobile: streamline mackerel SD and MMC devices
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
This patch fixes the following issues with SD and MMC interfaces on mackerel:
1. replace custom card-detection functions with standard GPIO CD API
2. resources don't have to be numbered
3. add SDHI interrupt names
4. remove OCR masks, where regulators are used
5. only specify SDHI CD interrupts on interfaces where a CD pin is present -
SDHI0
6. don't instantiate an MMCIF device and initialise MMCIF pins if SDHI1 is
selected
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-mackerel.c | 113 ++++++++++++++++---------------
1 file changed, 57 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 336ccb4..fb058c7 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -963,15 +963,6 @@ static struct platform_device nand_flash_device = {
},
};
-/*
- * The card detect pin of the top SD/MMC slot (CN7) is active low and is
- * connected to GPIO A22 of SH7372 (GPIO 41).
- */
-static int slot_cn7_get_cd(struct platform_device *pdev)
-{
- return !gpio_get_value(41);
-}
-
/* SDHI0 */
static struct sh_mobile_sdhi_info sdhi0_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI0_TX,
@@ -982,21 +973,21 @@ static struct sh_mobile_sdhi_info sdhi0_info = {
};
static struct resource sdhi0_resources[] = {
- [0] = {
+ {
.name = "SDHI0",
.start = 0xe6850000,
.end = 0xe68500ff,
.flags = IORESOURCE_MEM,
- },
- [1] = {
+ }, {
+ .name = SH_MOBILE_SDHI_IRQ_CARD_DETECT,
.start = evt2irq(0x0e00) /* SDHI0_SDHI0I0 */,
.flags = IORESOURCE_IRQ,
- },
- [2] = {
+ }, {
+ .name = SH_MOBILE_SDHI_IRQ_SDCARD,
.start = evt2irq(0x0e20) /* SDHI0_SDHI0I1 */,
.flags = IORESOURCE_IRQ,
- },
- [3] = {
+ }, {
+ .name = SH_MOBILE_SDHI_IRQ_SDIO,
.start = evt2irq(0x0e40) /* SDHI0_SDHI0I2 */,
.flags = IORESOURCE_IRQ,
},
@@ -1014,34 +1005,28 @@ static struct platform_device sdhi0_device = {
#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
/* SDHI1 */
+
+/* GPIO_PORT41 can trigger IRQ8, but it is used by USBHS1, we have to poll */
static struct sh_mobile_sdhi_info sdhi1_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI1_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI1_RX,
- .tmio_ocr_mask = MMC_VDD_165_195,
- .tmio_flags = TMIO_MMC_WRPROTECT_DISABLE,
+ .tmio_flags = TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_USE_GPIO_CD,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
MMC_CAP_NEEDS_POLL,
- .get_cd = slot_cn7_get_cd,
+ .cd_gpio = GPIO_PORT41,
};
static struct resource sdhi1_resources[] = {
- [0] = {
+ {
.name = "SDHI1",
.start = 0xe6860000,
.end = 0xe68600ff,
.flags = IORESOURCE_MEM,
- },
- [1] = {
- .name = SH_MOBILE_SDHI_IRQ_CARD_DETECT,
- .start = evt2irq(0x0e80), /* SDHI1_SDHI1I0 */
- .flags = IORESOURCE_IRQ,
- },
- [2] = {
+ }, {
.name = SH_MOBILE_SDHI_IRQ_SDCARD,
.start = evt2irq(0x0ea0), /* SDHI1_SDHI1I1 */
.flags = IORESOURCE_IRQ,
- },
- [3] = {
+ }, {
.name = SH_MOBILE_SDHI_IRQ_SDIO,
.start = evt2irq(0x0ec0), /* SDHI1_SDHI1I2 */
.flags = IORESOURCE_IRQ,
@@ -1059,43 +1044,32 @@ static struct platform_device sdhi1_device = {
};
#endif
+/* SDHI2 */
+
/*
* The card detect pin of the top SD/MMC slot (CN23) is active low and is
- * connected to GPIO SCIFB_SCK of SH7372 (162).
+ * connected to GPIO SCIFB_SCK of SH7372 (GPIO_PORT162).
*/
-static int slot_cn23_get_cd(struct platform_device *pdev)
-{
- return !gpio_get_value(162);
-}
-
-/* SDHI2 */
static struct sh_mobile_sdhi_info sdhi2_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI2_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI2_RX,
- .tmio_flags = TMIO_MMC_WRPROTECT_DISABLE,
+ .tmio_flags = TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_USE_GPIO_CD,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
MMC_CAP_NEEDS_POLL,
- .get_cd = slot_cn23_get_cd,
+ .cd_gpio = GPIO_PORT162,
};
static struct resource sdhi2_resources[] = {
- [0] = {
+ {
.name = "SDHI2",
.start = 0xe6870000,
.end = 0xe68700ff,
.flags = IORESOURCE_MEM,
- },
- [1] = {
- .name = SH_MOBILE_SDHI_IRQ_CARD_DETECT,
- .start = evt2irq(0x1200), /* SDHI2_SDHI2I0 */
- .flags = IORESOURCE_IRQ,
- },
- [2] = {
+ }, {
.name = SH_MOBILE_SDHI_IRQ_SDCARD,
.start = evt2irq(0x1220), /* SDHI2_SDHI2I1 */
.flags = IORESOURCE_IRQ,
- },
- [3] = {
+ }, {
.name = SH_MOBILE_SDHI_IRQ_SDIO,
.start = evt2irq(0x1240), /* SDHI2_SDHI2I2 */
.flags = IORESOURCE_IRQ,
@@ -1134,11 +1108,12 @@ static struct resource sh_mmcif_resources[] = {
static struct sh_mmcif_plat_data sh_mmcif_plat = {
.sup_pclk = 0,
- .ocr = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
.caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_8_BIT_DATA |
MMC_CAP_NEEDS_POLL,
- .get_cd = slot_cn7_get_cd,
+ .use_cd_gpio = true,
+ /* card detect pin for SD/MMC slot (CN7) */
+ .cd_gpio = GPIO_PORT41,
.slave_id_tx = SHDMA_SLAVE_MMCIF_TX,
.slave_id_rx = SHDMA_SLAVE_MMCIF_RX,
};
@@ -1263,9 +1238,10 @@ static struct platform_device *mackerel_devices[] __initdata = {
&sdhi0_device,
#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
&sdhi1_device,
+#else
+ &sh_mmcif_device,
#endif
&sdhi2_device,
- &sh_mmcif_device,
&ceu_device,
&mackerel_camera,
&hdmi_device,
@@ -1372,10 +1348,11 @@ static void __init mackerel_init(void)
{ "A3SP", &usbhs0_device, },
{ "A3SP", &usbhs1_device, },
{ "A3SP", &nand_flash_device, },
- { "A3SP", &sh_mmcif_device, },
{ "A3SP", &sdhi0_device, },
#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
{ "A3SP", &sdhi1_device, },
+#else
+ { "A3SP", &sh_mmcif_device, },
#endif
{ "A3SP", &sdhi2_device, },
{ "A4R", &ceu_device, },
@@ -1486,11 +1463,35 @@ static void __init mackerel_init(void)
/* SDHI0 PORT172 card-detect IRQ26 */
gpio_request(GPIO_FN_IRQ26_172, NULL);
- /* card detect pin for MMC slot (CN7) */
- gpio_request_one(41, GPIOF_IN, NULL);
+#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+ /* enable SDHI1 */
+ gpio_request(GPIO_FN_SDHICMD1, NULL);
+ gpio_request(GPIO_FN_SDHICLK1, NULL);
+ gpio_request(GPIO_FN_SDHID1_3, NULL);
+ gpio_request(GPIO_FN_SDHID1_2, NULL);
+ gpio_request(GPIO_FN_SDHID1_1, NULL);
+ gpio_request(GPIO_FN_SDHID1_0, NULL);
+#else
+ /* MMCIF */
+ gpio_request(GPIO_FN_MMCD0_0, NULL);
+ gpio_request(GPIO_FN_MMCD0_1, NULL);
+ gpio_request(GPIO_FN_MMCD0_2, NULL);
+ gpio_request(GPIO_FN_MMCD0_3, NULL);
+ gpio_request(GPIO_FN_MMCD0_4, NULL);
+ gpio_request(GPIO_FN_MMCD0_5, NULL);
+ gpio_request(GPIO_FN_MMCD0_6, NULL);
+ gpio_request(GPIO_FN_MMCD0_7, NULL);
+ gpio_request(GPIO_FN_MMCCMD0, NULL);
+ gpio_request(GPIO_FN_MMCCLK0, NULL);
+#endif
- /* card detect pin for microSD slot (CN23) */
- gpio_request_one(162, GPIOF_IN, NULL);
+ /* enable SDHI2 */
+ gpio_request(GPIO_FN_SDHICMD2, NULL);
+ gpio_request(GPIO_FN_SDHICLK2, NULL);
+ gpio_request(GPIO_FN_SDHID2_3, NULL);
+ gpio_request(GPIO_FN_SDHID2_2, NULL);
+ gpio_request(GPIO_FN_SDHID2_1, NULL);
+ gpio_request(GPIO_FN_SDHID2_0, NULL);
/* FLCTL */
gpio_request(GPIO_FN_D0_NAF0, NULL);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 03/13] ARM: shmobile: streamline mackerel SD and MMC devices
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
This patch fixes the following issues with SD and MMC interfaces on mackerel:
1. replace custom card-detection functions with standard GPIO CD API
2. resources don't have to be numbered
3. add SDHI interrupt names
4. remove OCR masks, where regulators are used
5. only specify SDHI CD interrupts on interfaces where a CD pin is present -
SDHI0
6. don't instantiate an MMCIF device and initialise MMCIF pins if SDHI1 is
selected
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-mackerel.c | 113 ++++++++++++++++---------------
1 file changed, 57 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 336ccb4..fb058c7 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -963,15 +963,6 @@ static struct platform_device nand_flash_device = {
},
};
-/*
- * The card detect pin of the top SD/MMC slot (CN7) is active low and is
- * connected to GPIO A22 of SH7372 (GPIO 41).
- */
-static int slot_cn7_get_cd(struct platform_device *pdev)
-{
- return !gpio_get_value(41);
-}
-
/* SDHI0 */
static struct sh_mobile_sdhi_info sdhi0_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI0_TX,
@@ -982,21 +973,21 @@ static struct sh_mobile_sdhi_info sdhi0_info = {
};
static struct resource sdhi0_resources[] = {
- [0] = {
+ {
.name = "SDHI0",
.start = 0xe6850000,
.end = 0xe68500ff,
.flags = IORESOURCE_MEM,
- },
- [1] = {
+ }, {
+ .name = SH_MOBILE_SDHI_IRQ_CARD_DETECT,
.start = evt2irq(0x0e00) /* SDHI0_SDHI0I0 */,
.flags = IORESOURCE_IRQ,
- },
- [2] = {
+ }, {
+ .name = SH_MOBILE_SDHI_IRQ_SDCARD,
.start = evt2irq(0x0e20) /* SDHI0_SDHI0I1 */,
.flags = IORESOURCE_IRQ,
- },
- [3] = {
+ }, {
+ .name = SH_MOBILE_SDHI_IRQ_SDIO,
.start = evt2irq(0x0e40) /* SDHI0_SDHI0I2 */,
.flags = IORESOURCE_IRQ,
},
@@ -1014,34 +1005,28 @@ static struct platform_device sdhi0_device = {
#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
/* SDHI1 */
+
+/* GPIO_PORT41 can trigger IRQ8, but it is used by USBHS1, we have to poll */
static struct sh_mobile_sdhi_info sdhi1_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI1_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI1_RX,
- .tmio_ocr_mask = MMC_VDD_165_195,
- .tmio_flags = TMIO_MMC_WRPROTECT_DISABLE,
+ .tmio_flags = TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_USE_GPIO_CD,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
MMC_CAP_NEEDS_POLL,
- .get_cd = slot_cn7_get_cd,
+ .cd_gpio = GPIO_PORT41,
};
static struct resource sdhi1_resources[] = {
- [0] = {
+ {
.name = "SDHI1",
.start = 0xe6860000,
.end = 0xe68600ff,
.flags = IORESOURCE_MEM,
- },
- [1] = {
- .name = SH_MOBILE_SDHI_IRQ_CARD_DETECT,
- .start = evt2irq(0x0e80), /* SDHI1_SDHI1I0 */
- .flags = IORESOURCE_IRQ,
- },
- [2] = {
+ }, {
.name = SH_MOBILE_SDHI_IRQ_SDCARD,
.start = evt2irq(0x0ea0), /* SDHI1_SDHI1I1 */
.flags = IORESOURCE_IRQ,
- },
- [3] = {
+ }, {
.name = SH_MOBILE_SDHI_IRQ_SDIO,
.start = evt2irq(0x0ec0), /* SDHI1_SDHI1I2 */
.flags = IORESOURCE_IRQ,
@@ -1059,43 +1044,32 @@ static struct platform_device sdhi1_device = {
};
#endif
+/* SDHI2 */
+
/*
* The card detect pin of the top SD/MMC slot (CN23) is active low and is
- * connected to GPIO SCIFB_SCK of SH7372 (162).
+ * connected to GPIO SCIFB_SCK of SH7372 (GPIO_PORT162).
*/
-static int slot_cn23_get_cd(struct platform_device *pdev)
-{
- return !gpio_get_value(162);
-}
-
-/* SDHI2 */
static struct sh_mobile_sdhi_info sdhi2_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI2_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI2_RX,
- .tmio_flags = TMIO_MMC_WRPROTECT_DISABLE,
+ .tmio_flags = TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_USE_GPIO_CD,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
MMC_CAP_NEEDS_POLL,
- .get_cd = slot_cn23_get_cd,
+ .cd_gpio = GPIO_PORT162,
};
static struct resource sdhi2_resources[] = {
- [0] = {
+ {
.name = "SDHI2",
.start = 0xe6870000,
.end = 0xe68700ff,
.flags = IORESOURCE_MEM,
- },
- [1] = {
- .name = SH_MOBILE_SDHI_IRQ_CARD_DETECT,
- .start = evt2irq(0x1200), /* SDHI2_SDHI2I0 */
- .flags = IORESOURCE_IRQ,
- },
- [2] = {
+ }, {
.name = SH_MOBILE_SDHI_IRQ_SDCARD,
.start = evt2irq(0x1220), /* SDHI2_SDHI2I1 */
.flags = IORESOURCE_IRQ,
- },
- [3] = {
+ }, {
.name = SH_MOBILE_SDHI_IRQ_SDIO,
.start = evt2irq(0x1240), /* SDHI2_SDHI2I2 */
.flags = IORESOURCE_IRQ,
@@ -1134,11 +1108,12 @@ static struct resource sh_mmcif_resources[] = {
static struct sh_mmcif_plat_data sh_mmcif_plat = {
.sup_pclk = 0,
- .ocr = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
.caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_8_BIT_DATA |
MMC_CAP_NEEDS_POLL,
- .get_cd = slot_cn7_get_cd,
+ .use_cd_gpio = true,
+ /* card detect pin for SD/MMC slot (CN7) */
+ .cd_gpio = GPIO_PORT41,
.slave_id_tx = SHDMA_SLAVE_MMCIF_TX,
.slave_id_rx = SHDMA_SLAVE_MMCIF_RX,
};
@@ -1263,9 +1238,10 @@ static struct platform_device *mackerel_devices[] __initdata = {
&sdhi0_device,
#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
&sdhi1_device,
+#else
+ &sh_mmcif_device,
#endif
&sdhi2_device,
- &sh_mmcif_device,
&ceu_device,
&mackerel_camera,
&hdmi_device,
@@ -1372,10 +1348,11 @@ static void __init mackerel_init(void)
{ "A3SP", &usbhs0_device, },
{ "A3SP", &usbhs1_device, },
{ "A3SP", &nand_flash_device, },
- { "A3SP", &sh_mmcif_device, },
{ "A3SP", &sdhi0_device, },
#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
{ "A3SP", &sdhi1_device, },
+#else
+ { "A3SP", &sh_mmcif_device, },
#endif
{ "A3SP", &sdhi2_device, },
{ "A4R", &ceu_device, },
@@ -1486,11 +1463,35 @@ static void __init mackerel_init(void)
/* SDHI0 PORT172 card-detect IRQ26 */
gpio_request(GPIO_FN_IRQ26_172, NULL);
- /* card detect pin for MMC slot (CN7) */
- gpio_request_one(41, GPIOF_IN, NULL);
+#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+ /* enable SDHI1 */
+ gpio_request(GPIO_FN_SDHICMD1, NULL);
+ gpio_request(GPIO_FN_SDHICLK1, NULL);
+ gpio_request(GPIO_FN_SDHID1_3, NULL);
+ gpio_request(GPIO_FN_SDHID1_2, NULL);
+ gpio_request(GPIO_FN_SDHID1_1, NULL);
+ gpio_request(GPIO_FN_SDHID1_0, NULL);
+#else
+ /* MMCIF */
+ gpio_request(GPIO_FN_MMCD0_0, NULL);
+ gpio_request(GPIO_FN_MMCD0_1, NULL);
+ gpio_request(GPIO_FN_MMCD0_2, NULL);
+ gpio_request(GPIO_FN_MMCD0_3, NULL);
+ gpio_request(GPIO_FN_MMCD0_4, NULL);
+ gpio_request(GPIO_FN_MMCD0_5, NULL);
+ gpio_request(GPIO_FN_MMCD0_6, NULL);
+ gpio_request(GPIO_FN_MMCD0_7, NULL);
+ gpio_request(GPIO_FN_MMCCMD0, NULL);
+ gpio_request(GPIO_FN_MMCCLK0, NULL);
+#endif
- /* card detect pin for microSD slot (CN23) */
- gpio_request_one(162, GPIOF_IN, NULL);
+ /* enable SDHI2 */
+ gpio_request(GPIO_FN_SDHICMD2, NULL);
+ gpio_request(GPIO_FN_SDHICLK2, NULL);
+ gpio_request(GPIO_FN_SDHID2_3, NULL);
+ gpio_request(GPIO_FN_SDHID2_2, NULL);
+ gpio_request(GPIO_FN_SDHID2_1, NULL);
+ gpio_request(GPIO_FN_SDHID2_0, NULL);
/* FLCTL */
gpio_request(GPIO_FN_D0_NAF0, NULL);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 04/13] ARM: shmobile: mark mackerel sh_mmcif_device __maybe_unused
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Arnd Bergmann <arnd@arndb.de>
Patch eac036ef9e "ARM: shmobile: streamline mackerel SD and MMC devices"
made the use of the sh_mmcif_device variable for mackarel optional,
but the definition is always provided, causing a build warning.
arch/arm/mach-shmobile/board-mackerel.c:1120:31: warning: 'sh_mmcif_device'
defined but not used [-Wunused-variable]
Marking the variable as __maybe_unused will do the right thing here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-mackerel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index fb058c7..ef22ec4 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -1118,7 +1118,7 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
.slave_id_rx = SHDMA_SLAVE_MMCIF_RX,
};
-static struct platform_device sh_mmcif_device = {
+static struct platform_device sh_mmcif_device __maybe_unused = {
.name = "sh_mmcif",
.id = 0,
.dev = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 04/13] ARM: shmobile: mark mackerel sh_mmcif_device __maybe_unused
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Arnd Bergmann <arnd@arndb.de>
Patch eac036ef9e "ARM: shmobile: streamline mackerel SD and MMC devices"
made the use of the sh_mmcif_device variable for mackarel optional,
but the definition is always provided, causing a build warning.
arch/arm/mach-shmobile/board-mackerel.c:1120:31: warning: 'sh_mmcif_device'
defined but not used [-Wunused-variable]
Marking the variable as __maybe_unused will do the right thing here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-mackerel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index fb058c7..ef22ec4 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -1118,7 +1118,7 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
.slave_id_rx = SHDMA_SLAVE_MMCIF_RX,
};
-static struct platform_device sh_mmcif_device = {
+static struct platform_device sh_mmcif_device __maybe_unused = {
.name = "sh_mmcif",
.id = 0,
.dev = {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 05/13] ARM: shmobile: marzen: Reference DT implementation
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Provide alternate board code for the marzen to demonstrate
how DT may be used given the current state of driver
device tree support. This is intended to act as a reference
for mach-shmobile developers.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a7779-marzen-reference.dts | 47 ++++++++++++++
arch/arm/mach-shmobile/Kconfig | 13 ++++
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/board-marzen-reference.c | 75 +++++++++++++++++++++++
5 files changed, 137 insertions(+)
create mode 100644 arch/arm/boot/dts/r8a7779-marzen-reference.dts
create mode 100644 arch/arm/mach-shmobile/board-marzen-reference.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..7965b9a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -136,6 +136,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
ccu9540.dtb
dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
r8a7740-armadillo800eva.dtb \
+ r8a7779-marzen-reference.dtb \
sh73a0-kzm9g.dtb \
sh7372-mackerel.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
new file mode 100644
index 0000000..72be4c8
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -0,0 +1,47 @@
+/*
+ * Reference Device Tree Source for the Marzen board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "r8a7779.dtsi"
+
+/ {
+ model = "marzen";
+ compatible = "renesas,marzen-reference", "renesas,r8a7779";
+
+ chosen {
+ bootargs = "console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x60000000 0x40000000>;
+ };
+
+ fixedregulator3v3: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ lan0@18000000 {
+ compatible = "smsc,lan9220", "smsc,lan9115";
+ reg = <0x18000000 0x100>;
+ phy-mode = "mii";
+ interrupt-parent = <&gic>;
+ interrupts = <0 28 0x4>;
+ reg-io-width = <4>;
+ vddvario-supply = <&fixedregulator3v3>;
+ vdd33a-supply = <&fixedregulator3v3>;
+ };
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 9255546..b15d4ff 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -102,6 +102,19 @@ config MACH_MARZEN
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+config MACH_MARZEN_REFERENCE
+ bool "MARZEN board - Reference Device Tree Implementation"
+ depends on ARCH_R8A7779
+ select ARCH_REQUIRE_GPIOLIB
+ select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select USE_OF
+ ---help---
+ Use reference implementation of Marzen board support
+ which makes use of device tree at the expense
+ of not supporting a number of devices.
+
+ This is intended to aid developers
+
config MACH_KZM9D
bool "KZM9D board"
depends on ARCH_EMEV2
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index b646ff4..3705d4f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_MACH_MACKEREL) += board-mackerel.o
obj-$(CONFIG_MACH_KOTA2) += board-kota2.o
obj-$(CONFIG_MACH_BONITO) += board-bonito.o
obj-$(CONFIG_MACH_MARZEN) += board-marzen.o
+obj-$(CONFIG_MACH_MARZEN_REFERENCE) += board-marzen-reference.o
obj-$(CONFIG_MACH_ARMADILLO800EVA) += board-armadillo800eva.o
obj-$(CONFIG_MACH_KZM9D) += board-kzm9d.o
obj-$(CONFIG_MACH_KZM9G) += board-kzm9g.o
diff --git a/arch/arm/mach-shmobile/board-marzen-reference.c b/arch/arm/mach-shmobile/board-marzen-reference.c
new file mode 100644
index 0000000..480d882
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-marzen-reference.c
@@ -0,0 +1,75 @@
+/*
+ * marzen board support - Reference DT implementation
+ *
+ * Copyright (C) 2011 Renesas Solutions Corp.
+ * Copyright (C) 2011 Magnus Damm
+ * Copyright (C) 2013 Simon Horman
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <linux/pinctrl/machine.h>
+#include <mach/r8a7779.h>
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <asm/irq.h>
+#include <asm/mach/arch.h>
+
+static const struct pinctrl_map marzen_pinctrl_map[] = {
+ /* SCIF2 (CN18: DEBUG0) */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "pfc-r8a7779",
+ "scif2_data_c", "scif2"),
+ /* SCIF4 (CN19: DEBUG1) */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-r8a7779",
+ "scif4_data", "scif4"),
+ /* SDHI0 */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+ "sdhi0_data4", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+ "sdhi0_ctrl", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+ "sdhi0_cd", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+ "sdhi0_wp", "sdhi0"),
+ /* SMSC */
+ PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a7779",
+ "intc_irq1_b", "intc"),
+ PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a7779",
+ "lbsc_ex_cs0", "lbsc"),
+};
+
+static void __init marzen_init(void)
+{
+ pinctrl_register_mappings(marzen_pinctrl_map,
+ ARRAY_SIZE(marzen_pinctrl_map));
+ r8a7779_pinmux_init();
+
+ r8a7779_add_standard_devices_dt();
+}
+
+static const char *marzen_boards_compat_dt[] __initdata = {
+ "renesas,marzen-reference",
+ NULL,
+};
+
+DT_MACHINE_START(MARZEN, "marzen")
+ .smp = smp_ops(r8a7779_smp_ops),
+ .map_io = r8a7779_map_io,
+ .init_early = r8a7779_init_delay,
+ .nr_irqs = NR_IRQS_LEGACY,
+ .init_irq = r8a7779_init_irq_dt,
+ .init_machine = marzen_init,
+ .init_time = shmobile_timer_init,
+ .dt_compat = marzen_boards_compat_dt,
+MACHINE_END
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 05/13] ARM: shmobile: marzen: Reference DT implementation
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Provide alternate board code for the marzen to demonstrate
how DT may be used given the current state of driver
device tree support. This is intended to act as a reference
for mach-shmobile developers.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a7779-marzen-reference.dts | 47 ++++++++++++++
arch/arm/mach-shmobile/Kconfig | 13 ++++
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/board-marzen-reference.c | 75 +++++++++++++++++++++++
5 files changed, 137 insertions(+)
create mode 100644 arch/arm/boot/dts/r8a7779-marzen-reference.dts
create mode 100644 arch/arm/mach-shmobile/board-marzen-reference.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..7965b9a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -136,6 +136,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
ccu9540.dtb
dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
r8a7740-armadillo800eva.dtb \
+ r8a7779-marzen-reference.dtb \
sh73a0-kzm9g.dtb \
sh7372-mackerel.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
new file mode 100644
index 0000000..72be4c8
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -0,0 +1,47 @@
+/*
+ * Reference Device Tree Source for the Marzen board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "r8a7779.dtsi"
+
+/ {
+ model = "marzen";
+ compatible = "renesas,marzen-reference", "renesas,r8a7779";
+
+ chosen {
+ bootargs = "console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x60000000 0x40000000>;
+ };
+
+ fixedregulator3v3: fixedregulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ lan0 at 18000000 {
+ compatible = "smsc,lan9220", "smsc,lan9115";
+ reg = <0x18000000 0x100>;
+ phy-mode = "mii";
+ interrupt-parent = <&gic>;
+ interrupts = <0 28 0x4>;
+ reg-io-width = <4>;
+ vddvario-supply = <&fixedregulator3v3>;
+ vdd33a-supply = <&fixedregulator3v3>;
+ };
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 9255546..b15d4ff 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -102,6 +102,19 @@ config MACH_MARZEN
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+config MACH_MARZEN_REFERENCE
+ bool "MARZEN board - Reference Device Tree Implementation"
+ depends on ARCH_R8A7779
+ select ARCH_REQUIRE_GPIOLIB
+ select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select USE_OF
+ ---help---
+ Use reference implementation of Marzen board support
+ which makes use of device tree at the expense
+ of not supporting a number of devices.
+
+ This is intended to aid developers
+
config MACH_KZM9D
bool "KZM9D board"
depends on ARCH_EMEV2
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index b646ff4..3705d4f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_MACH_MACKEREL) += board-mackerel.o
obj-$(CONFIG_MACH_KOTA2) += board-kota2.o
obj-$(CONFIG_MACH_BONITO) += board-bonito.o
obj-$(CONFIG_MACH_MARZEN) += board-marzen.o
+obj-$(CONFIG_MACH_MARZEN_REFERENCE) += board-marzen-reference.o
obj-$(CONFIG_MACH_ARMADILLO800EVA) += board-armadillo800eva.o
obj-$(CONFIG_MACH_KZM9D) += board-kzm9d.o
obj-$(CONFIG_MACH_KZM9G) += board-kzm9g.o
diff --git a/arch/arm/mach-shmobile/board-marzen-reference.c b/arch/arm/mach-shmobile/board-marzen-reference.c
new file mode 100644
index 0000000..480d882
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-marzen-reference.c
@@ -0,0 +1,75 @@
+/*
+ * marzen board support - Reference DT implementation
+ *
+ * Copyright (C) 2011 Renesas Solutions Corp.
+ * Copyright (C) 2011 Magnus Damm
+ * Copyright (C) 2013 Simon Horman
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <linux/pinctrl/machine.h>
+#include <mach/r8a7779.h>
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <asm/irq.h>
+#include <asm/mach/arch.h>
+
+static const struct pinctrl_map marzen_pinctrl_map[] = {
+ /* SCIF2 (CN18: DEBUG0) */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "pfc-r8a7779",
+ "scif2_data_c", "scif2"),
+ /* SCIF4 (CN19: DEBUG1) */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-r8a7779",
+ "scif4_data", "scif4"),
+ /* SDHI0 */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+ "sdhi0_data4", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+ "sdhi0_ctrl", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+ "sdhi0_cd", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+ "sdhi0_wp", "sdhi0"),
+ /* SMSC */
+ PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a7779",
+ "intc_irq1_b", "intc"),
+ PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a7779",
+ "lbsc_ex_cs0", "lbsc"),
+};
+
+static void __init marzen_init(void)
+{
+ pinctrl_register_mappings(marzen_pinctrl_map,
+ ARRAY_SIZE(marzen_pinctrl_map));
+ r8a7779_pinmux_init();
+
+ r8a7779_add_standard_devices_dt();
+}
+
+static const char *marzen_boards_compat_dt[] __initdata = {
+ "renesas,marzen-reference",
+ NULL,
+};
+
+DT_MACHINE_START(MARZEN, "marzen")
+ .smp = smp_ops(r8a7779_smp_ops),
+ .map_io = r8a7779_map_io,
+ .init_early = r8a7779_init_delay,
+ .nr_irqs = NR_IRQS_LEGACY,
+ .init_irq = r8a7779_init_irq_dt,
+ .init_machine = marzen_init,
+ .init_time = shmobile_timer_init,
+ .dt_compat = marzen_boards_compat_dt,
+MACHINE_END
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 06/13] ARM: shmobile: kzm9g: Reference DT implementation
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Provide alternate board code for the kzm9g to demonstrate
how DT may be used given the current state of driver
device tree support. This is intended to act as a reference
for mach-shmobile developers.
Some notes:
* Brings up the GIC interrupt handler using device tree
* Brings up the following device using device tree:
- MMCIF (MMC)
* Does not bring up the INTC interrupt controller at all,
thus external devices may not be used. In particular,
the SMSC ethernet device may not be used and thus
NFS root may not be used.
* Uses existing C code and not device tree to initialise the following,
which are needed for a working board:
- SCIF (Serial)
- CMT (Clock)
- PFC (GPIO)
To use this alternate board code instead of the normal board code,
CONFIG_MACH_KZM9G_REFERENCE should be selected in the kernel config.
And the sh73a0-kzm9g-reference.dtb flattened device tree blob should be used.
Includes fix by Thierry Reding to no longer use gic_handle_irq()
Includes fixes by Guennadi Liakhovetski for recent pinmux changes.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 41 +++++++++++
arch/arm/mach-shmobile/Kconfig | 10 +++
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/board-kzm9g-reference.c | 87 ++++++++++++++++++++++++
5 files changed, 140 insertions(+)
create mode 100644 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
create mode 100644 arch/arm/mach-shmobile/board-kzm9g-reference.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7965b9a..ee9fbe4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
r8a7740-armadillo800eva.dtb \
r8a7779-marzen-reference.dtb \
sh73a0-kzm9g.dtb \
+ sh73a0-kzm9g-reference.dtb \
sh7372-mackerel.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
socfpga_vt.dtb
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
new file mode 100644
index 0000000..06f52f9
--- /dev/null
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for the KZM-A9-GT board
+ *
+ * Copyright (C) 2012 Horms Solutions Ltd.
+ *
+ * Based on sh73a0-kzm9g.dts
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "sh73a0-reference.dtsi"
+
+/ {
+ model = "KZM-A9-GT";
+ compatible = "renesas,kzm9g-reference", "renesas,sh73a0";
+
+ chosen {
+ bootargs = "console=tty0 console=ttySC4,115200 root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x41000000 0x1e800000>;
+ };
+
+ fixedregulator1v8: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+};
+
+&mmcif {
+ vmmc-supply = <&fixedregulator1v8>;
+ vqmmc-supply = <&fixedregulator1v8>;
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index b15d4ff..0c48af9 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -129,6 +129,16 @@ config MACH_KZM9G
select SND_SOC_AK4642 if SND_SIMPLE_CARD
select USE_OF
+config MACH_KZM9G_REFERENCE
+ bool "KZM-A9-GT board - Reference Device Tree Implementation"
+ depends on MACH_KZM9G
+ ---help---
+ Use reference implementation of KZM-A9-GT board support
+ which makes as greater use of device tree at the expense
+ of not supporting a number of devices.
+
+ This is intended to aid developers
+
comment "SH-Mobile System Configuration"
config CPU_HAS_INTEVT
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 3705d4f..c621edf 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_MACH_MARZEN_REFERENCE) += board-marzen-reference.o
obj-$(CONFIG_MACH_ARMADILLO800EVA) += board-armadillo800eva.o
obj-$(CONFIG_MACH_KZM9D) += board-kzm9d.o
obj-$(CONFIG_MACH_KZM9G) += board-kzm9g.o
+obj-$(CONFIG_MACH_KZM9G_REFERENCE) += board-kzm9g-reference.o
# Framework support
obj-$(CONFIG_SMP) += $(smp-y)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
new file mode 100644
index 0000000..caba1bb
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -0,0 +1,87 @@
+/*
+ * KZM-A9-GT board support - Reference Device Tree Implementation
+ *
+ * Copyright (C) 2012 Horms Solutions Ltd.
+ *
+ * Based on board-kzm9g.c
+ * Copyright (C) 2012 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/input.h>
+#include <linux/of_platform.h>
+#include <linux/pinctrl/machine.h>
+#include <mach/sh73a0.h>
+#include <mach/common.h>
+#include <asm/hardware/cache-l2x0.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static const struct pinctrl_map kzm_pinctrl_map[] = {
+ PIN_MAP_MUX_GROUP_DEFAULT("i2c-sh_mobile.3", "pfc-sh73a0",
+ "i2c3_1", "i2c3"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
+ "scifa4_data", "scifa4"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
+ "scifa4_ctrl", "scifa4"),
+};
+
+static void __init kzm_init(void)
+{
+ sh73a0_add_standard_devices_dt();
+ pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
+
+#ifdef CONFIG_CACHE_L2X0
+ /* Early BRESP enable, Shared attribute override enable, 64K*8way */
+ l2x0_init(IOMEM(0xf0100000), 0x40460000, 0x82000fff);
+#endif
+}
+
+static void kzm9g_restart(char mode, const char *cmd)
+{
+#define RESCNT2 IOMEM(0xe6188020)
+ /* Do soft power on reset */
+ writel((1 << 31), RESCNT2);
+}
+
+static const char *kzm9g_boards_compat_dt[] __initdata = {
+ "renesas,kzm9g-reference",
+ NULL,
+};
+
+/* Please note that the clock initialisation shcheme used in
+ * sh73a0_add_early_devices_dt() and sh73a0_add_standard_devices_dt()
+ * does not work with SMP as there is a yet to be resolved lock-up in
+ * workqueue initialisation.
+ *
+ * CONFIG_SMP should be disabled when using this code.
+ */
+DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
+ .smp = smp_ops(sh73a0_smp_ops),
+ .map_io = sh73a0_map_io,
+ .init_early = sh73a0_init_delay,
+ .nr_irqs = NR_IRQS_LEGACY,
+ .init_irq = irqchip_init,
+ .init_machine = kzm_init,
+ .init_late = shmobile_init_late,
+ .init_time = shmobile_timer_init,
+ .restart = kzm9g_restart,
+ .dt_compat = kzm9g_boards_compat_dt,
+MACHINE_END
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 06/13] ARM: shmobile: kzm9g: Reference DT implementation
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Provide alternate board code for the kzm9g to demonstrate
how DT may be used given the current state of driver
device tree support. This is intended to act as a reference
for mach-shmobile developers.
Some notes:
* Brings up the GIC interrupt handler using device tree
* Brings up the following device using device tree:
- MMCIF (MMC)
* Does not bring up the INTC interrupt controller at all,
thus external devices may not be used. In particular,
the SMSC ethernet device may not be used and thus
NFS root may not be used.
* Uses existing C code and not device tree to initialise the following,
which are needed for a working board:
- SCIF (Serial)
- CMT (Clock)
- PFC (GPIO)
To use this alternate board code instead of the normal board code,
CONFIG_MACH_KZM9G_REFERENCE should be selected in the kernel config.
And the sh73a0-kzm9g-reference.dtb flattened device tree blob should be used.
Includes fix by Thierry Reding to no longer use gic_handle_irq()
Includes fixes by Guennadi Liakhovetski for recent pinmux changes.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 41 +++++++++++
arch/arm/mach-shmobile/Kconfig | 10 +++
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/board-kzm9g-reference.c | 87 ++++++++++++++++++++++++
5 files changed, 140 insertions(+)
create mode 100644 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
create mode 100644 arch/arm/mach-shmobile/board-kzm9g-reference.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7965b9a..ee9fbe4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
r8a7740-armadillo800eva.dtb \
r8a7779-marzen-reference.dtb \
sh73a0-kzm9g.dtb \
+ sh73a0-kzm9g-reference.dtb \
sh7372-mackerel.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
socfpga_vt.dtb
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
new file mode 100644
index 0000000..06f52f9
--- /dev/null
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for the KZM-A9-GT board
+ *
+ * Copyright (C) 2012 Horms Solutions Ltd.
+ *
+ * Based on sh73a0-kzm9g.dts
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "sh73a0-reference.dtsi"
+
+/ {
+ model = "KZM-A9-GT";
+ compatible = "renesas,kzm9g-reference", "renesas,sh73a0";
+
+ chosen {
+ bootargs = "console=tty0 console=ttySC4,115200 root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x41000000 0x1e800000>;
+ };
+
+ fixedregulator1v8: fixedregulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+};
+
+&mmcif {
+ vmmc-supply = <&fixedregulator1v8>;
+ vqmmc-supply = <&fixedregulator1v8>;
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index b15d4ff..0c48af9 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -129,6 +129,16 @@ config MACH_KZM9G
select SND_SOC_AK4642 if SND_SIMPLE_CARD
select USE_OF
+config MACH_KZM9G_REFERENCE
+ bool "KZM-A9-GT board - Reference Device Tree Implementation"
+ depends on MACH_KZM9G
+ ---help---
+ Use reference implementation of KZM-A9-GT board support
+ which makes as greater use of device tree at the expense
+ of not supporting a number of devices.
+
+ This is intended to aid developers
+
comment "SH-Mobile System Configuration"
config CPU_HAS_INTEVT
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 3705d4f..c621edf 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_MACH_MARZEN_REFERENCE) += board-marzen-reference.o
obj-$(CONFIG_MACH_ARMADILLO800EVA) += board-armadillo800eva.o
obj-$(CONFIG_MACH_KZM9D) += board-kzm9d.o
obj-$(CONFIG_MACH_KZM9G) += board-kzm9g.o
+obj-$(CONFIG_MACH_KZM9G_REFERENCE) += board-kzm9g-reference.o
# Framework support
obj-$(CONFIG_SMP) += $(smp-y)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
new file mode 100644
index 0000000..caba1bb
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -0,0 +1,87 @@
+/*
+ * KZM-A9-GT board support - Reference Device Tree Implementation
+ *
+ * Copyright (C) 2012 Horms Solutions Ltd.
+ *
+ * Based on board-kzm9g.c
+ * Copyright (C) 2012 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/input.h>
+#include <linux/of_platform.h>
+#include <linux/pinctrl/machine.h>
+#include <mach/sh73a0.h>
+#include <mach/common.h>
+#include <asm/hardware/cache-l2x0.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static const struct pinctrl_map kzm_pinctrl_map[] = {
+ PIN_MAP_MUX_GROUP_DEFAULT("i2c-sh_mobile.3", "pfc-sh73a0",
+ "i2c3_1", "i2c3"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
+ "scifa4_data", "scifa4"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
+ "scifa4_ctrl", "scifa4"),
+};
+
+static void __init kzm_init(void)
+{
+ sh73a0_add_standard_devices_dt();
+ pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
+
+#ifdef CONFIG_CACHE_L2X0
+ /* Early BRESP enable, Shared attribute override enable, 64K*8way */
+ l2x0_init(IOMEM(0xf0100000), 0x40460000, 0x82000fff);
+#endif
+}
+
+static void kzm9g_restart(char mode, const char *cmd)
+{
+#define RESCNT2 IOMEM(0xe6188020)
+ /* Do soft power on reset */
+ writel((1 << 31), RESCNT2);
+}
+
+static const char *kzm9g_boards_compat_dt[] __initdata = {
+ "renesas,kzm9g-reference",
+ NULL,
+};
+
+/* Please note that the clock initialisation shcheme used in
+ * sh73a0_add_early_devices_dt() and sh73a0_add_standard_devices_dt()
+ * does not work with SMP as there is a yet to be resolved lock-up in
+ * workqueue initialisation.
+ *
+ * CONFIG_SMP should be disabled when using this code.
+ */
+DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
+ .smp = smp_ops(sh73a0_smp_ops),
+ .map_io = sh73a0_map_io,
+ .init_early = sh73a0_init_delay,
+ .nr_irqs = NR_IRQS_LEGACY,
+ .init_irq = irqchip_init,
+ .init_machine = kzm_init,
+ .init_late = shmobile_init_late,
+ .init_time = shmobile_timer_init,
+ .restart = kzm9g_restart,
+ .dt_compat = kzm9g_boards_compat_dt,
+MACHINE_END
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 07/13] ARM: shmobile: parse DT and configure pinmux early on kzm9g-reference
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
GPIOs can be provided by the pinctrl subsystem, which can be initialised
by DT. Therefore DT has to be parsed before requesting GPIOs. Also non-DT
pinmux has to be configured early.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g-reference.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index caba1bb..add537c 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -47,6 +47,7 @@ static void __init kzm_init(void)
{
sh73a0_add_standard_devices_dt();
pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
+ sh73a0_pinmux_init();
#ifdef CONFIG_CACHE_L2X0
/* Early BRESP enable, Shared attribute override enable, 64K*8way */
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 07/13] ARM: shmobile: parse DT and configure pinmux early on kzm9g-reference
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
GPIOs can be provided by the pinctrl subsystem, which can be initialised
by DT. Therefore DT has to be parsed before requesting GPIOs. Also non-DT
pinmux has to be configured early.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g-reference.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index caba1bb..add537c 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -47,6 +47,7 @@ static void __init kzm_init(void)
{
sh73a0_add_standard_devices_dt();
pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
+ sh73a0_pinmux_init();
#ifdef CONFIG_CACHE_L2X0
/* Early BRESP enable, Shared attribute override enable, 64K*8way */
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 08/13] ARM: shmobile: SDHI and MMCIF interfaces to kzm9g-reference
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Add SDHI0 and SDHI2 interfaces to kzm9g-reference. With no pinctrl DT
support we cannot use GPIO card-detection and regulator switching.
Also update the MMCIF DT node to use all 8 data lines and avoid
redundant information in DT.
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
[ horms+renesas@verge.net.au: Updated for pinmux changes by Laurent Pinchart ]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 42 ++++++++++++++++++++++--
arch/arm/mach-shmobile/board-kzm9g-reference.c | 36 ++++++++++++++++++++
2 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index 06f52f9..7fad4b9 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -27,15 +27,51 @@
reg = <0x41000000 0x1e800000>;
};
- fixedregulator1v8: fixedregulator@0 {
+ reg_1p8v: regulator@0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ reg_2p8v: regulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sdhi0: sdhi@0xee100000 {
+ compatible = "renesas,shmobile-sdhi";
+ reg = <0xee100000 0x100>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 83 4
+ 0 84 4
+ 0 85 4>;
+ vmmc-supply = <®_2p8v>;
+ bus-width = <4>;
+ toshiba,mmc-has-idle-wait;
+ };
+
+ sdhi2: sdhi@0xee140000 {
+ compatible = "renesas,shmobile-sdhi";
+ reg = <0xee140000 0x100>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 104 4
+ 0 105 4>;
+ vmmc-supply = <®_2p8v>;
+ bus-width = <4>;
+ broken-cd;
+ toshiba,mmc-wrprotect-disable;
+ toshiba,mmc-has-idle-wait;
};
};
&mmcif {
- vmmc-supply = <&fixedregulator1v8>;
- vqmmc-supply = <&fixedregulator1v8>;
+ bus-width = <8>;
+ vmmc-supply = <®_1p8v>;
};
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index add537c..3056698 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -28,19 +28,48 @@
#include <linux/input.h>
#include <linux/of_platform.h>
#include <linux/pinctrl/machine.h>
+#include <linux/pinctrl/pinconf-generic.h>
#include <mach/sh73a0.h>
#include <mach/common.h>
#include <asm/hardware/cache-l2x0.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
+static unsigned long pin_pullup_conf[] = {
+ PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 0),
+};
+
static const struct pinctrl_map kzm_pinctrl_map[] = {
PIN_MAP_MUX_GROUP_DEFAULT("i2c-sh_mobile.3", "pfc-sh73a0",
"i2c3_1", "i2c3"),
+ /* MMCIF */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
+ "mmc0_data8_0", "mmc0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
+ "mmc0_ctrl_0", "mmc0"),
+ PIN_MAP_CONFIGS_PIN_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
+ "PORT279", pin_pullup_conf),
+ PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
+ "mmc0_data8_0", pin_pullup_conf),
+ /* SCIFA4 */
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
"scifa4_data", "scifa4"),
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
"scifa4_ctrl", "scifa4"),
+ /* SDHI0 */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
+ "sdhi0_data4", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
+ "sdhi0_ctrl", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
+ "sdhi0_cd", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
+ "sdhi0_wp", "sdhi0"),
+ /* SDHI2 */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.2", "pfc-sh73a0",
+ "sdhi2_data4", "sdhi2"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.2", "pfc-sh73a0",
+ "sdhi2_ctrl", "sdhi2"),
};
static void __init kzm_init(void)
@@ -49,6 +78,13 @@ static void __init kzm_init(void)
pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
sh73a0_pinmux_init();
+ /* enable SD */
+ gpio_request(GPIO_FN_SDHI0_VCCQ_MC0_ON, NULL);
+ gpio_request_one(GPIO_PORT15, GPIOF_OUT_INIT_HIGH, NULL); /* power */
+
+ gpio_request(GPIO_FN_SDHICLK2, NULL);
+ gpio_request_one(GPIO_PORT14, GPIOF_OUT_INIT_HIGH, NULL); /* power */
+
#ifdef CONFIG_CACHE_L2X0
/* Early BRESP enable, Shared attribute override enable, 64K*8way */
l2x0_init(IOMEM(0xf0100000), 0x40460000, 0x82000fff);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 08/13] ARM: shmobile: SDHI and MMCIF interfaces to kzm9g-reference
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Add SDHI0 and SDHI2 interfaces to kzm9g-reference. With no pinctrl DT
support we cannot use GPIO card-detection and regulator switching.
Also update the MMCIF DT node to use all 8 data lines and avoid
redundant information in DT.
Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
[ horms+renesas at verge.net.au: Updated for pinmux changes by Laurent Pinchart ]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 42 ++++++++++++++++++++++--
arch/arm/mach-shmobile/board-kzm9g-reference.c | 36 ++++++++++++++++++++
2 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index 06f52f9..7fad4b9 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -27,15 +27,51 @@
reg = <0x41000000 0x1e800000>;
};
- fixedregulator1v8: fixedregulator at 0 {
+ reg_1p8v: regulator at 0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ reg_2p8v: regulator at 1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sdhi0: sdhi at 0xee100000 {
+ compatible = "renesas,shmobile-sdhi";
+ reg = <0xee100000 0x100>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 83 4
+ 0 84 4
+ 0 85 4>;
+ vmmc-supply = <®_2p8v>;
+ bus-width = <4>;
+ toshiba,mmc-has-idle-wait;
+ };
+
+ sdhi2: sdhi at 0xee140000 {
+ compatible = "renesas,shmobile-sdhi";
+ reg = <0xee140000 0x100>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 104 4
+ 0 105 4>;
+ vmmc-supply = <®_2p8v>;
+ bus-width = <4>;
+ broken-cd;
+ toshiba,mmc-wrprotect-disable;
+ toshiba,mmc-has-idle-wait;
};
};
&mmcif {
- vmmc-supply = <&fixedregulator1v8>;
- vqmmc-supply = <&fixedregulator1v8>;
+ bus-width = <8>;
+ vmmc-supply = <®_1p8v>;
};
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index add537c..3056698 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -28,19 +28,48 @@
#include <linux/input.h>
#include <linux/of_platform.h>
#include <linux/pinctrl/machine.h>
+#include <linux/pinctrl/pinconf-generic.h>
#include <mach/sh73a0.h>
#include <mach/common.h>
#include <asm/hardware/cache-l2x0.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
+static unsigned long pin_pullup_conf[] = {
+ PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 0),
+};
+
static const struct pinctrl_map kzm_pinctrl_map[] = {
PIN_MAP_MUX_GROUP_DEFAULT("i2c-sh_mobile.3", "pfc-sh73a0",
"i2c3_1", "i2c3"),
+ /* MMCIF */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
+ "mmc0_data8_0", "mmc0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
+ "mmc0_ctrl_0", "mmc0"),
+ PIN_MAP_CONFIGS_PIN_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
+ "PORT279", pin_pullup_conf),
+ PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
+ "mmc0_data8_0", pin_pullup_conf),
+ /* SCIFA4 */
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
"scifa4_data", "scifa4"),
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
"scifa4_ctrl", "scifa4"),
+ /* SDHI0 */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
+ "sdhi0_data4", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
+ "sdhi0_ctrl", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
+ "sdhi0_cd", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
+ "sdhi0_wp", "sdhi0"),
+ /* SDHI2 */
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.2", "pfc-sh73a0",
+ "sdhi2_data4", "sdhi2"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.2", "pfc-sh73a0",
+ "sdhi2_ctrl", "sdhi2"),
};
static void __init kzm_init(void)
@@ -49,6 +78,13 @@ static void __init kzm_init(void)
pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
sh73a0_pinmux_init();
+ /* enable SD */
+ gpio_request(GPIO_FN_SDHI0_VCCQ_MC0_ON, NULL);
+ gpio_request_one(GPIO_PORT15, GPIOF_OUT_INIT_HIGH, NULL); /* power */
+
+ gpio_request(GPIO_FN_SDHICLK2, NULL);
+ gpio_request_one(GPIO_PORT14, GPIOF_OUT_INIT_HIGH, NULL); /* power */
+
#ifdef CONFIG_CACHE_L2X0
/* Early BRESP enable, Shared attribute override enable, 64K*8way */
l2x0_init(IOMEM(0xf0100000), 0x40460000, 0x82000fff);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 09/13] ARM: shmobile: simplify kzm9g Kconfig dependencies
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reference kernel configurations for armadillo800eva and kzm9g boards do not
have to depend on their respective "legacy" configurations, doing device
instantiation in .c, they can be configured and built independently.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
[horms+renesas@verge.net.au: created separate patch for kzm9g portion]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 0c48af9..ab2bb71 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -131,7 +131,11 @@ config MACH_KZM9G
config MACH_KZM9G_REFERENCE
bool "KZM-A9-GT board - Reference Device Tree Implementation"
- depends on MACH_KZM9G
+ depends on ARCH_SH73A0
+ select ARCH_REQUIRE_GPIOLIB
+ select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select USE_OF
---help---
Use reference implementation of KZM-A9-GT board support
which makes as greater use of device tree at the expense
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 09/13] ARM: shmobile: simplify kzm9g Kconfig dependencies
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reference kernel configurations for armadillo800eva and kzm9g boards do not
have to depend on their respective "legacy" configurations, doing device
instantiation in .c, they can be configured and built independently.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
[horms+renesas at verge.net.au: created separate patch for kzm9g portion]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 0c48af9..ab2bb71 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -131,7 +131,11 @@ config MACH_KZM9G
config MACH_KZM9G_REFERENCE
bool "KZM-A9-GT board - Reference Device Tree Implementation"
- depends on MACH_KZM9G
+ depends on ARCH_SH73A0
+ select ARCH_REQUIRE_GPIOLIB
+ select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select USE_OF
---help---
Use reference implementation of KZM-A9-GT board support
which makes as greater use of device tree at the expense
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 10/13] ARM: shmobile: kzm9g: Remove warning about SMP
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Remove warning about SMP not working with the
clock initialisation used for kzm9g reference.
This is resolved by not selecting CONFIG_PREEMPT.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g-reference.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 3056698..4da3501 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -103,13 +103,6 @@ static const char *kzm9g_boards_compat_dt[] __initdata = {
NULL,
};
-/* Please note that the clock initialisation shcheme used in
- * sh73a0_add_early_devices_dt() and sh73a0_add_standard_devices_dt()
- * does not work with SMP as there is a yet to be resolved lock-up in
- * workqueue initialisation.
- *
- * CONFIG_SMP should be disabled when using this code.
- */
DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
.smp = smp_ops(sh73a0_smp_ops),
.map_io = sh73a0_map_io,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 10/13] ARM: shmobile: kzm9g: Remove warning about SMP
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Remove warning about SMP not working with the
clock initialisation used for kzm9g reference.
This is resolved by not selecting CONFIG_PREEMPT.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g-reference.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 3056698..4da3501 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -103,13 +103,6 @@ static const char *kzm9g_boards_compat_dt[] __initdata = {
NULL,
};
-/* Please note that the clock initialisation shcheme used in
- * sh73a0_add_early_devices_dt() and sh73a0_add_standard_devices_dt()
- * does not work with SMP as there is a yet to be resolved lock-up in
- * workqueue initialisation.
- *
- * CONFIG_SMP should be disabled when using this code.
- */
DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
.smp = smp_ops(sh73a0_smp_ops),
.map_io = sh73a0_map_io,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 11/13] ARM: shmobile: kzm9g: Trim reference DT_MACHINE_START
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:17 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Remove .init_late and .restart from DT_MACHINE_START
for kzm9g reference as these are not necessary to
bring the board up which is the main aim of kzm9g reference.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g-reference.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 4da3501..e93473c 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -91,13 +91,6 @@ static void __init kzm_init(void)
#endif
}
-static void kzm9g_restart(char mode, const char *cmd)
-{
-#define RESCNT2 IOMEM(0xe6188020)
- /* Do soft power on reset */
- writel((1 << 31), RESCNT2);
-}
-
static const char *kzm9g_boards_compat_dt[] __initdata = {
"renesas,kzm9g-reference",
NULL,
@@ -110,8 +103,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
.nr_irqs = NR_IRQS_LEGACY,
.init_irq = irqchip_init,
.init_machine = kzm_init,
- .init_late = shmobile_init_late,
.init_time = shmobile_timer_init,
- .restart = kzm9g_restart,
.dt_compat = kzm9g_boards_compat_dt,
MACHINE_END
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 11/13] ARM: shmobile: kzm9g: Trim reference DT_MACHINE_START
@ 2013-03-19 2:17 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:17 UTC (permalink / raw)
To: linux-arm-kernel
Remove .init_late and .restart from DT_MACHINE_START
for kzm9g reference as these are not necessary to
bring the board up which is the main aim of kzm9g reference.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g-reference.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 4da3501..e93473c 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -91,13 +91,6 @@ static void __init kzm_init(void)
#endif
}
-static void kzm9g_restart(char mode, const char *cmd)
-{
-#define RESCNT2 IOMEM(0xe6188020)
- /* Do soft power on reset */
- writel((1 << 31), RESCNT2);
-}
-
static const char *kzm9g_boards_compat_dt[] __initdata = {
"renesas,kzm9g-reference",
NULL,
@@ -110,8 +103,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
.nr_irqs = NR_IRQS_LEGACY,
.init_irq = irqchip_init,
.init_machine = kzm_init,
- .init_late = shmobile_init_late,
.init_time = shmobile_timer_init,
- .restart = kzm9g_restart,
.dt_compat = kzm9g_boards_compat_dt,
MACHINE_END
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 12/13] ARM: shmobile: marzen: Use gic_iid macro for ICCIAR / interrupt ID
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:18 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:18 UTC (permalink / raw)
To: linux-arm-kernel
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
ARM: shmobile: add gic_iid macro for ICCIAR / interrupt ID
enabled to use gic_iid macro.
This patch exchange current GIC interrupt setting
from gic_spi() to gic_iid()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
[ horms+renesas@verge.net.au: Split irq.h portion into a separate patch ]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-marzen.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 5852331..2333a2d 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -67,7 +67,7 @@ static struct resource smsc911x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(28), /* IRQ 1 */
+ .start = gic_iid(0x3c), /* IRQ 1 */
.flags = IORESOURCE_IRQ,
},
};
@@ -97,7 +97,7 @@ static struct resource sdhi0_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(104),
+ .start = gic_iid(0x88),
.flags = IORESOURCE_IRQ,
},
};
@@ -215,7 +215,7 @@ static struct resource ehci0_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(44),
+ .start = gic_iid(0x4c),
.flags = IORESOURCE_IRQ,
},
};
@@ -239,7 +239,7 @@ static struct resource ehci1_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(45),
+ .start = gic_iid(0x4d),
.flags = IORESOURCE_IRQ,
},
};
@@ -269,7 +269,7 @@ static struct resource ohci0_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(44),
+ .start = gic_iid(0x4c),
.flags = IORESOURCE_IRQ,
},
};
@@ -293,7 +293,7 @@ static struct resource ohci1_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(45),
+ .start = gic_iid(0x4d),
.flags = IORESOURCE_IRQ,
},
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 12/13] ARM: shmobile: marzen: Use gic_iid macro for ICCIAR / interrupt ID
@ 2013-03-19 2:18 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:18 UTC (permalink / raw)
To: linux-arm-kernel
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
ARM: shmobile: add gic_iid macro for ICCIAR / interrupt ID
enabled to use gic_iid macro.
This patch exchange current GIC interrupt setting
from gic_spi() to gic_iid()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
[ horms+renesas at verge.net.au: Split irq.h portion into a separate patch ]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-marzen.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 5852331..2333a2d 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -67,7 +67,7 @@ static struct resource smsc911x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(28), /* IRQ 1 */
+ .start = gic_iid(0x3c), /* IRQ 1 */
.flags = IORESOURCE_IRQ,
},
};
@@ -97,7 +97,7 @@ static struct resource sdhi0_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(104),
+ .start = gic_iid(0x88),
.flags = IORESOURCE_IRQ,
},
};
@@ -215,7 +215,7 @@ static struct resource ehci0_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(44),
+ .start = gic_iid(0x4c),
.flags = IORESOURCE_IRQ,
},
};
@@ -239,7 +239,7 @@ static struct resource ehci1_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(45),
+ .start = gic_iid(0x4d),
.flags = IORESOURCE_IRQ,
},
};
@@ -269,7 +269,7 @@ static struct resource ohci0_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(44),
+ .start = gic_iid(0x4c),
.flags = IORESOURCE_IRQ,
},
};
@@ -293,7 +293,7 @@ static struct resource ohci1_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = gic_spi(45),
+ .start = gic_iid(0x4d),
.flags = IORESOURCE_IRQ,
},
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 13/13] ARM: shmobile: kzm9g: correct smsc regulator registration
2013-03-19 2:17 ` Simon Horman
@ 2013-03-19 2:18 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:18 UTC (permalink / raw)
To: linux-arm-kernel
Correct the name of smsc devices used for regulator registration
allowing the regulators to be found and used.
This eliminates the need for CONFIG_REGULATOR_DUMMY
when CONFIG_REGULATOR is set.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
index c1c0401..d2ace3a 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -63,8 +63,8 @@
/* Dummy supplies, where voltage doesn't matter */
static struct regulator_consumer_supply dummy_supplies[] = {
- REGULATOR_SUPPLY("vddvario", "smsc911x"),
- REGULATOR_SUPPLY("vdd33a", "smsc911x"),
+ REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+ REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
};
/*
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread* [PATCH 13/13] ARM: shmobile: kzm9g: correct smsc regulator registration
@ 2013-03-19 2:18 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-19 2:18 UTC (permalink / raw)
To: linux-arm-kernel
Correct the name of smsc devices used for regulator registration
allowing the regulators to be found and used.
This eliminates the need for CONFIG_REGULATOR_DUMMY
when CONFIG_REGULATOR is set.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/board-kzm9g.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
index c1c0401..d2ace3a 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -63,8 +63,8 @@
/* Dummy supplies, where voltage doesn't matter */
static struct regulator_consumer_supply dummy_supplies[] = {
- REGULATOR_SUPPLY("vddvario", "smsc911x"),
- REGULATOR_SUPPLY("vdd33a", "smsc911x"),
+ REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
+ REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
};
/*
--
1.7.10.4
^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-19 2:17 ` Simon Horman
@ 2013-03-21 17:18 ` Arnd Bergmann
-1 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-21 17:18 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 19 March 2013, Simon Horman wrote:
> ----------------------------------------------------------------
> Renesas ARM-based SoC board updates for v3.10
>
> This is based on a merge of the following:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-pinmux-for-v3.10
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-for-v3.10
Pulled into next/boards.
Please verify that I have pulled everything you sent me. If not, it my mistake.
Thanks,
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-21 17:18 ` Arnd Bergmann
0 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-21 17:18 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 19 March 2013, Simon Horman wrote:
> ----------------------------------------------------------------
> Renesas ARM-based SoC board updates for v3.10
>
> This is based on a merge of the following:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-pinmux-for-v3.10
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-for-v3.10
Pulled into next/boards.
Please verify that I have pulled everything you sent me. If not, it my mistake.
Thanks,
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-21 17:18 ` Arnd Bergmann
@ 2013-03-21 19:22 ` Arnd Bergmann
-1 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-21 19:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 21 March 2013, Arnd Bergmann wrote:
> On Tuesday 19 March 2013, Simon Horman wrote:
> Pulled into next/boards.
>
> Please verify that I have pulled everything you sent me. If not, it my mistake.
With everything applied, I now get one build failure and a new build warning:
=> build/mackerel_defconfig/faillog <=
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c: In function 'mackerel_init':
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1476:15: error: 'GPIO_FN_MMCD0_0' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1476:15: note: each undeclared identifier is reported only once for each function it appears in
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1477:15: error: 'GPIO_FN_MMCD0_1' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1478:15: error: 'GPIO_FN_MMCD0_2' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1479:15: error: 'GPIO_FN_MMCD0_3' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1480:15: error: 'GPIO_FN_MMCD0_4' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1481:15: error: 'GPIO_FN_MMCD0_5' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1482:15: error: 'GPIO_FN_MMCD0_6' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1483:15: error: 'GPIO_FN_MMCD0_7' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1484:15: error: 'GPIO_FN_MMCCMD0' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1485:15: error: 'GPIO_FN_MMCCLK0' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1489:15: error: 'GPIO_FN_SDHICMD2' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1490:15: error: 'GPIO_FN_SDHICLK2' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1491:15: error: 'GPIO_FN_SDHID2_3' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1492:15: error: 'GPIO_FN_SDHID2_2' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1493:15: error: 'GPIO_FN_SDHID2_1' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1494:15: error: 'GPIO_FN_SDHID2_0' undeclared (first use in this function)
make[3]: *** [arch/arm/mach-shmobile/board-mackerel.o] Error 1
make[3]: Target `__build' not remade because of errors.
make[2]: *** [arch/arm/mach-shmobile] Error 2
make[2]: Target `_all' not remade because of errors.
make[1]: *** [sub-make] Error 2
make[1]: Target `_all' not remade because of errors.
=> build/marzen_defconfig/faillog <=
In file included from /git/arm-soc/arch/arm/mach-shmobile/setup-r8a7779.c:24:0:
/git/arm-soc/include/linux/of_platform.h:107:13: warning: 'struct of_device_id' declared inside parameter list [enabled by default]
/git/arm-soc/include/linux/of_platform.h:107:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
/git/arm-soc/include/linux/of_platform.h:107:13: warning: 'struct device_node' declared inside parameter list [enabled by default]
I have not tried bisecting the problems. Could you find out what is going on
and send bug fixes to apply on top?
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-21 19:22 ` Arnd Bergmann
0 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-21 19:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 21 March 2013, Arnd Bergmann wrote:
> On Tuesday 19 March 2013, Simon Horman wrote:
> Pulled into next/boards.
>
> Please verify that I have pulled everything you sent me. If not, it my mistake.
With everything applied, I now get one build failure and a new build warning:
==> build/mackerel_defconfig/faillog <==
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c: In function 'mackerel_init':
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1476:15: error: 'GPIO_FN_MMCD0_0' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1476:15: note: each undeclared identifier is reported only once for each function it appears in
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1477:15: error: 'GPIO_FN_MMCD0_1' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1478:15: error: 'GPIO_FN_MMCD0_2' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1479:15: error: 'GPIO_FN_MMCD0_3' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1480:15: error: 'GPIO_FN_MMCD0_4' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1481:15: error: 'GPIO_FN_MMCD0_5' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1482:15: error: 'GPIO_FN_MMCD0_6' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1483:15: error: 'GPIO_FN_MMCD0_7' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1484:15: error: 'GPIO_FN_MMCCMD0' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1485:15: error: 'GPIO_FN_MMCCLK0' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1489:15: error: 'GPIO_FN_SDHICMD2' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1490:15: error: 'GPIO_FN_SDHICLK2' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1491:15: error: 'GPIO_FN_SDHID2_3' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1492:15: error: 'GPIO_FN_SDHID2_2' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1493:15: error: 'GPIO_FN_SDHID2_1' undeclared (first use in this function)
/git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1494:15: error: 'GPIO_FN_SDHID2_0' undeclared (first use in this function)
make[3]: *** [arch/arm/mach-shmobile/board-mackerel.o] Error 1
make[3]: Target `__build' not remade because of errors.
make[2]: *** [arch/arm/mach-shmobile] Error 2
make[2]: Target `_all' not remade because of errors.
make[1]: *** [sub-make] Error 2
make[1]: Target `_all' not remade because of errors.
==> build/marzen_defconfig/faillog <==
In file included from /git/arm-soc/arch/arm/mach-shmobile/setup-r8a7779.c:24:0:
/git/arm-soc/include/linux/of_platform.h:107:13: warning: 'struct of_device_id' declared inside parameter list [enabled by default]
/git/arm-soc/include/linux/of_platform.h:107:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
/git/arm-soc/include/linux/of_platform.h:107:13: warning: 'struct device_node' declared inside parameter list [enabled by default]
I have not tried bisecting the problems. Could you find out what is going on
and send bug fixes to apply on top?
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-21 19:22 ` Arnd Bergmann
@ 2013-03-22 0:32 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-22 0:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 21, 2013 at 07:22:56PM +0000, Arnd Bergmann wrote:
> On Thursday 21 March 2013, Arnd Bergmann wrote:
> > On Tuesday 19 March 2013, Simon Horman wrote:
>
> > Pulled into next/boards.
> >
> > Please verify that I have pulled everything you sent me. If not, it my mistake.
>
> With everything applied, I now get one build failure and a new build warning:
>
> => build/mackerel_defconfig/faillog <=
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c: In function 'mackerel_init':
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1476:15: error: 'GPIO_FN_MMCD0_0' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1476:15: note: each undeclared identifier is reported only once for each function it appears in
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1477:15: error: 'GPIO_FN_MMCD0_1' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1478:15: error: 'GPIO_FN_MMCD0_2' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1479:15: error: 'GPIO_FN_MMCD0_3' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1480:15: error: 'GPIO_FN_MMCD0_4' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1481:15: error: 'GPIO_FN_MMCD0_5' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1482:15: error: 'GPIO_FN_MMCD0_6' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1483:15: error: 'GPIO_FN_MMCD0_7' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1484:15: error: 'GPIO_FN_MMCCMD0' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1485:15: error: 'GPIO_FN_MMCCLK0' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1489:15: error: 'GPIO_FN_SDHICMD2' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1490:15: error: 'GPIO_FN_SDHICLK2' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1491:15: error: 'GPIO_FN_SDHID2_3' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1492:15: error: 'GPIO_FN_SDHID2_2' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1493:15: error: 'GPIO_FN_SDHID2_1' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1494:15: error: 'GPIO_FN_SDHID2_0' undeclared (first use in this function)
> make[3]: *** [arch/arm/mach-shmobile/board-mackerel.o] Error 1
> make[3]: Target `__build' not remade because of errors.
> make[2]: *** [arch/arm/mach-shmobile] Error 2
> make[2]: Target `_all' not remade because of errors.
> make[1]: *** [sub-make] Error 2
> make[1]: Target `_all' not remade because of errors.
>
> => build/marzen_defconfig/faillog <=
> In file included from /git/arm-soc/arch/arm/mach-shmobile/setup-r8a7779.c:24:0:
> /git/arm-soc/include/linux/of_platform.h:107:13: warning: 'struct of_device_id' declared inside parameter list [enabled by default]
> /git/arm-soc/include/linux/of_platform.h:107:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> /git/arm-soc/include/linux/of_platform.h:107:13: warning: 'struct device_node' declared inside parameter list [enabled by default]
>
>
> I have not tried bisecting the problems. Could you find out what is going on
> and send bug fixes to apply on top?
Thanks Arnd,
I noticed this only slightly before you did and I apologise for not catching it earlier.
I have a fix queued up and will send you a pull request shortly.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-22 0:32 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-22 0:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 21, 2013 at 07:22:56PM +0000, Arnd Bergmann wrote:
> On Thursday 21 March 2013, Arnd Bergmann wrote:
> > On Tuesday 19 March 2013, Simon Horman wrote:
>
> > Pulled into next/boards.
> >
> > Please verify that I have pulled everything you sent me. If not, it my mistake.
>
> With everything applied, I now get one build failure and a new build warning:
>
> ==> build/mackerel_defconfig/faillog <==
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c: In function 'mackerel_init':
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1476:15: error: 'GPIO_FN_MMCD0_0' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1476:15: note: each undeclared identifier is reported only once for each function it appears in
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1477:15: error: 'GPIO_FN_MMCD0_1' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1478:15: error: 'GPIO_FN_MMCD0_2' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1479:15: error: 'GPIO_FN_MMCD0_3' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1480:15: error: 'GPIO_FN_MMCD0_4' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1481:15: error: 'GPIO_FN_MMCD0_5' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1482:15: error: 'GPIO_FN_MMCD0_6' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1483:15: error: 'GPIO_FN_MMCD0_7' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1484:15: error: 'GPIO_FN_MMCCMD0' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1485:15: error: 'GPIO_FN_MMCCLK0' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1489:15: error: 'GPIO_FN_SDHICMD2' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1490:15: error: 'GPIO_FN_SDHICLK2' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1491:15: error: 'GPIO_FN_SDHID2_3' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1492:15: error: 'GPIO_FN_SDHID2_2' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1493:15: error: 'GPIO_FN_SDHID2_1' undeclared (first use in this function)
> /git/arm-soc/arch/arm/mach-shmobile/board-mackerel.c:1494:15: error: 'GPIO_FN_SDHID2_0' undeclared (first use in this function)
> make[3]: *** [arch/arm/mach-shmobile/board-mackerel.o] Error 1
> make[3]: Target `__build' not remade because of errors.
> make[2]: *** [arch/arm/mach-shmobile] Error 2
> make[2]: Target `_all' not remade because of errors.
> make[1]: *** [sub-make] Error 2
> make[1]: Target `_all' not remade because of errors.
>
> ==> build/marzen_defconfig/faillog <==
> In file included from /git/arm-soc/arch/arm/mach-shmobile/setup-r8a7779.c:24:0:
> /git/arm-soc/include/linux/of_platform.h:107:13: warning: 'struct of_device_id' declared inside parameter list [enabled by default]
> /git/arm-soc/include/linux/of_platform.h:107:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> /git/arm-soc/include/linux/of_platform.h:107:13: warning: 'struct device_node' declared inside parameter list [enabled by default]
>
>
> I have not tried bisecting the problems. Could you find out what is going on
> and send bug fixes to apply on top?
Thanks Arnd,
I noticed this only slightly before you did and I apologise for not catching it earlier.
I have a fix queued up and will send you a pull request shortly.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-21 17:18 ` Arnd Bergmann
@ 2013-03-22 0:58 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-22 0:58 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 21, 2013 at 05:18:32PM +0000, Arnd Bergmann wrote:
> On Tuesday 19 March 2013, Simon Horman wrote:
>
> > ----------------------------------------------------------------
> > Renesas ARM-based SoC board updates for v3.10
> >
> > This is based on a merge of the following:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-pinmux-for-v3.10
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-for-v3.10
>
> Pulled into next/boards.
>
> Please verify that I have pulled everything you sent me. If not, it my mistake.
Thanks.
Sorry about sending so many all at once. There were quite a few changes
queued up and it might have been better if I flushed some of them out
a bit earlier.
Of the batch that I sent last week, I think you are missing the following one:
From: Simon Horman <horms+renesas@verge.net.au>
To: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>
Cc: linux-sh@vger.kernel.org, arm@kernel.org,
linux-arm-kernel@lists.infradead.org,
Paul Mundt <lethal@linux-sh.org>,
Magnus Damm <magnus.damm@gmail.com>
Subject: [GIT PULL] ARM and SH based SoC clocksource update for v3.10
Date: Mon, 18 Mar 2013 22:02:26 +0900
Message-Id: <1363611758-6655-1-git-send-email-horms+renesas@verge.net.au>
Hi Olof, Hi Arnd,
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-clocksource-for-v3.10
for you to fetch changes up to 342896a5c565e38dfb87954f362735f03ae1efb0:
clocksource: sh_mtu2: Set initcall level to subsys (2013-03-13 02:24:37 +0900)
----------------------------------------------------------------
Renesas ARM and SH based SoC clocksource update for v3.10
I has been agreed by Paul Mundt and myself, that it would be best to take
these changes through the renesas tree and in turn the arm-soc tree.
----------------------------------------------------------------
Magnus Damm (8):
clocksource: sh_cmt: Take care of clk_put() when setup_irq() fails
clocksource: sh_cmt: Initialize 'max_match_value' and 'lock' in sh_cmt_setup()
clocksource: sh_cmt: Introduce per-register functions
clocksource: sh_cmt: Consolidate platform_set_drvdata() call
clocksource: sh_cmt: CMSTR and CMCSR register access update
clocksource: sh_cmt: CMCNT and CMCOR register access update
clocksource: sh_cmt: Add control register callbacks
clocksource: sh_cmt: Add CMT register layout comment
Simon Horman (4):
clocksource: sh_cmt: Set initcall level to subsys
clocksource: sh_tmu: Set initcall level to subsys
clocksource: em_sti: Set initcall level to subsys
clocksource: sh_mtu2: Set initcall level to subsys
drivers/clocksource/em_sti.c | 13 ++-
drivers/clocksource/sh_cmt.c | 189 +++++++++++++++++++++++++----------------
drivers/clocksource/sh_mtu2.c | 2 +-
drivers/clocksource/sh_tmu.c | 2 +-
4 files changed, 132 insertions(+), 74 deletions(-)
^ permalink raw reply [flat|nested] 114+ messages in thread* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-22 0:58 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-22 0:58 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 21, 2013 at 05:18:32PM +0000, Arnd Bergmann wrote:
> On Tuesday 19 March 2013, Simon Horman wrote:
>
> > ----------------------------------------------------------------
> > Renesas ARM-based SoC board updates for v3.10
> >
> > This is based on a merge of the following:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-pinmux-for-v3.10
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-for-v3.10
>
> Pulled into next/boards.
>
> Please verify that I have pulled everything you sent me. If not, it my mistake.
Thanks.
Sorry about sending so many all at once. There were quite a few changes
queued up and it might have been better if I flushed some of them out
a bit earlier.
Of the batch that I sent last week, I think you are missing the following one:
From: Simon Horman <horms+renesas@verge.net.au>
To: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>
Cc: linux-sh at vger.kernel.org, arm at kernel.org,
linux-arm-kernel at lists.infradead.org,
Paul Mundt <lethal@linux-sh.org>,
Magnus Damm <magnus.damm@gmail.com>
Subject: [GIT PULL] ARM and SH based SoC clocksource update for v3.10
Date: Mon, 18 Mar 2013 22:02:26 +0900
Message-Id: <1363611758-6655-1-git-send-email-horms+renesas@verge.net.au>
Hi Olof, Hi Arnd,
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-clocksource-for-v3.10
for you to fetch changes up to 342896a5c565e38dfb87954f362735f03ae1efb0:
clocksource: sh_mtu2: Set initcall level to subsys (2013-03-13 02:24:37 +0900)
----------------------------------------------------------------
Renesas ARM and SH based SoC clocksource update for v3.10
I has been agreed by Paul Mundt and myself, that it would be best to take
these changes through the renesas tree and in turn the arm-soc tree.
----------------------------------------------------------------
Magnus Damm (8):
clocksource: sh_cmt: Take care of clk_put() when setup_irq() fails
clocksource: sh_cmt: Initialize 'max_match_value' and 'lock' in sh_cmt_setup()
clocksource: sh_cmt: Introduce per-register functions
clocksource: sh_cmt: Consolidate platform_set_drvdata() call
clocksource: sh_cmt: CMSTR and CMCSR register access update
clocksource: sh_cmt: CMCNT and CMCOR register access update
clocksource: sh_cmt: Add control register callbacks
clocksource: sh_cmt: Add CMT register layout comment
Simon Horman (4):
clocksource: sh_cmt: Set initcall level to subsys
clocksource: sh_tmu: Set initcall level to subsys
clocksource: em_sti: Set initcall level to subsys
clocksource: sh_mtu2: Set initcall level to subsys
drivers/clocksource/em_sti.c | 13 ++-
drivers/clocksource/sh_cmt.c | 189 +++++++++++++++++++++++++----------------
drivers/clocksource/sh_mtu2.c | 2 +-
drivers/clocksource/sh_tmu.c | 2 +-
4 files changed, 132 insertions(+), 74 deletions(-)
^ permalink raw reply [flat|nested] 114+ messages in thread* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-22 0:58 ` Simon Horman
@ 2013-03-22 12:40 ` Arnd Bergmann
-1 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-22 12:40 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 22 March 2013, Simon Horman wrote:
> Sorry about sending so many all at once. There were quite a few changes
> queued up and it might have been better if I flushed some of them out
> a bit earlier.
>
> Of the batch that I sent last week, I think you are missing the following one:
>
Right, I've pulled it into next/drivers now. Thanks for checking this.
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-22 12:40 ` Arnd Bergmann
0 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-22 12:40 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 22 March 2013, Simon Horman wrote:
> Sorry about sending so many all at once. There were quite a few changes
> queued up and it might have been better if I flushed some of them out
> a bit earlier.
>
> Of the batch that I sent last week, I think you are missing the following one:
>
Right, I've pulled it into next/drivers now. Thanks for checking this.
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-22 12:40 ` Arnd Bergmann
@ 2013-03-22 13:52 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-22 13:52 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> On Friday 22 March 2013, Simon Horman wrote:
> > Sorry about sending so many all at once. There were quite a few changes
> > queued up and it might have been better if I flushed some of them out
> > a bit earlier.
> >
> > Of the batch that I sent last week, I think you are missing the following one:
> >
>
> Right, I've pulled it into next/drivers now. Thanks for checking this.
Thanks. I now have no outstanding pull requests.
I do have a few new patches in my tree.
I plan to let a few more accumulate before sending the next pull request(s).
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-22 13:52 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-22 13:52 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> On Friday 22 March 2013, Simon Horman wrote:
> > Sorry about sending so many all at once. There were quite a few changes
> > queued up and it might have been better if I flushed some of them out
> > a bit earlier.
> >
> > Of the batch that I sent last week, I think you are missing the following one:
> >
>
> Right, I've pulled it into next/drivers now. Thanks for checking this.
Thanks. I now have no outstanding pull requests.
I do have a few new patches in my tree.
I plan to let a few more accumulate before sending the next pull request(s).
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-22 13:52 ` Simon Horman
@ 2013-03-22 15:39 ` Arnd Bergmann
-1 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-22 15:39 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 22 March 2013, Simon Horman wrote:
> On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> > On Friday 22 March 2013, Simon Horman wrote:
> > > Sorry about sending so many all at once. There were quite a few changes
> > > queued up and it might have been better if I flushed some of them out
> > > a bit earlier.
> > >
> > > Of the batch that I sent last week, I think you are missing the following one:
> > >
> >
> > Right, I've pulled it into next/drivers now. Thanks for checking this.
>
> Thanks. I now have no outstanding pull requests.
>
> I do have a few new patches in my tree.
> I plan to let a few more accumulate before sending the next pull request(s).
Ok, sounds good.
One general question about your plans (probably more for Magnus than for you):
What is your expected time line for moving shmobile under
CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
there is also still a lot to be done.
I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
most of the work would be changing drivers/sh/clk to integrate into the common
clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
AUTO_ZRELADDR. Are those things you think can be done for 3.11?
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-22 15:39 ` Arnd Bergmann
0 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-22 15:39 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 22 March 2013, Simon Horman wrote:
> On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> > On Friday 22 March 2013, Simon Horman wrote:
> > > Sorry about sending so many all at once. There were quite a few changes
> > > queued up and it might have been better if I flushed some of them out
> > > a bit earlier.
> > >
> > > Of the batch that I sent last week, I think you are missing the following one:
> > >
> >
> > Right, I've pulled it into next/drivers now. Thanks for checking this.
>
> Thanks. I now have no outstanding pull requests.
>
> I do have a few new patches in my tree.
> I plan to let a few more accumulate before sending the next pull request(s).
Ok, sounds good.
One general question about your plans (probably more for Magnus than for you):
What is your expected time line for moving shmobile under
CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
there is also still a lot to be done.
I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
most of the work would be changing drivers/sh/clk to integrate into the common
clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
AUTO_ZRELADDR. Are those things you think can be done for 3.11?
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-22 15:39 ` Arnd Bergmann
@ 2013-03-27 5:30 ` Simon Horman
-1 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-27 5:30 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 22, 2013 at 03:39:39PM +0000, Arnd Bergmann wrote:
> On Friday 22 March 2013, Simon Horman wrote:
> > On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> > > On Friday 22 March 2013, Simon Horman wrote:
> > > > Sorry about sending so many all at once. There were quite a few changes
> > > > queued up and it might have been better if I flushed some of them out
> > > > a bit earlier.
> > > >
> > > > Of the batch that I sent last week, I think you are missing the following one:
> > > >
> > >
> > > Right, I've pulled it into next/drivers now. Thanks for checking this.
> >
> > Thanks. I now have no outstanding pull requests.
> >
> > I do have a few new patches in my tree.
> > I plan to let a few more accumulate before sending the next pull request(s).
>
> Ok, sounds good.
>
> One general question about your plans (probably more for Magnus than for you):
Indeed, it is more for Magnus than I.
> What is your expected time line for moving shmobile under
> CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
> there is also still a lot to be done.
>
> I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> most of the work would be changing drivers/sh/clk to integrate into the common
> clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> AUTO_ZRELADDR. Are those things you think can be done for 3.11?
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-27 5:30 ` Simon Horman
0 siblings, 0 replies; 114+ messages in thread
From: Simon Horman @ 2013-03-27 5:30 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 22, 2013 at 03:39:39PM +0000, Arnd Bergmann wrote:
> On Friday 22 March 2013, Simon Horman wrote:
> > On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> > > On Friday 22 March 2013, Simon Horman wrote:
> > > > Sorry about sending so many all at once. There were quite a few changes
> > > > queued up and it might have been better if I flushed some of them out
> > > > a bit earlier.
> > > >
> > > > Of the batch that I sent last week, I think you are missing the following one:
> > > >
> > >
> > > Right, I've pulled it into next/drivers now. Thanks for checking this.
> >
> > Thanks. I now have no outstanding pull requests.
> >
> > I do have a few new patches in my tree.
> > I plan to let a few more accumulate before sending the next pull request(s).
>
> Ok, sounds good.
>
> One general question about your plans (probably more for Magnus than for you):
Indeed, it is more for Magnus than I.
> What is your expected time line for moving shmobile under
> CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
> there is also still a lot to be done.
>
> I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> most of the work would be changing drivers/sh/clk to integrate into the common
> clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> AUTO_ZRELADDR. Are those things you think can be done for 3.11?
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-22 15:39 ` Arnd Bergmann
@ 2013-03-27 9:54 ` Magnus Damm
-1 siblings, 0 replies; 114+ messages in thread
From: Magnus Damm @ 2013-03-27 9:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Thanks for your email.
On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 22 March 2013, Simon Horman wrote:
>> On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
>> > On Friday 22 March 2013, Simon Horman wrote:
>> > > Sorry about sending so many all at once. There were quite a few changes
>> > > queued up and it might have been better if I flushed some of them out
>> > > a bit earlier.
>> > >
>> > > Of the batch that I sent last week, I think you are missing the following one:
>> > >
>> >
>> > Right, I've pulled it into next/drivers now. Thanks for checking this.
>>
>> Thanks. I now have no outstanding pull requests.
>>
>> I do have a few new patches in my tree.
>> I plan to let a few more accumulate before sending the next pull request(s).
>
> Ok, sounds good.
>
> One general question about your plans (probably more for Magnus than for you):
> What is your expected time line for moving shmobile under
> CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
> there is also still a lot to be done.
Indeed, there is still a lot to be done!
> I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> most of the work would be changing drivers/sh/clk to integrate into the common
> clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> AUTO_ZRELADDR. Are those things you think can be done for 3.11?
Good to hear that most ARM platforms will be converted by v3.10. This
is definitely something that I want to make happen for mach-shmobile
as well.
Our biggest challenge now is the move to common clocks. I suspect that
moving all our boards and SoCs to common clocks will take much longer
than v3.11 I'm afraid.
Starting with something smaller like EMEV2 may be a good first step.
So somehow I'd like to start converting them one by one, perhaps also
moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
an incremental fashion. Do you happen to have any example subarch that
has been migrated in an increment fashion already?
Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
should be enabled for the mach-shmobile bits that are used with
CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
recommendations would be very welcome!
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-27 9:54 ` Magnus Damm
0 siblings, 0 replies; 114+ messages in thread
From: Magnus Damm @ 2013-03-27 9:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Thanks for your email.
On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 22 March 2013, Simon Horman wrote:
>> On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
>> > On Friday 22 March 2013, Simon Horman wrote:
>> > > Sorry about sending so many all at once. There were quite a few changes
>> > > queued up and it might have been better if I flushed some of them out
>> > > a bit earlier.
>> > >
>> > > Of the batch that I sent last week, I think you are missing the following one:
>> > >
>> >
>> > Right, I've pulled it into next/drivers now. Thanks for checking this.
>>
>> Thanks. I now have no outstanding pull requests.
>>
>> I do have a few new patches in my tree.
>> I plan to let a few more accumulate before sending the next pull request(s).
>
> Ok, sounds good.
>
> One general question about your plans (probably more for Magnus than for you):
> What is your expected time line for moving shmobile under
> CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
> there is also still a lot to be done.
Indeed, there is still a lot to be done!
> I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> most of the work would be changing drivers/sh/clk to integrate into the common
> clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> AUTO_ZRELADDR. Are those things you think can be done for 3.11?
Good to hear that most ARM platforms will be converted by v3.10. This
is definitely something that I want to make happen for mach-shmobile
as well.
Our biggest challenge now is the move to common clocks. I suspect that
moving all our boards and SoCs to common clocks will take much longer
than v3.11 I'm afraid.
Starting with something smaller like EMEV2 may be a good first step.
So somehow I'd like to start converting them one by one, perhaps also
moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
an incremental fashion. Do you happen to have any example subarch that
has been migrated in an increment fashion already?
Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
should be enabled for the mach-shmobile bits that are used with
CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
recommendations would be very welcome!
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-27 9:54 ` Magnus Damm
@ 2013-03-27 11:37 ` Arnd Bergmann
-1 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-27 11:37 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 27 March 2013, Magnus Damm wrote:
> On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 22 March 2013, Simon Horman wrote:
> > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> > most of the work would be changing drivers/sh/clk to integrate into the common
> > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> > AUTO_ZRELADDR. Are those things you think can be done for 3.11?
>
> Good to hear that most ARM platforms will be converted by v3.10. This
> is definitely something that I want to make happen for mach-shmobile
> as well.
>
> Our biggest challenge now is the move to common clocks. I suspect that
> moving all our boards and SoCs to common clocks will take much longer
> than v3.11 I'm afraid.
Ok, I see. If you think it's not likely to be ready for 3.12, we might
need to discuss again whether there is another way of making the
common clk and the sh-clk code coexist. For instance, we could rename
all if the sh/shmobile specific clk functions and their users from
clk_* to shclk_*, and provide a thin wrapper around them that integrates
into common clk.
> Starting with something smaller like EMEV2 may be a good first step.
> So somehow I'd like to start converting them one by one, perhaps also
> moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
> an incremental fashion. Do you happen to have any example subarch that
> has been migrated in an increment fashion already?
We have had a few that were able to do both multiplatform and
single-platform for some time, but then changed to multiplatform-only.
I think mvebu and vt8500 are in this category.
> Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
> should be enabled for the mach-shmobile bits that are used with
> CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
> recommendations would be very welcome!
Yes, makes sense.
What I think you should do is rename CONFIG_ARCH_SHMOBILE to
CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in
arch/arm/mach-shmobile/Kconfig like
config ARCH_SHMOBILE
bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7
default CONFIG_ARCH_SHMOBILE_SINGLE
help
Support for Renesas's SH-Mobile and R-Mobile ARM platforms.
This way, the platform is a non-exclusive option for the multiplatform
case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE.
Every machine that is not ready for multiplatform can then add "depends on
CONFIG_ARCH_SHMOBILE_SINGLE".
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-03-27 11:37 ` Arnd Bergmann
0 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-03-27 11:37 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 27 March 2013, Magnus Damm wrote:
> On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 22 March 2013, Simon Horman wrote:
> > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> > most of the work would be changing drivers/sh/clk to integrate into the common
> > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> > AUTO_ZRELADDR. Are those things you think can be done for 3.11?
>
> Good to hear that most ARM platforms will be converted by v3.10. This
> is definitely something that I want to make happen for mach-shmobile
> as well.
>
> Our biggest challenge now is the move to common clocks. I suspect that
> moving all our boards and SoCs to common clocks will take much longer
> than v3.11 I'm afraid.
Ok, I see. If you think it's not likely to be ready for 3.12, we might
need to discuss again whether there is another way of making the
common clk and the sh-clk code coexist. For instance, we could rename
all if the sh/shmobile specific clk functions and their users from
clk_* to shclk_*, and provide a thin wrapper around them that integrates
into common clk.
> Starting with something smaller like EMEV2 may be a good first step.
> So somehow I'd like to start converting them one by one, perhaps also
> moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
> an incremental fashion. Do you happen to have any example subarch that
> has been migrated in an increment fashion already?
We have had a few that were able to do both multiplatform and
single-platform for some time, but then changed to multiplatform-only.
I think mvebu and vt8500 are in this category.
> Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
> should be enabled for the mach-shmobile bits that are used with
> CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
> recommendations would be very welcome!
Yes, makes sense.
What I think you should do is rename CONFIG_ARCH_SHMOBILE to
CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in
arch/arm/mach-shmobile/Kconfig like
config ARCH_SHMOBILE
bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7
default CONFIG_ARCH_SHMOBILE_SINGLE
help
Support for Renesas's SH-Mobile and R-Mobile ARM platforms.
This way, the platform is a non-exclusive option for the multiplatform
case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE.
Every machine that is not ready for multiplatform can then add "depends on
CONFIG_ARCH_SHMOBILE_SINGLE".
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-03-27 11:37 ` Arnd Bergmann
@ 2013-04-01 9:15 ` Magnus Damm
-1 siblings, 0 replies; 114+ messages in thread
From: Magnus Damm @ 2013-04-01 9:15 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wednesday 27 March 2013, Magnus Damm wrote:
> > On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Friday 22 March 2013, Simon Horman wrote:
> > > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> > > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> > > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> > > most of the work would be changing drivers/sh/clk to integrate into the common
> > > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> > > AUTO_ZRELADDR. Are those things you think can be done for 3.11?
> >
> > Good to hear that most ARM platforms will be converted by v3.10. This
> > is definitely something that I want to make happen for mach-shmobile
> > as well.
> >
> > Our biggest challenge now is the move to common clocks. I suspect that
> > moving all our boards and SoCs to common clocks will take much longer
> > than v3.11 I'm afraid.
>
> Ok, I see. If you think it's not likely to be ready for 3.12, we might
> need to discuss again whether there is another way of making the
> common clk and the sh-clk code coexist. For instance, we could rename
> all if the sh/shmobile specific clk functions and their users from
> clk_* to shclk_*, and provide a thin wrapper around them that integrates
> into common clk.
Yeah, I am not sure if it is likely that we will be able to convert
all platforms at v3.12 timing.
I actually tried to let common clocks and sh-clk coexist when the
common clock framework was under heavy development. I recall it being
far from trivial.
One possible way to develop this could be to force the mach-shmobile
"reference DT" implementations use common clocks and keep the old
boards as-is. Then we can also make sure the "reference DT"
implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we
only have "reference DT" code as MULTIPLATFORM and then finally kill
off the old board code one by one.
> > Starting with something smaller like EMEV2 may be a good first step.
> > So somehow I'd like to start converting them one by one, perhaps also
> > moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
> > an incremental fashion. Do you happen to have any example subarch that
> > has been migrated in an increment fashion already?
>
> We have had a few that were able to do both multiplatform and
> single-platform for some time, but then changed to multiplatform-only.
> I think mvebu and vt8500 are in this category.
Thanks.
> > Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
> > should be enabled for the mach-shmobile bits that are used with
> > CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
> > recommendations would be very welcome!
>
> Yes, makes sense.
>
> What I think you should do is rename CONFIG_ARCH_SHMOBILE to
> CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in
> arch/arm/mach-shmobile/Kconfig like
>
> config ARCH_SHMOBILE
> bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7
> default CONFIG_ARCH_SHMOBILE_SINGLE
> help
> Support for Renesas's SH-Mobile and R-Mobile ARM platforms.
>
> This way, the platform is a non-exclusive option for the multiplatform
> case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE.
> Every machine that is not ready for multiplatform can then add "depends on
> CONFIG_ARCH_SHMOBILE_SINGLE".
I see, that makes sense. Thanks.
Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any
recommendatoin about LPAE?
Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE
will result in a kernel only working on LPAE hardware:
config ARM_LPAE
[snip]
Say Y if you have an ARMv7 processor supporting the LPAE page
table format and you would like to access memory beyond the
4GB limit. The resulting kernel image will not run on
processors without the LPA extension.
With the above text it sounds to me like we should not to a "select
ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM.
I sort of expect LPAE to behave similar to x86 PAE. At least the board
DT file should describe all physical memory available and depending on
kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts
of usable memory in the kernel. Then if LPAE should be selected or not
is something that the distributions have to decide.
Thanks!
/ magnus
^ permalink raw reply [flat|nested] 114+ messages in thread* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-04-01 9:15 ` Magnus Damm
0 siblings, 0 replies; 114+ messages in thread
From: Magnus Damm @ 2013-04-01 9:15 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wednesday 27 March 2013, Magnus Damm wrote:
> > On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Friday 22 March 2013, Simon Horman wrote:
> > > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> > > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> > > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> > > most of the work would be changing drivers/sh/clk to integrate into the common
> > > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> > > AUTO_ZRELADDR. Are those things you think can be done for 3.11?
> >
> > Good to hear that most ARM platforms will be converted by v3.10. This
> > is definitely something that I want to make happen for mach-shmobile
> > as well.
> >
> > Our biggest challenge now is the move to common clocks. I suspect that
> > moving all our boards and SoCs to common clocks will take much longer
> > than v3.11 I'm afraid.
>
> Ok, I see. If you think it's not likely to be ready for 3.12, we might
> need to discuss again whether there is another way of making the
> common clk and the sh-clk code coexist. For instance, we could rename
> all if the sh/shmobile specific clk functions and their users from
> clk_* to shclk_*, and provide a thin wrapper around them that integrates
> into common clk.
Yeah, I am not sure if it is likely that we will be able to convert
all platforms at v3.12 timing.
I actually tried to let common clocks and sh-clk coexist when the
common clock framework was under heavy development. I recall it being
far from trivial.
One possible way to develop this could be to force the mach-shmobile
"reference DT" implementations use common clocks and keep the old
boards as-is. Then we can also make sure the "reference DT"
implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we
only have "reference DT" code as MULTIPLATFORM and then finally kill
off the old board code one by one.
> > Starting with something smaller like EMEV2 may be a good first step.
> > So somehow I'd like to start converting them one by one, perhaps also
> > moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
> > an incremental fashion. Do you happen to have any example subarch that
> > has been migrated in an increment fashion already?
>
> We have had a few that were able to do both multiplatform and
> single-platform for some time, but then changed to multiplatform-only.
> I think mvebu and vt8500 are in this category.
Thanks.
> > Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
> > should be enabled for the mach-shmobile bits that are used with
> > CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
> > recommendations would be very welcome!
>
> Yes, makes sense.
>
> What I think you should do is rename CONFIG_ARCH_SHMOBILE to
> CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in
> arch/arm/mach-shmobile/Kconfig like
>
> config ARCH_SHMOBILE
> bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7
> default CONFIG_ARCH_SHMOBILE_SINGLE
> help
> Support for Renesas's SH-Mobile and R-Mobile ARM platforms.
>
> This way, the platform is a non-exclusive option for the multiplatform
> case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE.
> Every machine that is not ready for multiplatform can then add "depends on
> CONFIG_ARCH_SHMOBILE_SINGLE".
I see, that makes sense. Thanks.
Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any
recommendatoin about LPAE?
Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE
will result in a kernel only working on LPAE hardware:
config ARM_LPAE
[snip]
Say Y if you have an ARMv7 processor supporting the LPAE page
table format and you would like to access memory beyond the
4GB limit. The resulting kernel image will not run on
processors without the LPA extension.
With the above text it sounds to me like we should not to a "select
ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM.
I sort of expect LPAE to behave similar to x86 PAE. At least the board
DT file should describe all physical memory available and depending on
kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts
of usable memory in the kernel. Then if LPAE should be selected or not
is something that the distributions have to decide.
Thanks!
/ magnus
^ permalink raw reply [flat|nested] 114+ messages in thread* Re: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
2013-04-01 9:15 ` Magnus Damm
@ 2013-04-02 10:09 ` Arnd Bergmann
-1 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-04-02 10:09 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 01 April 2013, Magnus Damm wrote:
> On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Ok, I see. If you think it's not likely to be ready for 3.12, we might
> > need to discuss again whether there is another way of making the
> > common clk and the sh-clk code coexist. For instance, we could rename
> > all if the sh/shmobile specific clk functions and their users from
> > clk_* to shclk_*, and provide a thin wrapper around them that integrates
> > into common clk.
>
> Yeah, I am not sure if it is likely that we will be able to convert
> all platforms at v3.12 timing.
>
> I actually tried to let common clocks and sh-clk coexist when the
> common clock framework was under heavy development. I recall it being
> far from trivial.
>
> One possible way to develop this could be to force the mach-shmobile
> "reference DT" implementations use common clocks and keep the old
> boards as-is. Then we can also make sure the "reference DT"
> implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we
> only have "reference DT" code as MULTIPLATFORM and then finally kill
> off the old board code one by one.
Works for me, but wouldn't that mean that half the shmobile boards
become incompatible with the other half, forcing you to build two
separate kernels if you want to run on all the machines?
Maybe that's not a problem for you, since you tend to have per-soc
defconfigs anyway, and it will only be temporary.
> Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any
> recommendatoin about LPAE?
>
> Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE
> will result in a kernel only working on LPAE hardware:
>
> config ARM_LPAE
> [snip]
> Say Y if you have an ARMv7 processor supporting the LPAE page
> table format and you would like to access memory beyond the
> 4GB limit. The resulting kernel image will not run on
> processors without the LPA extension.
>
> With the above text it sounds to me like we should not to a "select
> ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM.
Correct.
> I sort of expect LPAE to behave similar to x86 PAE. At least the board
> DT file should describe all physical memory available and depending on
> kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts
> of usable memory in the kernel. Then if LPAE should be selected or not
> is something that the distributions have to decide.
Yes. I believe all distros are planning to build one non-LPAE nd one
LPAE kernel. There will have to be a way to enable all LPAE-capable
platforms in Kconfig, but I don't know if that exists already.
Presumably, the LPAE kernel will also be using THUMB2 in the kernel,
while the non-LPAE kernel may get built with ARMv6 platform support
enabled, which rules out THUMB2.
Also, we could enable KVM support in the non-LPAE kernel, but since
all KVM capable CPU cores (Cortex-A7 and Cortex-A15) so far also
come with LPAE, that's not even necessary.
You can always use #address-cells=<2> in the DT root node if that
helps, and you can also keep your peripherals using #address-cells=<1>
with an appropriate ranges property in the soc bus node.
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread
* [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
@ 2013-04-02 10:09 ` Arnd Bergmann
0 siblings, 0 replies; 114+ messages in thread
From: Arnd Bergmann @ 2013-04-02 10:09 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 01 April 2013, Magnus Damm wrote:
> On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Ok, I see. If you think it's not likely to be ready for 3.12, we might
> > need to discuss again whether there is another way of making the
> > common clk and the sh-clk code coexist. For instance, we could rename
> > all if the sh/shmobile specific clk functions and their users from
> > clk_* to shclk_*, and provide a thin wrapper around them that integrates
> > into common clk.
>
> Yeah, I am not sure if it is likely that we will be able to convert
> all platforms at v3.12 timing.
>
> I actually tried to let common clocks and sh-clk coexist when the
> common clock framework was under heavy development. I recall it being
> far from trivial.
>
> One possible way to develop this could be to force the mach-shmobile
> "reference DT" implementations use common clocks and keep the old
> boards as-is. Then we can also make sure the "reference DT"
> implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we
> only have "reference DT" code as MULTIPLATFORM and then finally kill
> off the old board code one by one.
Works for me, but wouldn't that mean that half the shmobile boards
become incompatible with the other half, forcing you to build two
separate kernels if you want to run on all the machines?
Maybe that's not a problem for you, since you tend to have per-soc
defconfigs anyway, and it will only be temporary.
> Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any
> recommendatoin about LPAE?
>
> Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE
> will result in a kernel only working on LPAE hardware:
>
> config ARM_LPAE
> [snip]
> Say Y if you have an ARMv7 processor supporting the LPAE page
> table format and you would like to access memory beyond the
> 4GB limit. The resulting kernel image will not run on
> processors without the LPA extension.
>
> With the above text it sounds to me like we should not to a "select
> ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM.
Correct.
> I sort of expect LPAE to behave similar to x86 PAE. At least the board
> DT file should describe all physical memory available and depending on
> kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts
> of usable memory in the kernel. Then if LPAE should be selected or not
> is something that the distributions have to decide.
Yes. I believe all distros are planning to build one non-LPAE nd one
LPAE kernel. There will have to be a way to enable all LPAE-capable
platforms in Kconfig, but I don't know if that exists already.
Presumably, the LPAE kernel will also be using THUMB2 in the kernel,
while the non-LPAE kernel may get built with ARMv6 platform support
enabled, which rules out THUMB2.
Also, we could enable KVM support in the non-LPAE kernel, but since
all KVM capable CPU cores (Cortex-A7 and Cortex-A15) so far also
come with LPAE, that's not even necessary.
You can always use #address-cells=<2> in the DT root node if that
helps, and you can also keep your peripherals using #address-cells=<1>
with an appropriate ranges property in the soc bus node.
Arnd
^ permalink raw reply [flat|nested] 114+ messages in thread