* Re: [PATCH] sh: fix the compile error in setup-sh7757.c
From: Paul Mundt @ 2011-08-29 7:24 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4E536FC2.7090306@renesas.com>
On Tue, Aug 23, 2011 at 06:15:46PM +0900, Yoshihiro Shimoda wrote:
> Fix the following build errors:
>
> CC arch/sh/kernel/cpu/sh4a/setup-sh7757.o
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:681: error: implicit declaration of function ?DMA_BIT_MASK?
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:681: error: initializer element is not constant
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:681: error: (near initialization for ?usb_ehci_device.dev.coherent_dma_mask?)
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:705: error: initializer element is not constant
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:705: error: (near initialization for ?usb_ohci_device.dev.coherent_dma_mask?)
> make[3]: *** [arch/sh/kernel/cpu/sh4a/setup-sh7757.o] Error 1
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sh: Fix implicit declaration of function numa_node_id
From: Paul Mundt @ 2011-08-29 6:46 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1314335141-15887-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
On Fri, Aug 26, 2011 at 02:05:41PM +0900, Nobuhiro Iwamatsu wrote:
> CC arch/sh/kernel/topology.o
> arch/sh/kernel/topology.c: In function ???topology_init???:
> arch/sh/kernel/topology.c:77: error: implicit declaration of function ???numa_node_id???
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Against what tree? I don't have anything this applies to.
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: Kota2 TPU LED support V2
From: Magnus Damm @ 2011-08-29 4:59 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110829035011.28202.37748.sendpatchset@rxone.opensource.se>
From: Magnus Damm <damm@opensource.se>
This patch updates the Kota2 board support code to
use the recently submitted TPU LED driver whenever
possible.
The sh73a0 SoC has 5 TPU hardware blocks each with
4 timer channels which in theory allows a total of
20 LEDs to be controlled by "leds-renesas-tpu"
driver instances. The Kota2 board has 4 LEDs connected
to GPIO pins that also come with TPU pin functions, so
this patch ties up these 4 LEDS and leaves the remaining
3 LEDS for the GPIO based LED driver.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
Depends on the "leds-renesas-tpu" driver and the board
support code for Kota2.
V2513, V2514, V2514 have been tested on Kota2 hardware
with values 1000, 100, 10, 1 and 0. KEYLED support is
half-tested which means the values above seem to work
OK but we do not know for sure since the actual LED is
not mounted on the prototype board.
Changes V1 -> V2:
- Use "platform_data" directory for the TPU driver.
- Include more people in the CC list
arch/arm/mach-shmobile/board-kota2.c | 122 +++++++++++++++++++++++++++++++--
arch/arm/mach-shmobile/clock-sh73a0.c | 17 ++++
2 files changed, 135 insertions(+), 4 deletions(-)
--- 0012/arch/arm/mach-shmobile/board-kota2.c
+++ work/arch/arm/mach-shmobile/board-kota2.c 2011-08-29 13:40:54.000000000 +0900
@@ -33,6 +33,7 @@
#include <linux/input/sh_keysc.h>
#include <linux/gpio_keys.h>
#include <linux/leds.h>
+#include <linux/platform_data/leds-renesas-tpu.h>
#include <linux/mmc/host.h>
#include <linux/mmc/sh_mmcif.h>
#include <linux/mfd/tmio.h>
@@ -153,10 +154,6 @@ static struct platform_device gpio_keys_
#define GPIO_LED(n, g) { .name = n, .gpio = g }
static struct gpio_led gpio_leds[] = {
- GPIO_LED("V2513", GPIO_PORT153), /* PORT153 [TPU1T02] -> V2513 */
- GPIO_LED("V2514", GPIO_PORT199), /* PORT199 [TPU4TO1] -> V2514 */
- GPIO_LED("V2515", GPIO_PORT197), /* PORT197 [TPU2TO1] -> V2515 */
- GPIO_LED("KEYLED", GPIO_PORT163), /* PORT163 [TPU3TO0] -> KEYLED */
GPIO_LED("G", GPIO_PORT20), /* PORT20 [GPO0] -> LED7 -> "G" */
GPIO_LED("H", GPIO_PORT21), /* PORT21 [GPO1] -> LED8 -> "H" */
GPIO_LED("J", GPIO_PORT22), /* PORT22 [GPO2] -> LED9 -> "J" */
@@ -175,6 +172,119 @@ static struct platform_device gpio_leds_
},
};
+/* TPU LED */
+static struct led_renesas_tpu_config led_renesas_tpu12_pdata = {
+ .name = "V2513",
+ .pin_gpio_fn = GPIO_FN_TPU1TO2,
+ .pin_gpio = GPIO_PORT153,
+ .channel_offset = 0x90,
+ .timer_bit = 2,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu12_resources[] = {
+ [0] = {
+ .name = "TPU12",
+ .start = 0xe6610090,
+ .end = 0xe66100b5,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu12_device = {
+ .name = "leds-renesas-tpu",
+ .id = 12,
+ .dev = {
+ .platform_data = &led_renesas_tpu12_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu12_resources),
+ .resource = tpu12_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu41_pdata = {
+ .name = "V2514",
+ .pin_gpio_fn = GPIO_FN_TPU4TO1,
+ .pin_gpio = GPIO_PORT199,
+ .channel_offset = 0x50,
+ .timer_bit = 1,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu41_resources[] = {
+ [0] = {
+ .name = "TPU41",
+ .start = 0xe6640050,
+ .end = 0xe6640075,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu41_device = {
+ .name = "leds-renesas-tpu",
+ .id = 41,
+ .dev = {
+ .platform_data = &led_renesas_tpu41_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu41_resources),
+ .resource = tpu41_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu21_pdata = {
+ .name = "V2515",
+ .pin_gpio_fn = GPIO_FN_TPU2TO1,
+ .pin_gpio = GPIO_PORT197,
+ .channel_offset = 0x50,
+ .timer_bit = 1,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu21_resources[] = {
+ [0] = {
+ .name = "TPU21",
+ .start = 0xe6620050,
+ .end = 0xe6620075,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu21_device = {
+ .name = "leds-renesas-tpu",
+ .id = 21,
+ .dev = {
+ .platform_data = &led_renesas_tpu21_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu21_resources),
+ .resource = tpu21_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu30_pdata = {
+ .name = "KEYLED",
+ .pin_gpio_fn = GPIO_FN_TPU3TO0,
+ .pin_gpio = GPIO_PORT163,
+ .channel_offset = 0x10,
+ .timer_bit = 0,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu30_resources[] = {
+ [0] = {
+ .name = "TPU30",
+ .start = 0xe6630010,
+ .end = 0xe6630035,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu30_device = {
+ .name = "leds-renesas-tpu",
+ .id = 30,
+ .dev = {
+ .platform_data = &led_renesas_tpu30_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu30_resources),
+ .resource = tpu30_resources,
+};
+
static struct resource mmcif_resources[] = {
[0] = {
.name = "MMCIF",
@@ -284,6 +394,10 @@ static struct platform_device *kota2_dev
&keysc_device,
&gpio_keys_device,
&gpio_leds_device,
+ &leds_tpu12_device,
+ &leds_tpu41_device,
+ &leds_tpu21_device,
+ &leds_tpu30_device,
&mmcif_device,
&sdhi0_device,
&sdhi1_device,
--- 0004/arch/arm/mach-shmobile/clock-sh73a0.c
+++ work/arch/arm/mach-shmobile/clock-sh73a0.c 2011-08-29 13:40:38.000000000 +0900
@@ -113,6 +113,12 @@ static struct clk main_clk = {
.ops = &main_clk_ops,
};
+/* Divide Main clock by two */
+static struct clk main_div2_clk = {
+ .ops = &div2_clk_ops,
+ .parent = &main_clk,
+};
+
/* PLL0, PLL1, PLL2, PLL3 */
static unsigned long pll_recalc(struct clk *clk)
{
@@ -181,6 +187,7 @@ static struct clk *main_clks[] = {
&extal1_div2_clk,
&extal2_div2_clk,
&main_clk,
+ &main_div2_clk,
&pll0_clk,
&pll1_clk,
&pll2_clk,
@@ -268,6 +275,7 @@ enum { MSTP001,
MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
MSTP331, MSTP329, MSTP325, MSTP323, MSTP318,
MSTP314, MSTP313, MSTP312, MSTP311,
+ MSTP304, MSTP303, MSTP302, MSTP301, MSTP300,
MSTP411, MSTP410, MSTP403,
MSTP_NR };
@@ -301,6 +309,11 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP313] = MSTP(&div6_clks[DIV6_SDHI1], SMSTPCR3, 13, 0), /* SDHI1 */
[MSTP312] = MSTP(&div4_clks[DIV4_HP], SMSTPCR3, 12, 0), /* MMCIF0 */
[MSTP311] = MSTP(&div6_clks[DIV6_SDHI2], SMSTPCR3, 11, 0), /* SDHI2 */
+ [MSTP304] = MSTP(&main_div2_clk, SMSTPCR3, 4, 0), /* TPU0 */
+ [MSTP303] = MSTP(&main_div2_clk, SMSTPCR3, 3, 0), /* TPU1 */
+ [MSTP302] = MSTP(&main_div2_clk, SMSTPCR3, 2, 0), /* TPU2 */
+ [MSTP301] = MSTP(&main_div2_clk, SMSTPCR3, 1, 0), /* TPU3 */
+ [MSTP300] = MSTP(&main_div2_clk, SMSTPCR3, 0, 0), /* TPU4 */
[MSTP411] = MSTP(&div4_clks[DIV4_HP], SMSTPCR4, 11, 0), /* IIC3 */
[MSTP410] = MSTP(&div4_clks[DIV4_HP], SMSTPCR4, 10, 0), /* IIC4 */
[MSTP403] = MSTP(&r_clk, SMSTPCR4, 3, 0), /* KEYSC */
@@ -350,6 +363,10 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP313]), /* SDHI1 */
CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP312]), /* MMCIF0 */
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP311]), /* SDHI2 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.12", &mstp_clks[MSTP303]), /* TPU1 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.21", &mstp_clks[MSTP302]), /* TPU2 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.30", &mstp_clks[MSTP301]), /* TPU3 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.41", &mstp_clks[MSTP300]), /* TPU4 */
CLKDEV_DEV_ID("i2c-sh_mobile.3", &mstp_clks[MSTP411]), /* I2C3 */
CLKDEV_DEV_ID("i2c-sh_mobile.4", &mstp_clks[MSTP410]), /* I2C4 */
CLKDEV_DEV_ID("sh_keysc.0", &mstp_clks[MSTP403]), /* KEYSC */
^ permalink raw reply
* [PATCH] leds: Update Renesas TPU LED driver to use workqueue
From: Magnus Damm @ 2011-08-29 4:53 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-sh, grant.likely, lethal, rpurdie, Magnus Damm, akpm
From: Magnus Damm <damm@opensource.se>
Use a workqueue in the Renesas TPU LED driver
to allow the Runtime PM code to sleep.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
drivers/leds/leds-renesas-tpu.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
--- 0017/drivers/leds/leds-renesas-tpu.c
+++ work/drivers/leds/leds-renesas-tpu.c 2011-08-29 13:40:12.000000000 +0900
@@ -31,6 +31,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <linux/workqueue.h>
enum r_tpu_pin { R_TPU_PIN_UNUSED, R_TPU_PIN_GPIO, R_TPU_PIN_GPIO_FN };
enum r_tpu_timer { R_TPU_TIMER_UNUSED, R_TPU_TIMER_ON };
@@ -44,6 +45,8 @@ struct r_tpu_priv {
enum r_tpu_timer timer_state;
unsigned long min_rate;
unsigned int refresh_rate;
+ struct work_struct work;
+ enum led_brightness new_brightness;
};
static DEFINE_SPINLOCK(r_tpu_lock);
@@ -211,15 +214,15 @@ static void r_tpu_set_pin(struct r_tpu_p
p->pin_state = new_state;
}
-static void r_tpu_set_brightness(struct led_classdev *ldev,
- enum led_brightness brightness)
+static void r_tpu_work(struct work_struct *work)
{
- struct r_tpu_priv *p = container_of(ldev, struct r_tpu_priv, ldev);
+ struct r_tpu_priv *p = container_of(work, struct r_tpu_priv, work);
+ enum led_brightness brightness = p->new_brightness;
r_tpu_disable(p);
/* off and maximum are handled as GPIO pins, in between PWM */
- if ((brightness = 0) || (brightness = ldev->max_brightness))
+ if ((brightness = 0) || (brightness = p->ldev.max_brightness))
r_tpu_set_pin(p, R_TPU_PIN_GPIO, brightness);
else {
r_tpu_set_pin(p, R_TPU_PIN_GPIO_FN, 0);
@@ -227,6 +230,14 @@ static void r_tpu_set_brightness(struct
}
}
+static void r_tpu_set_brightness(struct led_classdev *ldev,
+ enum led_brightness brightness)
+{
+ struct r_tpu_priv *p = container_of(ldev, struct r_tpu_priv, ldev);
+ p->new_brightness = brightness;
+ schedule_work(&p->work);
+}
+
static int __devinit r_tpu_probe(struct platform_device *pdev)
{
struct led_renesas_tpu_config *cfg = pdev->dev.platform_data;
@@ -274,6 +285,7 @@ static int __devinit r_tpu_probe(struct
r_tpu_set_pin(p, R_TPU_PIN_GPIO, LED_OFF);
platform_set_drvdata(pdev, p);
+ INIT_WORK(&p->work, r_tpu_work);
p->ldev.name = cfg->name;
p->ldev.brightness = LED_OFF;
@@ -307,6 +319,7 @@ static int __devexit r_tpu_remove(struct
r_tpu_set_brightness(&p->ldev, LED_OFF);
led_classdev_unregister(&p->ldev);
+ cancel_work_sync(&p->work);
r_tpu_disable(p);
r_tpu_set_pin(p, R_TPU_PIN_UNUSED, LED_OFF);
^ permalink raw reply
* [PATCH] leds: Move Renesas TPU LED driver platform data
From: Magnus Damm @ 2011-08-29 4:50 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-sh, grant.likely, lethal, rpurdie, Magnus Damm, akpm
From: Magnus Damm <damm@opensource.se>
Use the platform_data include directory for the
TPU LED driver, as suggested by Paul Mundt.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
drivers/leds/leds-renesas-tpu.c | 2 +-
include/linux/leds-renesas-tpu.h | 14 --------------
include/linux/platform_data/leds-renesas-tpu.h | 14 ++++++++++++++
3 files changed, 15 insertions(+), 15 deletions(-)
--- 0016/drivers/leds/leds-renesas-tpu.c
+++ work/drivers/leds/leds-renesas-tpu.c 2011-08-29 13:39:21.000000000 +0900
@@ -26,7 +26,7 @@
#include <linux/io.h>
#include <linux/clk.h>
#include <linux/leds.h>
-#include <linux/leds-renesas-tpu.h>
+#include <linux/platform_data/leds-renesas-tpu.h>
#include <linux/gpio.h>
#include <linux/err.h>
#include <linux/slab.h>
--- 0015/include/linux/leds-renesas-tpu.h
+++ /dev/null 2011-08-29 11:06:11.184294567 +0900
@@ -1,14 +0,0 @@
-#ifndef __LEDS_RENESAS_TPU_H__
-#define __LEDS_RENESAS_TPU_H__
-
-struct led_renesas_tpu_config {
- char *name;
- unsigned pin_gpio_fn;
- unsigned pin_gpio;
- unsigned int channel_offset;
- unsigned int timer_bit;
- unsigned int max_brightness;
- unsigned int refresh_rate;
-};
-
-#endif /* __LEDS_RENESAS_TPU_H__ */
--- /dev/null
+++ work/include/linux/platform_data/leds-renesas-tpu.h 2011-08-29 13:13:35.000000000 +0900
@@ -0,0 +1,14 @@
+#ifndef __LEDS_RENESAS_TPU_H__
+#define __LEDS_RENESAS_TPU_H__
+
+struct led_renesas_tpu_config {
+ char *name;
+ unsigned pin_gpio_fn;
+ unsigned pin_gpio;
+ unsigned int channel_offset;
+ unsigned int timer_bit;
+ unsigned int max_brightness;
+ unsigned int refresh_rate;
+};
+
+#endif /* __LEDS_RENESAS_TPU_H__ */
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: clock-sh73a0: tidyup CKSCR main clock selecter
From: Kuninori Morimoto @ 2011-08-29 4:13 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <w3pmxozyxra.wl%kuninori.morimoto.gx@renesas.com>
Hi Magnus
Thank you for checking my patch
> > MAINCKSEL is [29:28], not [27:24]
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This matches the data sheet, thanks for submitting this Morimoto-san.
>
> In the future, please include the word "bug fix" in the subject so we
> can tell it's a bug fix.
Thank you for pointing it.
I will do
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: Kota2 TPU LED support
From: Magnus Damm @ 2011-08-29 3:50 UTC (permalink / raw)
To: linux-sh
From: Magnus Damm <damm@opensource.se>
This patch updates the Kota2 board support code to
use the recently submitted TPU LED driver whenever
possible.
The sh73a0 SoC has 5 TPU hardware blocks each with
4 timer channels which in theory allows a total of
20 LEDs to be controlled by "leds-renesas-tpu"
driver instances. The Kota2 board has 4 LEDs connected
to GPIO pins that also come with TPU pin functions, so
this patch ties up these 4 LEDS and leaves the remaining
3 LEDS for the GPIO based LED driver.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
Depends on the "leds-renesas-tpu" driver and the board
support code for Kota2.
V2513, V2514, V2514 have been tested on Kota2 hardware
with values 1000, 100, 10, 1 and 0. KEYLED support is
half-tested which means the values above seem to work
OK but we do not know for sure since the actual LED is
not mounted on the prototype board.
arch/arm/mach-shmobile/board-kota2.c | 122 +++++++++++++++++++++++++++++++--
arch/arm/mach-shmobile/clock-sh73a0.c | 17 ++++
2 files changed, 135 insertions(+), 4 deletions(-)
--- 0012/arch/arm/mach-shmobile/board-kota2.c
+++ work/arch/arm/mach-shmobile/board-kota2.c 2011-08-29 12:30:02.000000000 +0900
@@ -33,6 +33,7 @@
#include <linux/input/sh_keysc.h>
#include <linux/gpio_keys.h>
#include <linux/leds.h>
+#include <linux/leds-renesas-tpu.h>
#include <linux/mmc/host.h>
#include <linux/mmc/sh_mmcif.h>
#include <linux/mfd/tmio.h>
@@ -153,10 +154,6 @@ static struct platform_device gpio_keys_
#define GPIO_LED(n, g) { .name = n, .gpio = g }
static struct gpio_led gpio_leds[] = {
- GPIO_LED("V2513", GPIO_PORT153), /* PORT153 [TPU1T02] -> V2513 */
- GPIO_LED("V2514", GPIO_PORT199), /* PORT199 [TPU4TO1] -> V2514 */
- GPIO_LED("V2515", GPIO_PORT197), /* PORT197 [TPU2TO1] -> V2515 */
- GPIO_LED("KEYLED", GPIO_PORT163), /* PORT163 [TPU3TO0] -> KEYLED */
GPIO_LED("G", GPIO_PORT20), /* PORT20 [GPO0] -> LED7 -> "G" */
GPIO_LED("H", GPIO_PORT21), /* PORT21 [GPO1] -> LED8 -> "H" */
GPIO_LED("J", GPIO_PORT22), /* PORT22 [GPO2] -> LED9 -> "J" */
@@ -175,6 +172,119 @@ static struct platform_device gpio_leds_
},
};
+/* TPU LED */
+static struct led_renesas_tpu_config led_renesas_tpu12_pdata = {
+ .name = "V2513",
+ .pin_gpio_fn = GPIO_FN_TPU1TO2,
+ .pin_gpio = GPIO_PORT153,
+ .channel_offset = 0x90,
+ .timer_bit = 2,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu12_resources[] = {
+ [0] = {
+ .name = "TPU12",
+ .start = 0xe6610090,
+ .end = 0xe66100b5,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu12_device = {
+ .name = "leds-renesas-tpu",
+ .id = 12,
+ .dev = {
+ .platform_data = &led_renesas_tpu12_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu12_resources),
+ .resource = tpu12_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu41_pdata = {
+ .name = "V2514",
+ .pin_gpio_fn = GPIO_FN_TPU4TO1,
+ .pin_gpio = GPIO_PORT199,
+ .channel_offset = 0x50,
+ .timer_bit = 1,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu41_resources[] = {
+ [0] = {
+ .name = "TPU41",
+ .start = 0xe6640050,
+ .end = 0xe6640075,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu41_device = {
+ .name = "leds-renesas-tpu",
+ .id = 41,
+ .dev = {
+ .platform_data = &led_renesas_tpu41_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu41_resources),
+ .resource = tpu41_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu21_pdata = {
+ .name = "V2515",
+ .pin_gpio_fn = GPIO_FN_TPU2TO1,
+ .pin_gpio = GPIO_PORT197,
+ .channel_offset = 0x50,
+ .timer_bit = 1,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu21_resources[] = {
+ [0] = {
+ .name = "TPU21",
+ .start = 0xe6620050,
+ .end = 0xe6620075,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu21_device = {
+ .name = "leds-renesas-tpu",
+ .id = 21,
+ .dev = {
+ .platform_data = &led_renesas_tpu21_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu21_resources),
+ .resource = tpu21_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu30_pdata = {
+ .name = "KEYLED",
+ .pin_gpio_fn = GPIO_FN_TPU3TO0,
+ .pin_gpio = GPIO_PORT163,
+ .channel_offset = 0x10,
+ .timer_bit = 0,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu30_resources[] = {
+ [0] = {
+ .name = "TPU30",
+ .start = 0xe6630010,
+ .end = 0xe6630035,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu30_device = {
+ .name = "leds-renesas-tpu",
+ .id = 30,
+ .dev = {
+ .platform_data = &led_renesas_tpu30_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu30_resources),
+ .resource = tpu30_resources,
+};
+
static struct resource mmcif_resources[] = {
[0] = {
.name = "MMCIF",
@@ -284,6 +394,10 @@ static struct platform_device *kota2_dev
&keysc_device,
&gpio_keys_device,
&gpio_leds_device,
+ &leds_tpu12_device,
+ &leds_tpu41_device,
+ &leds_tpu21_device,
+ &leds_tpu30_device,
&mmcif_device,
&sdhi0_device,
&sdhi1_device,
--- 0004/arch/arm/mach-shmobile/clock-sh73a0.c
+++ work/arch/arm/mach-shmobile/clock-sh73a0.c 2011-08-29 12:30:32.000000000 +0900
@@ -113,6 +113,12 @@ static struct clk main_clk = {
.ops = &main_clk_ops,
};
+/* Divide Main clock by two */
+static struct clk main_div2_clk = {
+ .ops = &div2_clk_ops,
+ .parent = &main_clk,
+};
+
/* PLL0, PLL1, PLL2, PLL3 */
static unsigned long pll_recalc(struct clk *clk)
{
@@ -181,6 +187,7 @@ static struct clk *main_clks[] = {
&extal1_div2_clk,
&extal2_div2_clk,
&main_clk,
+ &main_div2_clk,
&pll0_clk,
&pll1_clk,
&pll2_clk,
@@ -268,6 +275,7 @@ enum { MSTP001,
MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
MSTP331, MSTP329, MSTP325, MSTP323, MSTP318,
MSTP314, MSTP313, MSTP312, MSTP311,
+ MSTP304, MSTP303, MSTP302, MSTP301, MSTP300,
MSTP411, MSTP410, MSTP403,
MSTP_NR };
@@ -301,6 +309,11 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP313] = MSTP(&div6_clks[DIV6_SDHI1], SMSTPCR3, 13, 0), /* SDHI1 */
[MSTP312] = MSTP(&div4_clks[DIV4_HP], SMSTPCR3, 12, 0), /* MMCIF0 */
[MSTP311] = MSTP(&div6_clks[DIV6_SDHI2], SMSTPCR3, 11, 0), /* SDHI2 */
+ [MSTP304] = MSTP(&main_div2_clk, SMSTPCR3, 4, 0), /* TPU0 */
+ [MSTP303] = MSTP(&main_div2_clk, SMSTPCR3, 3, 0), /* TPU1 */
+ [MSTP302] = MSTP(&main_div2_clk, SMSTPCR3, 2, 0), /* TPU2 */
+ [MSTP301] = MSTP(&main_div2_clk, SMSTPCR3, 1, 0), /* TPU3 */
+ [MSTP300] = MSTP(&main_div2_clk, SMSTPCR3, 0, 0), /* TPU4 */
[MSTP411] = MSTP(&div4_clks[DIV4_HP], SMSTPCR4, 11, 0), /* IIC3 */
[MSTP410] = MSTP(&div4_clks[DIV4_HP], SMSTPCR4, 10, 0), /* IIC4 */
[MSTP403] = MSTP(&r_clk, SMSTPCR4, 3, 0), /* KEYSC */
@@ -350,6 +363,10 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP313]), /* SDHI1 */
CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP312]), /* MMCIF0 */
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP311]), /* SDHI2 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.12", &mstp_clks[MSTP303]), /* TPU1 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.21", &mstp_clks[MSTP302]), /* TPU2 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.30", &mstp_clks[MSTP301]), /* TPU3 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.41", &mstp_clks[MSTP300]), /* TPU4 */
CLKDEV_DEV_ID("i2c-sh_mobile.3", &mstp_clks[MSTP411]), /* I2C3 */
CLKDEV_DEV_ID("i2c-sh_mobile.4", &mstp_clks[MSTP410]), /* I2C4 */
CLKDEV_DEV_ID("sh_keysc.0", &mstp_clks[MSTP403]), /* KEYSC */
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: clock-sh73a0: tidyup CKSCR main clock selecter
From: Magnus Damm @ 2011-08-29 3:36 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <w3pmxozyxra.wl%kuninori.morimoto.gx@renesas.com>
On Fri, Aug 26, 2011 at 4:27 PM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
> MAINCKSEL is [29:28], not [27:24]
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This matches the data sheet, thanks for submitting this Morimoto-san.
In the future, please include the word "bug fix" in the subject so we
can tell it's a bug fix.
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH 0/4 v8] mmc: tmio, sdhi: provide multiple irq handlers
From: Chris Ball @ 2011-08-28 17:58 UTC (permalink / raw)
To: Simon Horman
Cc: linux-mmc, linux-sh, Paul Mundt, Guennadi Liakhovetski,
Magnus Damm
In-Reply-To: <1314235648-8959-1-git-send-email-horms@verge.net.au>
Hi Simon,
On Wed, Aug 24 2011, Simon Horman wrote:
> The SDHI driver already supports making use of up to three interrupt
> sources.
>
> This series breaks up the existing interrupt handler into three handlers,
> one for sdcard access, one for card detect and one for SDIO interrupts.
> A cover-all handler, which makes use of these new broken-out handlers
> is provided for for the case where there is a multiplexed interrupt source.
>
> This series also wires up the new IRQ handlers for the mackerel and ag4evm.
>
> This series contains the following patches:
>
> [PATCH v8 1/4] mmc: tmio: Cache interrupt masks
> [PATCH v8 2/4] mmc: tmio: Provide separate interrupt handlers
> [PATCH v8 3/4] mmc: sdhi: Allow name IRQs to use specific handlers
> [PATCH v8 4/4] ARM: shmobile: ag5evm, ap4: Named SDHI IRQ sources
Thanks, all applied to mmc-next for 3.2, using Guennadi's v9 for 3/4.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* 最新广交会买家库+500万海外买家资源+
From: 每天都有新买家 @ 2011-08-28 16:27 UTC (permalink / raw)
To: linux-sh
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 13419 bytes --]
500���������������������������������������������������������������+������������������������������������������������������+������������������������������������Email���������������������������=���������������������������������������������������������������������������������
500���������������������������������������������������������������+������������������������������������������������������+������������������������������������Email���������������������������=���������������������������������������������������������������������������������
1���������500������������������������������������������������������ ���������������������������500��������������������������������������������������������������������������������� (������������������������������������������������������������������������������������������������������������������������������������������������������������������)���������
2���������������������������������������������������������������Email������������������������������������ ���������������������������600������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������1-2���������������������������������������������������������������EMAIL������������������������������������������������������
3������������������������������������������������������ ���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������5���������������������������������������������
��������������������������������������������������������������������������������� (���������������������������������������������������������������������������������������������������������������������������������������������������������) ������������������������������������������������������ ���������������������������
������������������������������������
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
������������������������������������:
1������������������������������������������������������������������������������������������,��������������������������������������������������������������� 500-1000���������������������������Email������������������������������������������������������������������������������������������������������������
2���������2009���������������������������������������������������������������piers��������������������������� 1���������������������������
3���������2011������������������109���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
4���������2008������������������2010��������� ������������������+������������������������������������������������������������������������������������������103 104 105 106 107 108 ���������������������������������������������120.6������������������������������������
5������������������������������������������������������������������������,���������451660������������������������������������������������������������������������Email���������
6���������2010������������������������������������������������������������������������PPAI��������������������������������������������� PPAI Members Directory������������������������������������������������������������������������������������������
7���������2010���������������������������������������������������������������������������������������������������������������������(���������������������������������������������������������������)������������������7.2������������������������������������������������������������������������������������������������������������
8���������100���������������������������������������������������������������������������������������������������������������������Email���������
9���������������������������������������������������������������������������������������������������
���������������������������������������������
������������{.n���+���������������������+%���������������������\x17������w������{.n���+������������{���������������{ay���\x1d���������������,j\a������f���������h���������������������������z_������\x03(���������������������j"������\x1a���^[m������������\a������G������������������?���������������&���������~������
^ permalink raw reply
* [GIT PULL] Power management fixes for 3.1
From: Rafael J. Wysocki @ 2011-08-28 12:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux PM mailing list, linux-sh, Magnus Damm, Kevin Hilman,
linux-omap
Hi Linus,
Please pull power management fixes for 3.1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-fixes
They include:
* Fixes related to the sh-sci driver which uses runtime PM helpers in
such a way that they may be run with interrupts off, but it doesn't
tell the core about that (so the core happily enables interrupts when
they should be off), and which also causes pm_clk_suspend() and
pm_clk_resume() to be run with interrupts off (so they shouldn't use
a mutex).
* shi7372 LCDC suspend fix from Magnus Damm.
* OMAP suspend callbacks fix from Kevin Hilman.
* Runtime PM documentation correction.
Thanks!
Documentation/power/runtime_pm.txt | 3 +-
arch/arm/mach-shmobile/board-ap4evb.c | 1 +
arch/arm/mach-shmobile/board-mackerel.c | 1 +
arch/arm/mach-shmobile/clock-sh7372.c | 2 +
arch/arm/plat-omap/omap_device.c | 3 +-
drivers/base/power/clock_ops.c | 40 +++++++++++++++++--------------
drivers/tty/serial/sh-sci.c | 1 +
7 files changed, 30 insertions(+), 21 deletions(-)
---------------
Kevin Hilman (1):
OMAP: omap_device: only override _noirq methods, not normal suspend/resume
Magnus Damm (2):
ARM: mach-shmobile: sh7372 LCDC1 suspend fix
ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental)
Rafael J. Wysocki (3):
PM: Use spinlock instead of mutex in clock management functions
sh-sci / PM: Use power.irq_safe
PM / Runtime: Correct documentation of pm_runtime_irq_safe()
^ permalink raw reply
* Re: [PATCH 0/2] mmc: tmio: two bug-fixes
From: Ian Molton @ 2011-08-27 21:40 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Chris Ball, linux-mmc, linux-sh, Magnus Damm, Rafael J. Wysocki,
Simon Horman
In-Reply-To: <Pine.LNX.4.64.1107150957570.22613@axis700.grange>
On Fri, 2011-07-15 at 10:46 +0200, Guennadi Liakhovetski wrote:
> Thanks for the offer, I appreciate it! I am not the only active tmio
> mmc contributor, but yes, I could take that role upon me, if noone
> objects.
> Would be good to hear, what Ian thinks? Is he maybe still planning to
> actively working on the driver? Would he like to stay listed as a
> co-maintainer? If I am to maintain the driver alone, it would be good
> to have access to some non-sh-mobile hardware, using it too, at least
> for regression testing. Any idea where to get anything like that?
Seem to remember dealing with this already - but I'm fine with it. I'd
like to keep on testing the TMIO chipsets in e-series (need to build
that again sometime soon).
-Ian
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental)
From: Rafael J. Wysocki @ 2011-08-27 12:27 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110824093936.8230.53081.sendpatchset@rxone.opensource.se>
On Saturday, August 27, 2011, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> This patch updates the recently submitted
> "Associate the HDMI clock together with LCDC1 on sh7372"
> to V2 with the following change:
> - Use lcdc1_device on AP4EVB to build properly.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
Applied to linux-pm/pm-fixes, thanks!
Rafael
> ---
>
> arch/arm/mach-shmobile/board-ap4evb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 0007/arch/arm/mach-shmobile/board-ap4evb.c
> +++ work/arch/arm/mach-shmobile/board-ap4evb.c 2011-08-27 20:58:15.000000000 +0900
> @@ -1412,7 +1412,7 @@ static void __init ap4evb_init(void)
> fsi_init_pm_clock();
> sh7372_pm_init();
> pm_clk_add(&fsi_device.dev, "spu2");
> - pm_clk_add(&hdmi_lcdc_device.dev, "hdmi");
> + pm_clk_add(&lcdc1_device.dev, "hdmi");
> }
>
> static void __init ap4evb_timer_init(void)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental)
From: Magnus Damm @ 2011-08-27 12:04 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110824093936.8230.53081.sendpatchset@rxone.opensource.se>
From: Magnus Damm <damm@opensource.se>
This patch updates the recently submitted
"Associate the HDMI clock together with LCDC1 on sh7372"
to V2 with the following change:
- Use lcdc1_device on AP4EVB to build properly.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/board-ap4evb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 0007/arch/arm/mach-shmobile/board-ap4evb.c
+++ work/arch/arm/mach-shmobile/board-ap4evb.c 2011-08-27 20:58:15.000000000 +0900
@@ -1412,7 +1412,7 @@ static void __init ap4evb_init(void)
fsi_init_pm_clock();
sh7372_pm_init();
pm_clk_add(&fsi_device.dev, "spu2");
- pm_clk_add(&hdmi_lcdc_device.dev, "hdmi");
+ pm_clk_add(&lcdc1_device.dev, "hdmi");
}
static void __init ap4evb_timer_init(void)
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2
From: Rafael J. Wysocki @ 2011-08-26 20:47 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110824093936.8230.53081.sendpatchset@rxone.opensource.se>
Hi,
On Friday, August 26, 2011, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> Associate the HDMI clock together with LCDC1 on sh7372 V2.
>
> Without this patch Suspend-to-RAM hangs on the boards
> AP4EVB and Mackerel. The code hangs in the LCDC driver
> where the software is waiting forever for the hardware to
> power down. By explicitly associating the HDMI clock with
> LCDC1 we can make sure the HDMI clock is enabled using
> Runtime PM whenever the driver is accessing the hardware.
>
> This HDMI and LCDC1 dependency is documented in the sh7372
> data sheet. Older kernels did work as expected but the
> recently merged (3.1-rc)
>
> 794d78f drivers: sh: late disabling of clocks V2
>
> introduced code to turn off clocks lacking software reference
> which happens to include the HDMI clock that is needed by
> LCDC1 to operate as expected.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
Since the v1 alread sits in my pm-fixes branch which I _really_
wouldn't like to rebase (and in fact I was planning to push it
to Linus today) can you please create an incremental v1->v2
patch on top of it?
Rafael
> ---
>
> Changes V1 -> V2:
> - Use lcdc1_device on AP4EVB to build properly.
>
> arch/arm/mach-shmobile/board-ap4evb.c | 1 +
> arch/arm/mach-shmobile/board-mackerel.c | 1 +
> arch/arm/mach-shmobile/clock-sh7372.c | 2 ++
> 3 files changed, 4 insertions(+)
>
> --- 0001/arch/arm/mach-shmobile/board-ap4evb.c
> +++ work/arch/arm/mach-shmobile/board-ap4evb.c 2011-08-26 13:41:24.000000000 +0900
> @@ -1412,6 +1412,7 @@ static void __init ap4evb_init(void)
> fsi_init_pm_clock();
> sh7372_pm_init();
> pm_clk_add(&fsi_device.dev, "spu2");
> + pm_clk_add(&lcdc1_device.dev, "hdmi");
> }
>
> static void __init ap4evb_timer_init(void)
> --- 0004/arch/arm/mach-shmobile/board-mackerel.c
> +++ work/arch/arm/mach-shmobile/board-mackerel.c 2011-08-26 13:33:36.000000000 +0900
> @@ -1592,6 +1592,7 @@ static void __init mackerel_init(void)
> hdmi_init_pm_clock();
> sh7372_pm_init();
> pm_clk_add(&fsi_device.dev, "spu2");
> + pm_clk_add(&hdmi_lcdc_device.dev, "hdmi");
> }
>
> static void __init mackerel_timer_init(void)
> --- 0005/arch/arm/mach-shmobile/clock-sh7372.c
> +++ work/arch/arm/mach-shmobile/clock-sh7372.c 2011-08-26 13:33:36.000000000 +0900
> @@ -659,6 +659,8 @@ static struct clk_lookup lookups[] = {
> CLKDEV_DEV_ID("renesas_usbhs.1", &mstp_clks[MSTP406]), /* USB1 */
> CLKDEV_DEV_ID("sh_keysc.0", &mstp_clks[MSTP403]), /* KEYSC */
>
> + CLKDEV_ICK_ID("hdmi", "sh_mobile_lcdc_fb.1",
> + &div6_reparent_clks[DIV6_HDMI]),
> CLKDEV_ICK_ID("ick", "sh-mobile-hdmi", &div6_reparent_clks[DIV6_HDMI]),
> CLKDEV_ICK_ID("icka", "sh_fsi2", &div6_reparent_clks[DIV6_FSIA]),
> CLKDEV_ICK_ID("ickb", "sh_fsi2", &div6_reparent_clks[DIV6_FSIB]),
>
>
^ permalink raw reply
* Re: [PATCH][RESEND] ARM: mach-shmobile: sh7372 generic suspend/resume support
From: Rafael J. Wysocki @ 2011-08-26 20:43 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110826051205.24370.44903.sendpatchset@rxone.opensource.se>
On Friday, August 26, 2011, Magnus Damm wrote:
> On Fri, Aug 26, 2011 at 6:23 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Aug 26, 2011 at 05:44:04PM +0900, Magnus Damm wrote:
> >> Good question. This was posted before the 3.1-rc merge window, but
> >> didn't make it into mainline for some unknown
> >> reason. I'm all for merging things sooner than later if possible, but
> >> I understand if 3.1-rc is out of the question at this point.
> >>
> >> If you are offering to queue this up for the 3.2 merge window then I
> >> am instead suggesting that Rafael picks this up in his PM tree because
> >> there are other PM related patches that build on top of this one.
> >
> > If Rafael wants to pick it up, that's fine.
>
> Let's see what he says about that.
I will take the patch for 3.2.
Russell, may I add your Acked-by to it?
Magnus, which branch do you want it to go to?
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] net: sh_eth: fix the compile error
From: David Miller @ 2011-08-26 16:50 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4E537249.8050806@renesas.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1086 bytes --]
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Tue, 23 Aug 2011 18:26:33 +0900
> Fix the following build error:
>
> CC drivers/net/sh_eth.o
> drivers/net/sh_eth.c:1115: error: expected ¡=¢, ¡,¢, ¡;¢, ¡asm¢ or ¡__attribute__¢ before ¡sh_eth_interrupt¢
> drivers/net/sh_eth.c: In function ¡sh_eth_open¢:
> drivers/net/sh_eth.c:1387: error: implicit declaration of function ¡request_irq¢
> drivers/net/sh_eth.c:1387: error: ¡sh_eth_interrupt¢ undeclared (first use in this function)
> drivers/net/sh_eth.c:1387: error: (Each undeclared identifier is reported only once
> drivers/net/sh_eth.c:1387: error: for each function it appears in.)
> drivers/net/sh_eth.c:1391: error: ¡IRQF_SHARED¢ undeclared (first use in this function)
> drivers/net/sh_eth.c:1424: error: implicit declaration of function ¡free_irq¢
> make[2]: *** [drivers/net/sh_eth.o] Error 1
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þÈÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á
^ permalink raw reply
* Re: [PATCH] [RFC] ARM: shmobile: g4evm: Use multiple irq vectors for
From: Simon Horman @ 2011-08-26 13:06 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linux-mmc, linux-sh, Paul Mundt, Magnus Damm
In-Reply-To: <Pine.LNX.4.64.1108261448400.25272@axis700.grange>
On Fri, Aug 26, 2011 at 02:56:50PM +0200, Guennadi Liakhovetski wrote:
> On Fri, 26 Aug 2011, Simon Horman wrote:
>
> > On Fri, Aug 26, 2011 at 02:17:20PM +0200, Guennadi Liakhovetski wrote:
> > > On Fri, 26 Aug 2011, Simon Horman wrote:
> > >
> > > > This patch is based on "ARM: arch-shmobile: Use multiple irq vectors for SDHI"
> > > >
> > > > It removes multiplexing of the SDHI vectors and names each IRQ source
> > > > to allow the SDHI driver to used source-specific handlers.
> > > >
> > > > This is untested as I do not have access to a working g4evm.
> > > >
> > > > Signed-off-by: Simon Horman <horms@verge.net.au>
> > > >
> > > > ---
> > > >
> > > > Requires "mmc: sdhi: Allow specific IRQ sources to use corresponding handlers."
> > > >
> > > > *** compile tested only ***
> > > > ---
> > > > arch/arm/mach-shmobile/board-g4evm.c | 26 ++++++++++++++++++++++-
> > > > arch/arm/mach-shmobile/intc-sh7377.c | 36 ++++++++++++++++-----------------
> > >
> > > This second file should not be here, right?
> >
> > I believe that the g4evm uses the sh7377 and that the multiplexing of
> > SDHIinterrupts for the 7377 need to be removed in order to provide multiple
> > SDHI irq sources.
> >
> > Am I missing something?
>
> Maybe not, I just misread your patch description as that it only should
> touch the board itself. Since intc-sh7377.c has to be touched too, this
> should be tested, I think. And I don't have any 7377 hardware available.
I agree that this needs to be tested (or dropped).
And its annoying that neither of us have the hardware at this time.
> Also, would anything break, if we split this into three patches? The first
> one would only modify g4evm.c with demuxed IRQs but without names. Then
> the sdhi/tmio driver will install the generic ISR for each of them, and in
> fact all interrupts would still only come on one IRQ. Then the second
> patch would modify intc-sh7377.c, after which IRQs will be routed to
> different vectors. And the third patch would then add names to IRQs. But
> maybe Paul prefers a single patch for all that.
Personally I think a single patch is the way to go.
Though I have no strong feelings on the issue.
With regards to your question about splitting the patch. Adding the names
as a separate patch should be fine for the reason you describe. However, I
suspect the other split you suggest would not work.
In any case, two patches would reflect the way the changes
have been made on the 7372 (mackerel and ap4evb).
^ permalink raw reply
* Re: [PATCH] [RFC] ARM: shmobile: g4evm: Use multiple irq vectors
From: Guennadi Liakhovetski @ 2011-08-26 12:56 UTC (permalink / raw)
To: Simon Horman; +Cc: linux-mmc, linux-sh, Paul Mundt, Magnus Damm
In-Reply-To: <20110826123411.GB29479@verge.net.au>
On Fri, 26 Aug 2011, Simon Horman wrote:
> On Fri, Aug 26, 2011 at 02:17:20PM +0200, Guennadi Liakhovetski wrote:
> > On Fri, 26 Aug 2011, Simon Horman wrote:
> >
> > > This patch is based on "ARM: arch-shmobile: Use multiple irq vectors for SDHI"
> > >
> > > It removes multiplexing of the SDHI vectors and names each IRQ source
> > > to allow the SDHI driver to used source-specific handlers.
> > >
> > > This is untested as I do not have access to a working g4evm.
> > >
> > > Signed-off-by: Simon Horman <horms@verge.net.au>
> > >
> > > ---
> > >
> > > Requires "mmc: sdhi: Allow specific IRQ sources to use corresponding handlers."
> > >
> > > *** compile tested only ***
> > > ---
> > > arch/arm/mach-shmobile/board-g4evm.c | 26 ++++++++++++++++++++++-
> > > arch/arm/mach-shmobile/intc-sh7377.c | 36 ++++++++++++++++-----------------
> >
> > This second file should not be here, right?
>
> I believe that the g4evm uses the sh7377 and that the multiplexing of
> SDHIinterrupts for the 7377 need to be removed in order to provide multiple
> SDHI irq sources.
>
> Am I missing something?
Maybe not, I just misread your patch description as that it only should
touch the board itself. Since intc-sh7377.c has to be touched too, this
should be tested, I think. And I don't have any 7377 hardware available.
Also, would anything break, if we split this into three patches? The first
one would only modify g4evm.c with demuxed IRQs but without names. Then
the sdhi/tmio driver will install the generic ISR for each of them, and in
fact all interrupts would still only come on one IRQ. Then the second
patch would modify intc-sh7377.c, after which IRQs will be routed to
different vectors. And the third patch would then add names to IRQs. But
maybe Paul prefers a single patch for all that.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] [RFC] ARM: shmobile: g4evm: Use multiple irq vectors for
From: Simon Horman @ 2011-08-26 12:34 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linux-mmc, linux-sh, Paul Mundt, Magnus Damm
In-Reply-To: <Pine.LNX.4.64.1108261416330.25272@axis700.grange>
On Fri, Aug 26, 2011 at 02:17:20PM +0200, Guennadi Liakhovetski wrote:
> On Fri, 26 Aug 2011, Simon Horman wrote:
>
> > This patch is based on "ARM: arch-shmobile: Use multiple irq vectors for SDHI"
> >
> > It removes multiplexing of the SDHI vectors and names each IRQ source
> > to allow the SDHI driver to used source-specific handlers.
> >
> > This is untested as I do not have access to a working g4evm.
> >
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > ---
> >
> > Requires "mmc: sdhi: Allow specific IRQ sources to use corresponding handlers."
> >
> > *** compile tested only ***
> > ---
> > arch/arm/mach-shmobile/board-g4evm.c | 26 ++++++++++++++++++++++-
> > arch/arm/mach-shmobile/intc-sh7377.c | 36 ++++++++++++++++-----------------
>
> This second file should not be here, right?
I believe that the g4evm uses the sh7377 and that the multiplexing of
SDHIinterrupts for the 7377 need to be removed in order to provide multiple
SDHI irq sources.
Am I missing something?
^ permalink raw reply
* Re: [PATCH] [RFC] ARM: shmobile: g4evm: Use multiple irq vectors
From: Guennadi Liakhovetski @ 2011-08-26 12:17 UTC (permalink / raw)
To: Simon Horman; +Cc: linux-mmc, linux-sh, Paul Mundt, Magnus Damm
In-Reply-To: <1314353627-23079-1-git-send-email-horms@verge.net.au>
On Fri, 26 Aug 2011, Simon Horman wrote:
> This patch is based on "ARM: arch-shmobile: Use multiple irq vectors for SDHI"
>
> It removes multiplexing of the SDHI vectors and names each IRQ source
> to allow the SDHI driver to used source-specific handlers.
>
> This is untested as I do not have access to a working g4evm.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> Requires "mmc: sdhi: Allow specific IRQ sources to use corresponding handlers."
>
> *** compile tested only ***
> ---
> arch/arm/mach-shmobile/board-g4evm.c | 26 ++++++++++++++++++++++-
> arch/arm/mach-shmobile/intc-sh7377.c | 36 ++++++++++++++++-----------------
This second file should not be here, right?
Thanks
Guennadi
> 2 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-g4evm.c b/arch/arm/mach-shmobile/board-g4evm.c
> index 8e3c555..60721f1 100644
> --- a/arch/arm/mach-shmobile/board-g4evm.c
> +++ b/arch/arm/mach-shmobile/board-g4evm.c
> @@ -209,7 +209,18 @@ static struct resource sdhi0_resources[] = {
> .flags = IORESOURCE_MEM,
> },
> [1] = {
> - .start = evt2irq(0x0e00), /* SDHI0 */
> + .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,
> },
> };
> @@ -236,7 +247,18 @@ static struct resource sdhi1_resources[] = {
> .flags = IORESOURCE_MEM,
> },
> [1] = {
> - .start = evt2irq(0x0e80), /* SDHI1 */
> + .name = SH_MOBILE_SDHI_IRQ_CARD_DETECT,
> + .start = evt2irq(0x0e80) /* SDHI1_SDHI0I0 */,
> + .flags = IORESOURCE_IRQ,
> + },
> + [2] = {
> + .name = SH_MOBILE_SDHI_IRQ_SDCARD,
> + .start = evt2irq(0x0ea0) /* SDHI1_SDHI0I1 */,
> + .flags = IORESOURCE_IRQ,
> + },
> + [3] = {
> + .name = SH_MOBILE_SDHI_IRQ_SDIO,
> + .start = evt2irq(0x0ec0) /* SDHI1_SDHI0I2 */,
> .flags = IORESOURCE_IRQ,
> },
> };
> diff --git a/arch/arm/mach-shmobile/intc-sh7377.c b/arch/arm/mach-shmobile/intc-sh7377.c
> index fe45154..6395687 100644
> --- a/arch/arm/mach-shmobile/intc-sh7377.c
> +++ b/arch/arm/mach-shmobile/intc-sh7377.c
> @@ -27,8 +27,6 @@
>
> enum {
> UNUSED_INTCA = 0,
> - ENABLED,
> - DISABLED,
>
> /* interrupt sources INTCA */
> IRQ0A, IRQ1A, IRQ2A, IRQ3A, IRQ4A, IRQ5A, IRQ6A, IRQ7A,
> @@ -51,8 +49,8 @@ enum {
> MSIOF2, MSIOF1,
> SCIFA4, SCIFA5, SCIFB,
> FLCTL_FLSTEI, FLCTL_FLTENDI, FLCTL_FLTREQ0I, FLCTL_FLTREQ1I,
> - SDHI0,
> - SDHI1,
> + SDHI0_SDHI0I0, SDHI0_SDHI0I1, SDHI0_SDHI0I2, SDHI0_SDHI0I3,
> + SDHI1_SDHI1I0, SDHI1_SDHI1I1, SDHI1_SDHI1I2, SDHI1_SDHI1I3,
> MSU_MSU, MSU_MSU2,
> IRREM,
> MSUG,
> @@ -87,7 +85,7 @@ enum {
> /* interrupt groups INTCA */
> DMAC_1, DMAC_2, DMAC2_1, DMAC2_2, DMAC3_1, DMAC3_2, SHWYSTAT,
> AP_ARM1, AP_ARM2, USBHS, SPU2, FLCTL, IIC1,
> - ICUSB, ICUDMC
> + ICUSB, ICUDMC, SDHI0, SDHI1,
> };
>
> static struct intc_vect intca_vectors[] __initdata = {
> @@ -130,10 +128,10 @@ static struct intc_vect intca_vectors[] __initdata = {
> INTC_VECT(SCIFB, 0x0d60),
> INTC_VECT(FLCTL_FLSTEI, 0x0d80), INTC_VECT(FLCTL_FLTENDI, 0x0da0),
> INTC_VECT(FLCTL_FLTREQ0I, 0x0dc0), INTC_VECT(FLCTL_FLTREQ1I, 0x0de0),
> - INTC_VECT(SDHI0, 0x0e00), INTC_VECT(SDHI0, 0x0e20),
> - INTC_VECT(SDHI0, 0x0e40), INTC_VECT(SDHI0, 0x0e60),
> - INTC_VECT(SDHI1, 0x0e80), INTC_VECT(SDHI1, 0x0ea0),
> - INTC_VECT(SDHI1, 0x0ec0), INTC_VECT(SDHI1, 0x0ee0),
> + INTC_VECT(SDHI0_SDHI0I0, 0x0e00), INTC_VECT(SDHI0_SDHI0I1, 0x0e20),
> + INTC_VECT(SDHI0_SDHI0I2, 0x0e40), INTC_VECT(SDHI0_SDHI0I3, 0x0e60),
> + INTC_VECT(SDHI1_SDHI1I0, 0x0e80), INTC_VECT(SDHI1_SDHI1I1, 0x0ea0),
> + INTC_VECT(SDHI1_SDHI1I2, 0x0ec0), INTC_VECT(SDHI1_SDHI1I3, 0x0ee0),
> INTC_VECT(MSU_MSU, 0x0f20), INTC_VECT(MSU_MSU2, 0x0f40),
> INTC_VECT(IRREM, 0x0f60),
> INTC_VECT(MSUG, 0x0fa0),
> @@ -200,6 +198,10 @@ static struct intc_group intca_groups[] __initdata = {
> INTC_GROUP(SHWYSTAT, SHWYSTAT_RT, SHWYSTAT_HS, SHWYSTAT_COM),
> INTC_GROUP(ICUSB, ICUSB_ICUSB0, ICUSB_ICUSB1),
> INTC_GROUP(ICUDMC, ICUDMC_ICUDMC1, ICUDMC_ICUDMC2),
> + INTC_GROUP(SDHI0, SDHI0_SDHI0I0, SDHI0_SDHI0I1,
> + SDHI0_SDHI0I2, SDHI0_SDHI0I3),
> + INTC_GROUP(SDHI1, SDHI1_SDHI1I0, SDHI1_SDHI1I1,
> + SDHI1_SDHI1I2, SDHI1_SDHI1I3)
> };
>
> static struct intc_mask_reg intca_mask_registers[] __initdata = {
> @@ -234,10 +236,10 @@ static struct intc_mask_reg intca_mask_registers[] __initdata = {
> { SCIFB, SCIFA5, SCIFA4, MSIOF1,
> 0, 0, MSIOF2, 0 } },
> { 0xe694009c, 0xe69400dc, 8, /* IMR7A / IMCR7A */
> - { DISABLED, ENABLED, ENABLED, ENABLED,
> + { SDHI0_SDHI0I3, SDHI0_SDHI0I2, SDHI0_SDHI0I1, SDHI0_SDHI0I0,
> FLCTL_FLTREQ1I, FLCTL_FLTREQ0I, FLCTL_FLTENDI, FLCTL_FLSTEI } },
> { 0xe69400a0, 0xe69400e0, 8, /* IMR8A / IMCR8A */
> - { DISABLED, ENABLED, ENABLED, ENABLED,
> + { SDHI1_SDHI1I3, SDHI1_SDHI1I2, SDHI1_SDHI1I1, SDHI1_SDHI1I0,
> TTI20, USBDMAC_USHDMI, 0, MSUG } },
> { 0xe69400a4, 0xe69400e4, 8, /* IMR9A / IMCR9A */
> { CMT1_CMT13, CMT1_CMT12, CMT1_CMT11, CMT1_CMT10,
> @@ -337,14 +339,10 @@ static struct intc_mask_reg intca_ack_registers[] __initdata = {
> { IRQ24A, IRQ25A, IRQ26A, IRQ27A, IRQ28A, IRQ29A, IRQ30A, IRQ31A } },
> };
>
> -static struct intc_desc intca_desc __initdata = {
> - .name = "sh7377-intca",
> - .force_enable = ENABLED,
> - .force_disable = DISABLED,
> - .hw = INTC_HW_DESC(intca_vectors, intca_groups,
> - intca_mask_registers, intca_prio_registers,
> - intca_sense_registers, intca_ack_registers),
> -};
> +static DECLARE_INTC_DESC_ACK(intca_desc, "sh7377-intca",
> + intca_vectors, intca_groups,
> + intca_mask_registers, intca_prio_registers,
> + intca_sense_registers, intca_ack_registers);
>
> /* this macro ignore entry which is also in INTCA */
> #define __IGNORE(a...)
> --
> 1.7.5.4
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH v2] ARM: mach-shmobile: clock-sh7372: fixup USB-DMAC1 settings
From: Magnus Damm @ 2011-08-26 10:49 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <874o16up7v.wl%kuninori.morimoto.gx@renesas.com>
On Thu, Aug 25, 2011 at 12:47 PM, <kuninori.morimoto.gx@renesas.com> wrote:
> USB-DMAC1 needs SMSTPCR4/MSTP407 controls, not MSTP214
> this patch tested on mackerel board
>
> Reported-by: Magnus Damm <damm@opensource.se>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> v1 -> v2
>
> - tested on mackerel board
> - fix comment
> - fix MSTPxxx order
This looks much better, thanks!
/ magnus
^ permalink raw reply
* [PATCH] [RFC] ARM: shmobile: g4evm: Use multiple irq vectors for SDHI
From: Simon Horman @ 2011-08-26 10:13 UTC (permalink / raw)
To: linux-mmc, linux-sh
Cc: Paul Mundt, Guennadi Liakhovetski, Magnus Damm, Simon Horman
This patch is based on "ARM: arch-shmobile: Use multiple irq vectors for SDHI"
It removes multiplexing of the SDHI vectors and names each IRQ source
to allow the SDHI driver to used source-specific handlers.
This is untested as I do not have access to a working g4evm.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Requires "mmc: sdhi: Allow specific IRQ sources to use corresponding handlers."
*** compile tested only ***
---
arch/arm/mach-shmobile/board-g4evm.c | 26 ++++++++++++++++++++++-
arch/arm/mach-shmobile/intc-sh7377.c | 36 ++++++++++++++++-----------------
2 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-g4evm.c b/arch/arm/mach-shmobile/board-g4evm.c
index 8e3c555..60721f1 100644
--- a/arch/arm/mach-shmobile/board-g4evm.c
+++ b/arch/arm/mach-shmobile/board-g4evm.c
@@ -209,7 +209,18 @@ static struct resource sdhi0_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = evt2irq(0x0e00), /* SDHI0 */
+ .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,
},
};
@@ -236,7 +247,18 @@ static struct resource sdhi1_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = evt2irq(0x0e80), /* SDHI1 */
+ .name = SH_MOBILE_SDHI_IRQ_CARD_DETECT,
+ .start = evt2irq(0x0e80) /* SDHI1_SDHI0I0 */,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .name = SH_MOBILE_SDHI_IRQ_SDCARD,
+ .start = evt2irq(0x0ea0) /* SDHI1_SDHI0I1 */,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .name = SH_MOBILE_SDHI_IRQ_SDIO,
+ .start = evt2irq(0x0ec0) /* SDHI1_SDHI0I2 */,
.flags = IORESOURCE_IRQ,
},
};
diff --git a/arch/arm/mach-shmobile/intc-sh7377.c b/arch/arm/mach-shmobile/intc-sh7377.c
index fe45154..6395687 100644
--- a/arch/arm/mach-shmobile/intc-sh7377.c
+++ b/arch/arm/mach-shmobile/intc-sh7377.c
@@ -27,8 +27,6 @@
enum {
UNUSED_INTCA = 0,
- ENABLED,
- DISABLED,
/* interrupt sources INTCA */
IRQ0A, IRQ1A, IRQ2A, IRQ3A, IRQ4A, IRQ5A, IRQ6A, IRQ7A,
@@ -51,8 +49,8 @@ enum {
MSIOF2, MSIOF1,
SCIFA4, SCIFA5, SCIFB,
FLCTL_FLSTEI, FLCTL_FLTENDI, FLCTL_FLTREQ0I, FLCTL_FLTREQ1I,
- SDHI0,
- SDHI1,
+ SDHI0_SDHI0I0, SDHI0_SDHI0I1, SDHI0_SDHI0I2, SDHI0_SDHI0I3,
+ SDHI1_SDHI1I0, SDHI1_SDHI1I1, SDHI1_SDHI1I2, SDHI1_SDHI1I3,
MSU_MSU, MSU_MSU2,
IRREM,
MSUG,
@@ -87,7 +85,7 @@ enum {
/* interrupt groups INTCA */
DMAC_1, DMAC_2, DMAC2_1, DMAC2_2, DMAC3_1, DMAC3_2, SHWYSTAT,
AP_ARM1, AP_ARM2, USBHS, SPU2, FLCTL, IIC1,
- ICUSB, ICUDMC
+ ICUSB, ICUDMC, SDHI0, SDHI1,
};
static struct intc_vect intca_vectors[] __initdata = {
@@ -130,10 +128,10 @@ static struct intc_vect intca_vectors[] __initdata = {
INTC_VECT(SCIFB, 0x0d60),
INTC_VECT(FLCTL_FLSTEI, 0x0d80), INTC_VECT(FLCTL_FLTENDI, 0x0da0),
INTC_VECT(FLCTL_FLTREQ0I, 0x0dc0), INTC_VECT(FLCTL_FLTREQ1I, 0x0de0),
- INTC_VECT(SDHI0, 0x0e00), INTC_VECT(SDHI0, 0x0e20),
- INTC_VECT(SDHI0, 0x0e40), INTC_VECT(SDHI0, 0x0e60),
- INTC_VECT(SDHI1, 0x0e80), INTC_VECT(SDHI1, 0x0ea0),
- INTC_VECT(SDHI1, 0x0ec0), INTC_VECT(SDHI1, 0x0ee0),
+ INTC_VECT(SDHI0_SDHI0I0, 0x0e00), INTC_VECT(SDHI0_SDHI0I1, 0x0e20),
+ INTC_VECT(SDHI0_SDHI0I2, 0x0e40), INTC_VECT(SDHI0_SDHI0I3, 0x0e60),
+ INTC_VECT(SDHI1_SDHI1I0, 0x0e80), INTC_VECT(SDHI1_SDHI1I1, 0x0ea0),
+ INTC_VECT(SDHI1_SDHI1I2, 0x0ec0), INTC_VECT(SDHI1_SDHI1I3, 0x0ee0),
INTC_VECT(MSU_MSU, 0x0f20), INTC_VECT(MSU_MSU2, 0x0f40),
INTC_VECT(IRREM, 0x0f60),
INTC_VECT(MSUG, 0x0fa0),
@@ -200,6 +198,10 @@ static struct intc_group intca_groups[] __initdata = {
INTC_GROUP(SHWYSTAT, SHWYSTAT_RT, SHWYSTAT_HS, SHWYSTAT_COM),
INTC_GROUP(ICUSB, ICUSB_ICUSB0, ICUSB_ICUSB1),
INTC_GROUP(ICUDMC, ICUDMC_ICUDMC1, ICUDMC_ICUDMC2),
+ INTC_GROUP(SDHI0, SDHI0_SDHI0I0, SDHI0_SDHI0I1,
+ SDHI0_SDHI0I2, SDHI0_SDHI0I3),
+ INTC_GROUP(SDHI1, SDHI1_SDHI1I0, SDHI1_SDHI1I1,
+ SDHI1_SDHI1I2, SDHI1_SDHI1I3)
};
static struct intc_mask_reg intca_mask_registers[] __initdata = {
@@ -234,10 +236,10 @@ static struct intc_mask_reg intca_mask_registers[] __initdata = {
{ SCIFB, SCIFA5, SCIFA4, MSIOF1,
0, 0, MSIOF2, 0 } },
{ 0xe694009c, 0xe69400dc, 8, /* IMR7A / IMCR7A */
- { DISABLED, ENABLED, ENABLED, ENABLED,
+ { SDHI0_SDHI0I3, SDHI0_SDHI0I2, SDHI0_SDHI0I1, SDHI0_SDHI0I0,
FLCTL_FLTREQ1I, FLCTL_FLTREQ0I, FLCTL_FLTENDI, FLCTL_FLSTEI } },
{ 0xe69400a0, 0xe69400e0, 8, /* IMR8A / IMCR8A */
- { DISABLED, ENABLED, ENABLED, ENABLED,
+ { SDHI1_SDHI1I3, SDHI1_SDHI1I2, SDHI1_SDHI1I1, SDHI1_SDHI1I0,
TTI20, USBDMAC_USHDMI, 0, MSUG } },
{ 0xe69400a4, 0xe69400e4, 8, /* IMR9A / IMCR9A */
{ CMT1_CMT13, CMT1_CMT12, CMT1_CMT11, CMT1_CMT10,
@@ -337,14 +339,10 @@ static struct intc_mask_reg intca_ack_registers[] __initdata = {
{ IRQ24A, IRQ25A, IRQ26A, IRQ27A, IRQ28A, IRQ29A, IRQ30A, IRQ31A } },
};
-static struct intc_desc intca_desc __initdata = {
- .name = "sh7377-intca",
- .force_enable = ENABLED,
- .force_disable = DISABLED,
- .hw = INTC_HW_DESC(intca_vectors, intca_groups,
- intca_mask_registers, intca_prio_registers,
- intca_sense_registers, intca_ack_registers),
-};
+static DECLARE_INTC_DESC_ACK(intca_desc, "sh7377-intca",
+ intca_vectors, intca_groups,
+ intca_mask_registers, intca_prio_registers,
+ intca_sense_registers, intca_ack_registers);
/* this macro ignore entry which is also in INTCA */
#define __IGNORE(a...)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v8 4/4] ARM: shmobile: ag5evm, ap4: Named SDHI IRQ sources
From: Simon Horman @ 2011-08-26 9:48 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-mmc, linux-sh, Chris Ball, Paul Mundt, Magnus Damm
In-Reply-To: <Pine.LNX.4.64.1108261121280.25272@axis700.grange>
On Fri, Aug 26, 2011 at 11:22:00AM +0200, Guennadi Liakhovetski wrote:
> On Fri, 26 Aug 2011, Simon Horman wrote:
>
> > On Fri, Aug 26, 2011 at 10:44:16AM +0200, Guennadi Liakhovetski wrote:
> > > On Thu, 25 Aug 2011, Simon Horman wrote:
> > >
> > > > This allows specific (non-multiplexed) IRQ handlers to be used.
> > >
> > > Could you also prepare a similar patch for g4evm and ap4evb? No need to
> > > change this one, just prepare another one, please.
> >
> > Sure, though I do not have access to those boards to test
> > (as far as I know).
>
> Ok, I've got an ap4evb, so, I'll prepare that patch myself.
I can give you this to test:
From 18f06d15a1b08861b06727e9a429201b19e4323a Mon Sep 17 00:00:00 2001
From: Simon Horman <horms@verge.net.au>
Date: Fri, 26 Aug 2011 18:44:53 +0900
Subject: [PATCH] ARM: shmobile: ap4evb: Name SDHI IRQ sources
This allows specific (non-multiplexed) IRQ handlers to be used
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/board-ap4evb.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index 9e0856b..ef5c7ca 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -339,14 +339,17 @@ static struct resource sdhi0_resources[] = {
.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,
},
@@ -380,14 +383,17 @@ static struct resource sdhi1_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
+ 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,
},
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH][RESEND] ARM: mach-shmobile: sh7372 generic suspend/resume support
From: Magnus Damm @ 2011-08-26 9:47 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110826051205.24370.44903.sendpatchset@rxone.opensource.se>
On Fri, Aug 26, 2011 at 6:23 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Aug 26, 2011 at 05:44:04PM +0900, Magnus Damm wrote:
>> Good question. This was posted before the 3.1-rc merge window, but
>> didn't make it into mainline for some unknown
>> reason. I'm all for merging things sooner than later if possible, but
>> I understand if 3.1-rc is out of the question at this point.
>>
>> If you are offering to queue this up for the 3.2 merge window then I
>> am instead suggesting that Rafael picks this up in his PM tree because
>> there are other PM related patches that build on top of this one.
>
> If Rafael wants to pick it up, that's fine.
Let's see what he says about that.
>> While at it, for the 3.1 release, would it be possible to update the
>> mach-types list in mainline? We have patches for the Kota2 board that
>> depend on the mach-type update.
>
> I dropped my mach-types update (which was required to fix a build error -
> because a platform was introduced into mainline without its entry in
> mach-types) as the update was causing a number of problems with other
> platforms and drivers in mainline.
Ouch.
> I'm not sure what the long term future of mach-types is, as it's become
> quite a burden to manually update it each time due to the amount of crap
> now contained in there, and it seems automated filtering results in
> breakage.
Honestly, I think your mach-types list and the patch tracker have
served their purpose for a long time. They make totally sense to
handle the kind of work load and of diverse hardware platform support
that you have been dealing with over the years. These days I suspect
there are other solutions available that may make it easier for you.
> I think the whole interface to it needs to be revised so that it is
> purely read-only, and editing is done via human interaction adding a
> level of manual approval to the system. It's the only way I can think
> of stopping the 'ARM', 'IMX', etc like entries from being added, along
> with ensuring that the machine_is_xxx() and MACH_TYPE_xxx() names always
> match.
I guess you prefer to keep the information separate from the Linux kernel?
If you don't mind, then wouldn't it be possible to move over the
information to some more verbose form of the mach-types file and store
it in the kernel tree and use regular git to manage it? That's what I
would do.
Another option is to extend your web interface and separate addition
of new entries from modification of already existing ones. Perhaps new
entries can be merged at any time in -rc but modification needs to
happen early in the cycle.
Cheers,
/ magnus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox