[PATCH] Fix IGEPv2 second MMC channel power supply
Commit 72f381ba056 removed an unused regulator entry, but left
the second MMC channel (used by the Libertas WLAN mudule) without
link to power regulator. This causes the SDIO module to fail being
detected.
This patch adds a second supply to the existing MMC1 regulator,
and let MMC2 hang off it. With that patch, the second channel is
properly detected.
Tested on an IGEPv2 Rev-B.
Signed-off-by: Marc Zyngier m...@misterjones.org
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
Note that this doesn't fix WLAN itself on 2.6.37-rc1...
arch/arm/mach-omap2/board-igep0020.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..b66d114 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -257,8 +257,9 @@ static inline void __init igep2_init_smsc911x(void) { }
static struct omap_board_config_kernel igep2_config[] __initdata = {
};
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
- .supply = vmmc,
+static struct regulator_consumer_supply igep2_vmmc1_supplies[] = {
+ [0] = { .supply = vmmc, },
+ [1] = { .supply = vmmc, },
};
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
@@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = igep2_vmmc1_supply,
+ .num_consumer_supplies = 2,
+ .consumer_supplies = igep2_vmmc1_supplies,
};
static struct omap2_hsmmc_info mmc[] = {
@@ -376,7 +377,8 @@ static int igep2_twl_gpio_setup(struct device *dev,
* link regulators to MMC adapters ... we know the
* regulators will be set up only *after* we return.
*/
- igep2_vmmc1_supply.dev = mmc[0].dev;
+ igep2_vmmc1_supplies[0].dev = mmc[0].dev;
+ igep2_vmmc1_supplies[1].dev = mmc[1].dev;
/*
* REVISIT: need ehci-omap hooks for external VBUS
--
1.7.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix IGEPv2 second MMC channel power supply
On Sun, 14 Nov 2010 19:11:46 +0100 Enric Balletbò i Serra eballe...@gmail.com wrote: Why we need to define an unexistent regulator in board file ? This should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel configuration ? I'm not adding another regulator, but instead simply exposing the fact (or rather my guess) that the same regulator (vmmc1) is powering the two MMC channels. Not having access to the board schematics, I can't tell if that reflects the reality or not. But using CONFIG_DUMMY_REGULATOR seems the wrong idea to me, as it's just papering over the issue. We should be exposing what's really on the board (a fixed regulator if that's the case). M. -- I'm the slime oozin' out from your TV set... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix IGEPv2 second MMC channel power supply
On Mon, 15 Nov 2010 09:32:22 +0100 Enric Balletbò i Serra eballe...@gmail.com wrote: Hi Enric, So the DUMMY_REGULATOR is only a workaround when a regulator is not defined and shouldn't be used ? Sorry if this is a stupid question but regulator interface is not too clear for me. My understanding is that DUMMY_REGULATOR kicks in when the regulator setup is incomplete, and when it's better to fix things behind the user's back rather than leaving him with a broken device. The reality is this : --- | 3V3 | | 1V8 | --- | | - | WIFI/BT | - | ( MMC2 at 1V8 ) | OMAP | --- 3V3 is a fixed regulator 1V8 is a fixed regulator (VIO from TWL4030) So, which you think is the right solution ? I think we should provide a fixed regulator to the device, wired to the .vio field of twl4030_platform_data. I'll submit a patch later today, once I get a chance to test it on my board. Cheers, M. -- I'm the slime oozin' out from your TV set... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Fix IGEPv2 second MMC channel power supply
Commit 72f381ba056 (omap3: Remove VMMC2 regulator on IGEP v2)
removed an unused regulator entry, but left the second MMC channel
(used by the Libertas WLAN module) without link to power regulator.
This causes the SDIO module to fail being detected.
This patch adds the two regulators that actually feed the WLAN module
(1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the
second channel is properly detected. Details of the power supply
implementation were kindly provided by Enric Balletbo i Serra.
Also change vmmc1 to use symbolic names instead of direct device
reference.
Tested on an IGEPv2 Rev-B.
Signed-off-by: Marc Zyngier m...@misterjones.org
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-igep0020.c | 61 -
1 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..9a85e60 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
@@ -257,9 +258,8 @@ static inline void __init igep2_init_smsc911x(void) { }
static struct omap_board_config_kernel igep2_config[] __initdata = {
};
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
- .supply = vmmc,
-};
+static struct regulator_consumer_supply igep2_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data igep2_vmmc1 = {
@@ -276,6 +276,52 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies = igep2_vmmc1_supply,
};
+static struct regulator_consumer_supply igep2_vio_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = 1,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vio_supply,
+};
+
+static struct regulator_consumer_supply igep2_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vmmc2 = {
+ .constraints= {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .always_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vmmc2_supply,
+};
+
+static struct fixed_voltage_config igep2_vwlan = {
+ .supply_name= vwlan,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .enabled_at_boot= 1,
+ .init_data = igep2_vmmc2,
+};
+
+static struct platform_device igep2_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 0,
+ .dev = {
+ .platform_data = igep2_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -373,12 +419,6 @@ static int igep2_twl_gpio_setup(struct device *dev,
omap2_hsmmc_init(mmc);
/*
-* link regulators to MMC adapters ... we know the
-* regulators will be set up only *after* we return.
-*/
- igep2_vmmc1_supply.dev = mmc[0].dev;
-
- /*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
@@ -489,6 +529,7 @@ static void __init igep2_display_init(void)
static struct platform_device *igep2_devices[] __initdata = {
igep2_dss_device,
+ igep2_vwlan_device,
};
static void __init igep2_init_irq(void)
@@ -519,7 +560,7 @@ static struct twl4030_platform_data igep2_twldata = {
.gpio = igep2_twl4030_gpio_pdata,
.vmmc1 = igep2_vmmc1,
.vpll2 = igep2_vpll2,
-
+ .vio= igep2_vio,
};
static struct i2c_board_info __initdata igep2_i2c1_boardinfo[] = {
--
1.7.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
Commit 72f381ba056 (omap3: Remove VMMC2 regulator on IGEP v2)
removed an unused regulator entry, but left the second MMC channel
(used by the Libertas WLAN module) without link to power regulator.
This causes the SDIO module to fail being detected.
This patch adds the two regulators that actually feed the WLAN module
(1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the
second channel is properly detected. Details of the power supply
implementation were kindly provided by Enric Balletbo i Serra.
Also change vmmc1 to use symbolic names instead of direct device
reference.
Tested on an IGEPv2 Rev-B.
Signed-off-by: Marc Zyngier m...@misterjones.org
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-igep0020.c | 61 -
1 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..9a85e60 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
@@ -257,9 +258,8 @@ static inline void __init igep2_init_smsc911x(void) { }
static struct omap_board_config_kernel igep2_config[] __initdata = {
};
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
- .supply = vmmc,
-};
+static struct regulator_consumer_supply igep2_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data igep2_vmmc1 = {
@@ -276,6 +276,52 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies = igep2_vmmc1_supply,
};
+static struct regulator_consumer_supply igep2_vio_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = 1,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vio_supply,
+};
+
+static struct regulator_consumer_supply igep2_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vmmc2 = {
+ .constraints= {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .always_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vmmc2_supply,
+};
+
+static struct fixed_voltage_config igep2_vwlan = {
+ .supply_name= vwlan,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .enabled_at_boot= 1,
+ .init_data = igep2_vmmc2,
+};
+
+static struct platform_device igep2_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 0,
+ .dev = {
+ .platform_data = igep2_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -373,12 +419,6 @@ static int igep2_twl_gpio_setup(struct device *dev,
omap2_hsmmc_init(mmc);
/*
-* link regulators to MMC adapters ... we know the
-* regulators will be set up only *after* we return.
-*/
- igep2_vmmc1_supply.dev = mmc[0].dev;
-
- /*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
@@ -489,6 +529,7 @@ static void __init igep2_display_init(void)
static struct platform_device *igep2_devices[] __initdata = {
igep2_dss_device,
+ igep2_vwlan_device,
};
static void __init igep2_init_irq(void)
@@ -519,7 +560,7 @@ static struct twl4030_platform_data igep2_twldata = {
.gpio = igep2_twl4030_gpio_pdata,
.vmmc1 = igep2_vmmc1,
.vpll2 = igep2_vpll2,
-
+ .vio= igep2_vio,
};
static struct i2c_board_info __initdata igep2_i2c1_boardinfo[] = {
--
1.7.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] omap3: igep3: Fix IGEP module second MMC channel power supply.
On Mon, 10 Jan 2011 14:26:13 +0100, Enric Balletbo i Serra eballe...@gmail.com wrote: The second MMC channel (used by the WLAN/BT module) is not linked to power regulator. This causes the WLAN/BT module to fail being detected if CONFIG_REGULATOR_DUMMY is not set. This patch adds the two regulators that actually feed the WLAN/BT module (1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the second channel is properly detected. Also change vmmc1 to use symbolic names instead of direct device reference. Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com Acked-by: Marc Zyngier m...@misterjones.org -- Who you jivin' with that Cosmik Debris? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Serial: Define IRQ flags for 8250 driver
On Thu, 11 Jun 2009 19:53:50 -0500 Vikram Pandita vikram.pand...@ti.com wrote: Boards with serial irq High/Low/Rising/Falling IRQ requirement do not work today 8250 serial driver does not have provision to pass on IRQ flags from platform_device This is requred for OMAP Zoom2 board for which Serial IRQ trigger is IRQF_TRIGGER_HIGH Signed-off-by: Vikram Pandita vikram.pand...@ti.com Arcom Viper (pxa255 based) has the same kind of requirement (triggers on rising edge), and currently uses a couple of set_irq_type that I'd love to get rid of. So a patch like this one should definitely be considered. Best regards, M. -- We don't mess around. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: 8250: add IRQ trigger support
On Fri, 12 Jun 2009 12:32:51 -0500
Vikram Pandita vikram.pand...@ti.com wrote:
There is currently no provision for passing IRQ trigger flags for
serial IRQs with triggering requirements (such as GPIO IRQs.)
This patch adds UPF_IRQ_TRIG_* flags which map on to IRQF_TRIGGER_*
flags.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Note that this patch doesn't allow the interrupt to trigger on both
edges (not that I have ever seen a 8250 with this behavior, but this
is a valid configuration from an interrupt point of view).
Aside from this remark:
Acked-by: Marc Zyngier m...@misterjones.org
---
drivers/serial/8250.c | 10 ++
include/linux/serial_core.h |4
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index bab115e..8235ef5 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -1641,6 +1641,16 @@ static int serial_link_irq_chain(struct
uart_8250_port *up) struct irq_info *i;
int ret, irq_flags = up-port.flags UPF_SHARE_IRQ ?
IRQF_SHARED : 0;
+ /* Get IRQ Trigger Flag */
+ if (up-port.flags UPF_IRQ_TRIG_RISING)
+ irq_flags |= IRQF_TRIGGER_RISING;
+ else if (up-port.flags UPF_IRQ_TRIG_FALLING)
+ irq_flags |= IRQF_TRIGGER_FALLING;
+ else if (up-port.flags UPF_IRQ_TRIG_HIGH)
+ irq_flags |= IRQF_TRIGGER_HIGH;
+ else if (up-port.flags UPF_IRQ_TRIG_LOW)
+ irq_flags |= IRQF_TRIGGER_LOW;
+
mutex_lock(hash_mutex);
h = irq_lists[up-port.irq % NR_IRQ_HASH];
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 57a97e5..07591d5 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -296,7 +296,11 @@ struct uart_port {
#define UPF_SPD_WARP ((__force upf_t) (0x1010))
#define UPF_SKIP_TEST((__force upf_t) (1 6))
#define UPF_AUTO_IRQ ((__force upf_t) (1 7))
+#define UPF_IRQ_TRIG_RISING ((__force upf_t) (1 8))
+#define UPF_IRQ_TRIG_FALLING ((__force upf_t) (1 9))
+#define UPF_IRQ_TRIG_HIGH((__force upf_t) (1 10))
#define UPF_HARDPPS_CD ((__force upf_t) (1 11))
+#define UPF_IRQ_TRIG_LOW ((__force upf_t) (1 12))
#define UPF_LOW_LATENCY ((__force upf_t) (1 13))
#define UPF_BUGGY_UART ((__force upf_t) (1 14))
#define UPF_NO_TXEN_TEST ((__force upf_t) (1 15))
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: architected timers: Mark the clockevent with the C3_STOP feature
On 04/07/12 10:54, Santosh Shilimkar wrote: ARM arch timers stop in low power state and hence can not wakeup CPUs in deeper idle states when used as cloc event devices. Marking these clock event devices with C3_STOP so that during lowpower states, the tick is managed by wakeup capable broadcast timer. Cc: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Hi Santosh, I already have queued an identical patch from Lorenzo. Thanks for reminder anyway! M. --- arch/arm/kernel/arch_timer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c index dd58035..df44c8c 100644 --- a/arch/arm/kernel/arch_timer.c +++ b/arch/arm/kernel/arch_timer.c @@ -137,7 +137,7 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk) /* Be safe... */ arch_timer_disable(); - clk-features = CLOCK_EVT_FEAT_ONESHOT; + clk-features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP; clk-name = arch_sys_timer; clk-rating = 450; clk-set_mode = arch_timer_set_mode; -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On 31/08/11 16:27, Mark Salter wrote: On Wed, 2011-08-31 at 16:21 +0100, Will Deacon wrote: On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote: On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote: On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote: One question: why this write buffer issue did not happen at UP ARM V7 platform, whose dma buffer also uncache, but bufferable? Which CPU was on this platform? Using a 3.1.0-rc4+ kernel on a Pandaboard, and running 'hdparm -t' on a usb disk drive, I see ~5.8MB/s read speed. Same kernel, but passing nosmp on the commandline, I see 20.3MB/s. Can someone explain why nosmp would make such a difference? Oh gawd, that's horrible. I have a feeling it's probably a separate issue though, caused by: omap_modify_auxcoreboot0(0x200, 0xfdff); in boot_secondary for OMAP. Unfortunately I have no idea what that line is doing because it ends up talking to the secure monitor. Okay, I may poke around a bit with that to see I can get a better understanding. With the patched ehci-q.c, I see no noticeable difference between smp and nosmp. Both get me around 23.5MB/s with my setup. Oddly enough, this patch doesn't do anything on my Tegra setup. In both cases, I get around 17MB/s from a crap SD card plugged in a USB reader. This leads me to suspect that this issue is very much OMAP4 specific. Can anyone verify this theory on other some A9 platforms? Cheers, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
Hi Marc, On 31/08/11 17:55, Marc Dietrich wrote: Am Mittwoch 31 August 2011, 18:12:48 schrieb Marc Zyngier: [...] Oddly enough, this patch doesn't do anything on my Tegra setup. In both cases, I get around 17MB/s from a crap SD card plugged in a USB reader. This leads me to suspect that this issue is very much OMAP4 specific. Can anyone verify this theory on other some A9 platforms? That's odd. On my Tegra2 (on ac100) it boosts the transfer rate from 7 to 17 MB/s. I'm using a Harmony board. Could you share your kernel version, .config and dmesg? Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On 01/09/11 20:08, Stephen Warren wrote: Marc Dietich wrote at Thursday, September 01, 2011 5:14 AM: I'll add Stephen Warren from NVIDIA to the CC list. He has more HW to test on. Here are the results I found: Harmony: Tegra USB3 - SMSC9514 hub: NOT affected (Unplugging LAN cable, or disabling SMSC9514 LAN driver doesn't change this) Seaboard (springbank; clamshell): Tegra USB1 - no hub: Affected Seaboard (seaboard non-clamshell): Tegra USB1 - no hub: Affected Tegra USB3 - no hub: Affected TrimSlice: Tegra USB3 - unknown hub: Affected This implies there's something different about Harmony. Is the USB hub a clue? Seaboard doesn't have one, and although I don't know what model TrimSlice uses, I assume it's different since I know TrimSlice's Ethernet is not the same as Harmony's. Panda has the exact same USB hub configuration, and is affected. So we can rule this out. I don't see anything in board-harmony.c vs. board-seaboard.c that'd affect anything USB-related. Perhaps there's some kind of bootloader or BCT difference. However, my Harmony and both Seaboards both use (a very old) U-Boot and BCT from ChromeOS, so I don't imagine there's actually much difference there. I just noticed something else. Harmony is fast *most of the time*. In about one in 3 reboots, I get the slow behavior. When USB is fast, I also have I2C interrupts screaming: 85: 294321 0 GIC tegra-i2c 116: 0 0 GIC tegra-i2c 118: 98542 0 GIC tps6586x This is a couple of seconds after boot. When USB is slow, I see the following: [0.385270] tps6586x 3-0034: Chip ID read failed: -121 [0.390584] tps6586x: probe of 3-0034 failed with error -5 ... and I2C interrupt is quiet. The I2C interrupt handler calls writel(), which does a cache sync. That would explain the fast behavior of Harmony. Do you see the same this on your board? M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
Hi Tony, On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren t...@atomide.com wrote: Hi, * Marc Zyngier marc.zyng...@arm.com [120907 10:04]: From: Dave Martin dave.mar...@linaro.org This patch does two things: * Ensure that asynchronous aborts are masked at kernel entry. The bootloader should be masking these anyway, but this reduces the damage window just in case it doesn't. * Enter svc mode via exception return to ensure that CPU state is properly serialised. This does not matter when switching from an ordinary privileged mode (PL1 modes in ARMv7-AR rev C parlance), but it potentially does matter when switching from a another privileged mode such as hyp mode. This should allow the kernel to boot safely either from svc mode or hyp mode, even if no support for use of the ARM Virtualization Extensions is built into the kernel. Signed-off-by: Dave Martin dave.mar...@linaro.org Signed-off-by: Marc Zyngier marc.zyng...@arm.com Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB( .thumb ) @ switch to Thumb now. THUMB(1: ) -setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode -@ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT +bl __hyp_stub_install +#endif +@ ensure svc mode and all interrupts masked +safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. If you compiled for v6 only, we can safely exclude __hyp_stub_install, and I assume that you get past the decompressor. If so, that indicates some side effect of the safe_svcmode_maskall macro, and I suspect the movs pc, lr bit. Can you try the attached patch? It basically falls back to the previous behaviour if not entered in HYP mode. Thanks, M. -- Fast, cheap, reliable. Pick two.diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 658a15d..b21b97f 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,16 +254,17 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT bic \reg , \reg , #MODE_MASK orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) - msr spsr_cxsf, \reg - adr lr, BSYM(2f) bne 1f + orr \reg, \reg, #PSR_A_BIT + adr lr, BSYM(2f) + msr spsr_cxsf, \reg __MSR_ELR_HYP(14) __ERET -1: movspc, lr +1: msr cpsr_c, \reg 2: .endm
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Sat, 6 Oct 2012 10:06:00 -0400 (EDT), Nicolas Pitre nicolas.pi...@linaro.org wrote: On Sat, 6 Oct 2012, Marc Zyngier wrote: Hi Tony, On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren t...@atomide.com wrote: Hi, * Marc Zyngier marc.zyng...@arm.com [120907 10:04]: From: Dave Martin dave.mar...@linaro.org This patch does two things: * Ensure that asynchronous aborts are masked at kernel entry. The bootloader should be masking these anyway, but this reduces the damage window just in case it doesn't. * Enter svc mode via exception return to ensure that CPU state is properly serialised. This does not matter when switching from an ordinary privileged mode (PL1 modes in ARMv7-AR rev C parlance), but it potentially does matter when switching from a another privileged mode such as hyp mode. This should allow the kernel to boot safely either from svc mode or hyp mode, even if no support for use of the ARM Virtualization Extensions is built into the kernel. Signed-off-by: Dave Martin dave.mar...@linaro.org Signed-off-by: Marc Zyngier marc.zyng...@arm.com Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB( .thumb ) @ switch to Thumb now. THUMB(1:) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. If you compiled for v6 only, we can safely exclude __hyp_stub_install, and I assume that you get past the decompressor. If so, that indicates some side effect of the safe_svcmode_maskall macro, and I suspect the movs pc, lr bit. That would be surprizing if the movs pc, lr was to blame. This should work on all architectures. However the A bit might be to blame. Can you try the attached patch? It basically falls back to the previous behaviour if not entered in HYP mode. This is likely to work of course. However I think we should try to pinpoint the exact problem i.e. whether it is the A bit or the movs pc, lr which makes a difference (it is unlikely to be both). Agreed. We need to get to the bottom of this. Also, finding out which revisions of the 1136 are present on both of Tony's platforms could help understanding why this works on OMAP 2430 and not 2420. So I was about to suggest to test this patch as well: diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 683a1e6b60..118e22ee46 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,8 +254,7 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT - bic \reg , \reg , #MODE_MASK + mov \reg , #PSR_I_BIT | PSR_F_BIT orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) msr spsr_cxsf, \reg Yup, that should give us all the information we need. Thanks Nico. M. -- Fast, cheap, reliable. Pick two. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Sat, 6 Oct 2012 08:40:52 -0700, Tony Lindgren t...@atomide.com wrote: * Nicolas Pitre nicolas.pi...@linaro.org [121006 08:33]: On Sat, 6 Oct 2012, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [121006 03:19]: If so, that indicates some side effect of the safe_svcmode_maskall macro, and I suspect the movs pc, lr bit. Can you try the attached patch? It basically falls back to the previous behaviour if not entered in HYP mode. Yes, with this it boots OK. OK. In that case, I suggest this patch be sent to Russell to fix this issue so he could push the ARM stuff to Linus ASAP. Acked-by: Nicolas Pitre n...@linaro.org Yes we can come back to this: Tested-by: Tony Lindgren t...@atomide.com Now in Russell's patch system as #7549/1. Thanks a lot for your help on this both of you. M. -- Fast, cheap, reliable. Pick two. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On 08/10/12 12:01, Dave Martin wrote: On Sat, Oct 06, 2012 at 09:00:32AM -0700, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [121006 03:19]: If so, that indicates some side effect of the safe_svcmode_maskall macro, and I suspect the movs pc, lr bit. Can you try the attached patch? It basically falls back to the previous behaviour if not entered in HYP mode. ... diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 658a15d..b21b97f 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,16 +254,17 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT bic \reg , \reg , #MODE_MASK orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) - msr spsr_cxsf, \reg - adr lr, BSYM(2f) bne 1f + orr \reg, \reg, #PSR_A_BIT + adr lr, BSYM(2f) + msr spsr_cxsf, \reg __MSR_ELR_HYP(14) __ERET -1: movspc, lr +1: msr cpsr_c, \reg 2: .endm The minimal version of this that still boots on my n800 is just the last change of the above patch: --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -263,7 +263,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT) bne 1f __MSR_ELR_HYP(14) __ERET -1: movspc, lr +1: msr cpsr_c, \reg 2: .endm In an attempt to narrow this down... Can you follow this (i.e., _after_ a known successful switch to SVC mode) (a) mrs \reg, cpsr msr spsr_cxsf, \reg adr \reg, 3f movspc, lr 3: and (b) mrs \reg, cpsr orr \reg, \reg, #CPSR_A_BIT msr cpsr_cxsf, \reg and (c) mrs \reg, cpsr orr \reg, \reg, #CPSR_A_BIT msr spsr_cxsf, \reg adr \reg, 3f movspc, lr 3: If only (a) works, this would suggest that the attempt to set the A bit is causing the problem. If only (b) works, this suggests that the A bit is OK but that some invalid hardware state, or something else we don't understand, is causing exception returns to fail in general. If (a) and (b) work but (c) fails, this suggests that specifically trying to set the A bit via an exception return is problematic. If all of them work then this suggests some invalid hardware state or something else we don't understand, but which is cleared by the initial msr cpsr_c which clobbers the processor mode. Playing with an Integrator-CP with a 1136 tile, the only way I could cause the thing to fail was to boot the thing in SYSTEM mode. Tony, can you possibly also try the attached patch? Thanks, M. -- Jazz is not dead. It just smells funny...diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 683a1e6..7714ec7 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -253,6 +253,8 @@ mrs \reg , cpsr mov lr , \reg and lr , lr , #MODE_MASK + cmp lr , #SYSTEM_MODE /* Yet another braindead platform? */ + beq omgsys cmp lr , #HYP_MODE orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT bic \reg , \reg , #MODE_MASK @@ -264,6 +266,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT ) __MSR_ELR_HYP(14) __ERET 1: movs pc, lr +omgsys: msr cpsr_c, \reg 2: .endm
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote:
On Mon, Apr 04, 2011 at 12:03:42PM +0100, Catalin Marinas wrote:
On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote:
On Sunday 03 April 2011, Russell King - ARM Linux wrote:
Then there's those which change the cs-read function pointer at
runtime,
...
and those which share that pointer with their sched_clock()
implementation.
Abstracting sched_clock() to be run-time selected is something that
needs to be taken care of. Maybe we could have a generic sched_clock
implementation that is written on top of clocksource instead of jiffies,
and always select that on architectures that have a decent clocksource.
On Cortex-A15 with the virtualisation extensions and architected timers
the clocksource is implemented using a physical counter (as we want
wall-clock timing). But for sched_clock() we may want to use a virtual
counter (which is basically an offset from the physical one, set by the
hypervisor during guest OS switching). Marc already posted some patches
for this.
I had a quick look at the two patches, but I was far from impressed
due to the apparant complexity I saw.
There's no point in trying to consolidate stuff if it results in a net
increase in the amount of code to be maintained as that just increases
the burden, churn and maintainence headache.
Is there an easier way to consolidate it across all platforms? I think
so:
static DEFINE_CLOCK_DATA(cd);
static u32 sched_clock_mask;
static u32 (*read_sched_clock)(void);
unsigned long long notrace sched_clock(void)
{
if (read_sched_clock) {
u32 cyc = read_sched_clock();
return cyc_to_sched_clock(cd, cyc, sched_clock_mask);
} else {
/* jiffies based code */
}
}
static void notrace update_sched_clock(void)
{
u32 cyc = read_sched_clock();
update_sched_clock(cd, cyc, sched_clock_mask);
}
void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
{
BUG_ON(bits 32);
read_sched_clock = read;
sched_clock_mask = (1 bits) - 1;
init_sched_clock(cd, update_sched_clock, bits, rate);
}
and then get rid of the per-platform implementations entirely - all
that platforms then have to provide is a read function and a call to
setup_sched_clock().
The complexity mostly comes the fact that I tried to avoid having more
runtime complexity on platforms that didn't need to select their
sched_clock() implementation at runtime (no indirection while calling
sched_clock()).
If this can be relaxed, then your implementation is definitely better.
Whether its worth it or not is questionable - the above is more lines
of code than many of the existing implementations, and we're not going
to shrink the existing implementations by much (maybe one to three
lines.) The only thing we gain is the ability to select an implementation
at runtime.
I believe this last point to be rather important if we plan to have this
mythical single kernel covering several architectures. It's also nice
for the A15 to be able to use some default sched_clock() implementation
as a fallback if the generic timers are not available for some reason.
M.
--
Reality is an implementation detail.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote: On Mon, Apr 04, 2011 at 02:24:17PM +0100, Marc Zyngier wrote: On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote: Whether its worth it or not is questionable - the above is more lines of code than many of the existing implementations, and we're not going to shrink the existing implementations by much (maybe one to three lines.) The only thing we gain is the ability to select an implementation at runtime. I believe this last point to be rather important if we plan to have this mythical single kernel covering several architectures. It's also nice for the A15 to be able to use some default sched_clock() implementation as a fallback if the generic timers are not available for some reason. If ARM are going to architect a set of timers into the hardware, let's make sure that all such hardware has them so we can dig ourselves out of this crappy mess that we find ourselves in today. As far as I know, A15 always has a set of generic timers. It may be that they are not available (frequency not programmed into the CNTFREQ register), or that someone decided to use a better alternative (for some particular interpretation of better). Overall, it seems like we need some degree of flexibility to have several sched_clock() implementations within a single image, whether it is to support multiple platforms, or to allow a single architecture to pick the best alternative given a set of initial conditions. M. -- Reality is an implementation detail. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Mon, 2011-04-04 at 22:08 +0200, Linus Walleij wrote: 2011/4/4 Marc Zyngier marc.zyng...@arm.com: On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote: If ARM are going to architect a set of timers into the hardware, let's make sure that all such hardware has them so we can dig ourselves out of this crappy mess that we find ourselves in today. As far as I know, A15 always has a set of generic timers. It may be that they are not available (frequency not programmed into the CNTFREQ register), or that someone decided to use a better alternative (for some particular interpretation of better). I guess this thing is inside that A15 core? First, what happens the day any vendors start making SoCs on this is they turn the A15 core off whenever it is not used, loosing all state including this timer, I believe. The main counter is located in an ALWAYS_ON power domain, and should keep going whatever happens in the system. [...] Second, have you taken into account the effect of changing the frequency of the A15 core, which is something every vendor also does, as you know Colin Cross already has a patch pending for that on the TWD localtimer which has not yet reached the kernel. (Or is A15 fixed frequency? Forgive my ignorance...) Fixed frequency, with a minimal roll-over time of 40 years. M. -- Reality is an implementation detail. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/12] ARM: omap4: use remapped PPI interrupts for local timer
On Fri, 2011-04-29 at 12:54 +0530, Santosh Shilimkar wrote: Hi Santosh, On 4/21/2011 12:38 AM, Marc Zyngier wrote: Use the normal interrupt scheme for the local timers by using a remapped PPI interrupt. Tested on a Pandaboard. Cc: Tony Lindgrent...@atomide.com Cc: Santosh Shilimkarsantosh.shilim...@ti.com Signed-off-by: Marc Zyngiermarc.zyng...@arm.com --- Have reviewed and tested your series along with OMAP changes. It boots fine on OMAP4430 SDP. # cat /proc/interrupts CPU0 CPU1 . 410: 3678 0 GIC-PPI local_timer 413: 0 1042 GIC-PPI local_timer . LOC: 0 0 Local timer interrupts . Though above output would be bit miss leading, this series removes the duplicate code from platforms and consolidate it at one place. The LOC line is gone in the next iteration of the patch serie. FWIW, you can add my Reviewedd-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks for testing. M. -- Reality is an implementation detail. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On 18/01/12 14:11, Russell King - ARM Linux wrote: On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote: On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: Convert counter_32k clocksource driver to standard platform_driver and move it drivers/clocksource/ directory. Also, rename it to more generic name omap-32k.c. NAK. sched_clock is supposed to be available early. Platform device driver initialization is FAR too late. Russell, Sched_clock is available very early during boot sequence. Initially gp-timer (dmtimer) will get registered as a clocksource. Please refer to the file mach-omap2/timer.c 32k_sync timer (omap-32k.c) will come get registered during arch_init. Just FYI, the way I tested it is, I used kernel parameter clocksourse=counter-32k, the switch from gp-timer to 32k timer will happen once it gets registered. So please delete the sched_clock code from the 32k timer stuff you've moved to a platform driver. It will cause sched_clock to reset to zero, and that's bad news. Only one sched_clock() should ever be registered, and that should only be registered very early at boot time. The kernel will WARN if two sched_clock() are registered. I hope this will be enough for people not to persist with such a thing... M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On 18/01/12 14:38, Hiremath, Vaibhav wrote:
On Wed, Jan 18, 2012 at 19:55:51, Marc Zyngier wrote:
On 18/01/12 14:11, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote:
On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote:
On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote:
Convert counter_32k clocksource driver to standard platform_driver
and move it drivers/clocksource/ directory.
Also, rename it to more generic name omap-32k.c.
NAK. sched_clock is supposed to be available early. Platform device
driver initialization is FAR too late.
Russell,
Sched_clock is available very early during boot sequence. Initially
gp-timer
(dmtimer) will get registered as a clocksource. Please refer to the file
mach-omap2/timer.c
32k_sync timer (omap-32k.c) will come get registered during arch_init.
Just FYI, the way I tested it is, I used kernel parameter
clocksourse=counter-32k, the switch from gp-timer to 32k timer
will happen once it gets registered.
So please delete the sched_clock code from the 32k timer stuff you've
moved to a platform driver. It will cause sched_clock to reset to zero,
and that's bad news.
Only one sched_clock() should ever be registered, and that should only be
registered very early at boot time.
The kernel will WARN if two sched_clock() are registered. I hope this
will be enough for people not to persist with such a thing...
Marc,
This code-snippet is not registering multiple sched_clock() functions,
Here we have 2 timers
- gp-timer (available on all devices)
- 32k-sync timer (may not available on all devices, like AM33xx)
So we are registering both the timers as a clocksource and kernel
Chooses one based on kernel-parameter or rating.
From sched_clock perspective, we have only one function exported in
mach-omap2/timer.c, which in-turn calls omap-32k.c timer api.
Something like this,
unsigned long long notrace sched_clock(void)
{
U32 cyc;
/* First call 32k-sync timer sched_clock() */
/* return 0 means, the device doesn't have 32k-sync timer available */
cyc = sched_clock_32k();
if (cyc)
return cyc;
/* Fall back to gp-timer approach */
}
So there is and will not be any warning from kernel here.
Can't you instead use the ARM sched_clock framework? Please have a look
at what's currently in mainline (we basically register a read() function
with the sched_clock framework).
A per-platform sched_clock() is a step backward for the single zImage
work, and I really want to avoid this.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SMP local timers and their CPUfreq notifiers setup on OMAP3
Hi Santosh,
On Fri, 17 Feb 2012 13:18:37 +0530, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
From 3a16f7a6694c14e201fdf6ad195c821816b2de84 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 17 Feb 2012 11:11:28 +0530
Subject: [PATCH] ARM: smp_twd: Don't register CPUFREQ notifiers if local
timers are not initialised.
Current ARM local timer code registers CPUFREQ notifiers even in case
the twd_timer_setup() isn't called. That seems to be wrong and
would eventually lead to kernel crash on the CPU frequency transitions
on the SOCs where the local timer doesn't exist or broken because of
hardware BUG.
Fix it by uisng an initialised variable. Though the twd_timer_setup()
is percpu, the idea here is to avoid the CPUFREQ registration. Hence
percpu initialised variable is not used.
The issue was observed with v3.3-rc3 and building an OMAP2+ kernel
on OMAP3 SOC which doesn't have TWD.
Below is the dump for reference :
Unable to handle kernel paging request at virtual address 007e900
pgd = cdc2
[007e9000] *pgd=
Internal error: Oops: 5 [#1] SMP
Modules linked in:
CPU: 0Not tainted (3.3.0-rc3-pm+debug+initramfs #9)
PC is at twd_update_frequency+0x34/0x48
LR is at twd_update_frequency+0x10/0x48
pc : [c001382c]lr : [c0013808]psr: 6093
sp : ce311dd8 ip : fp :
r10: r9 : 0001 r8 : ce31
r7 : c0440458 r6 : c00137f8 r5 : r4 : c0947a74
r3 : r2 : 007e9000 r1 : r0 :
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment usr
Control: 10c5387d Table: 8dc20019 DAC: 0015
Process sh (pid: 599, stack limit = 0xce3102f8)
Stack: (0xce311dd8 to 0xce312000)
1dc0: 6000c
1de0: 0001 0002 0
1e00: c093d8f0 ce311ebc 0001 0001 ce310
1e20: c001386c c0437c4c c0e95b60 c0e95ba8 0001 c0e95bf8 4
1e40: c005ef74 ce31 c0435cf0 ce311ebc 0
1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 0
1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 8
1ea0: c08ba040 c033364c ce311ecc c0433b50 0002 ffea c0330
1ec0: 0007a120 0007a120 2201 ce357
1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 0002 c032f47c 00034
1f00: c0331cac ce352b40 0007 c032f6d0 ce352bbc 0003d090 c0930
1f20: c093d8bc c03306a4 0007 ce311f80 0007 cdc2aec0 ce358
1f40: ce8d20c0 0007 b6fe5000 ce311f80 0007 ce31 c
1f60: c000de74 ce987400 ce8d20c0 b6fe5000 c
1f80: 001fbac8 0007 001fbac8 4
1fa0: c000df04 c000dd60 0007 001fbac8 0001 b6fe5000 0
1fc0: 0007 001fbac8 0007 0004 b6fe5000 00202
1fe0: beb565f8 00101ffc 8e8c 6010 0001 0
[c001382c] (twd_update_frequency+0x34/0x48) from [c008ac4c] )
[c008ac4c] (smp_call_function_single+0x17c/0x1c8) from [c0013)
[c0013890] (twd_cpufreq_transition+0x24/0x30) from [c0437c4c)
[c0437c4c] (notifier_call_chain+0x44/0x84) from [c005efe4] ()
[c005efe4] (__srcu_notifier_call_chain+0x70/0xa4) from [c005f)
[c005f030] (srcu_notifier_call_chain+0x18/0x20) from [c032fe2)
[c032fe2c] (cpufreq_notify_transition+0xc8/0x1b0) from [c0333)
[c033364c] (omap_target+0x1b4/0x28c) from [c032f47c] (__cpuf)
[c032f47c] (__cpufreq_driver_target+0x50/0x64) from [c0331d24)
[c0331d24] (cpufreq_set+0x78/0x98) from [c032f6d0] (store_sc)
[c032f6d0] (store_scaling_setspeed+0x5c/0x74) from [c03306a4)
[c03306a4] (store+0x58/0x74) from [c014d868] (sysfs_write_fi)
[c014d868] (sysfs_write_file+0x80/0xb4) from [c00f2c2c] (vfs)
[c00f2c2c] (vfs_write+0xa8/0x138) from [c00f2e9c] (sys_write)
[c00f2e9c] (sys_write+0x40/0x6c) from [c000dd60] (ret_fast_s)
Code: e594300c e792210c e1a01000 e5840004 (e7930002)
---[ end trace 5da3b5167c1ecdda ]---
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/kernel/smp_twd.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 4285daa..753ae37 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -30,6 +30,7 @@ void __iomem *twd_base;
static struct clk *twd_clk;
static unsigned long twd_timer_rate;
+static bool twd_initialised;
static struct clock_event_device __percpu **twd_evt;
@@ -129,7 +130,7 @@ static struct notifier_block twd_cpufreq_nb = {
static int twd_cpufreq_init(void)
{
- if (!IS_ERR(twd_clk))
+ if ((!IS_ERR(twd_clk)) twd_initialised)
return cpufreq_register_notifier(twd_cpufreq_nb,
CPUFREQ_TRANSITION_NOTIFIER);
Testing twd_evt and *__this_cpu_ptr(twd_evt) should have a
Re: SMP local timers and their CPUfreq notifiers setup on OMAP3
On 17/02/12 10:40, Shilimkar, Santosh wrote:
On Fri, Feb 17, 2012 at 3:17 PM, Marc Zyngier marc.zyng...@arm.com wrote:
Hi Santosh,
On Fri, 17 Feb 2012 13:18:37 +0530, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[...]
arch/arm/kernel/smp_twd.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 4285daa..753ae37 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -30,6 +30,7 @@ void __iomem *twd_base;
static struct clk *twd_clk;
static unsigned long twd_timer_rate;
+static bool twd_initialised;
static struct clock_event_device __percpu **twd_evt;
@@ -129,7 +130,7 @@ static struct notifier_block twd_cpufreq_nb = {
static int twd_cpufreq_init(void)
{
- if (!IS_ERR(twd_clk))
+ if ((!IS_ERR(twd_clk)) twd_initialised)
return cpufreq_register_notifier(twd_cpufreq_nb,
CPUFREQ_TRANSITION_NOTIFIER);
Testing twd_evt and *__this_cpu_ptr(twd_evt) should have a similar effect,
and save the additional variable.
Indeed.
Updated patch below.
From 4d351f59e5dabe065d51304455ee01b191cb56d6 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 17 Feb 2012 11:11:28 +0530
Subject: [PATCH] ARM: smp_twd: Don't register CPUFREQ notifiers if
local timers are not initialised.
Current ARM local timer code registers CPUFREQ notifiers even in case
the twd_timer_setup() isn't called. That seems to be wrong and
would eventually lead to kernel crash on the CPU frequency transitions
on the SOCs where the local timer doesn't exist or broken because of
hardware BUG. Fix it by testing twd_evt and *__this_cpu_ptr(twd_evt).
The issue was observed with v3.3-rc3 and building an OMAP2+ kernel
on OMAP3 SOC which doesn't have TWD.
Below is the dump for reference :
Unable to handle kernel paging request at virtual address 007e900
pgd = cdc2
[007e9000] *pgd=
Internal error: Oops: 5 [#1] SMP
Modules linked in:
CPU: 0Not tainted (3.3.0-rc3-pm+debug+initramfs #9)
PC is at twd_update_frequency+0x34/0x48
LR is at twd_update_frequency+0x10/0x48
pc : [c001382c]lr : [c0013808]psr: 6093
sp : ce311dd8 ip : fp :
r10: r9 : 0001 r8 : ce31
r7 : c0440458 r6 : c00137f8 r5 : r4 : c0947a74
r3 : r2 : 007e9000 r1 : r0 :
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment usr
Control: 10c5387d Table: 8dc20019 DAC: 0015
Process sh (pid: 599, stack limit = 0xce3102f8)
Stack: (0xce311dd8 to 0xce312000)
1dc0: 6000c
1de0: 0001 0002 0
1e00: c093d8f0 ce311ebc 0001 0001 ce310
1e20: c001386c c0437c4c c0e95b60 c0e95ba8 0001 c0e95bf8 4
1e40: c005ef74 ce31 c0435cf0 ce311ebc 0
1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 0
1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 8
1ea0: c08ba040 c033364c ce311ecc c0433b50 0002 ffea c0330
1ec0: 0007a120 0007a120 2201 ce357
1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 0002 c032f47c 00034
1f00: c0331cac ce352b40 0007 c032f6d0 ce352bbc 0003d090 c0930
1f20: c093d8bc c03306a4 0007 ce311f80 0007 cdc2aec0 ce358
1f40: ce8d20c0 0007 b6fe5000 ce311f80 0007 ce31 c
1f60: c000de74 ce987400 ce8d20c0 b6fe5000 c
1f80: 001fbac8 0007 001fbac8 4
1fa0: c000df04 c000dd60 0007 001fbac8 0001 b6fe5000 0
1fc0: 0007 001fbac8 0007 0004 b6fe5000 00202
1fe0: beb565f8 00101ffc 8e8c 6010 0001 0
[c001382c] (twd_update_frequency+0x34/0x48) from [c008ac4c] )
[c008ac4c] (smp_call_function_single+0x17c/0x1c8) from [c0013)
[c0013890] (twd_cpufreq_transition+0x24/0x30) from [c0437c4c)
[c0437c4c] (notifier_call_chain+0x44/0x84) from [c005efe4] ()
[c005efe4] (__srcu_notifier_call_chain+0x70/0xa4) from [c005f)
[c005f030] (srcu_notifier_call_chain+0x18/0x20) from [c032fe2)
[c032fe2c] (cpufreq_notify_transition+0xc8/0x1b0) from [c0333)
[c033364c] (omap_target+0x1b4/0x28c) from [c032f47c] (__cpuf)
[c032f47c] (__cpufreq_driver_target+0x50/0x64) from [c0331d24)
[c0331d24] (cpufreq_set+0x78/0x98) from [c032f6d0] (store_sc)
[c032f6d0] (store_scaling_setspeed+0x5c/0x74) from [c03306a4)
[c03306a4] (store+0x58/0x74) from [c014d868] (sysfs_write_fi)
[c014d868] (sysfs_write_file+0x80/0xb4) from [c00f2c2c] (vfs)
[c00f2c2c] (vfs_write+0xa8/0x138) from [c00f2e9c] (sys_write)
[c00f2e9c] (sys_write+0x40/0x6c) from [c000dd60] (ret_fast_s)
Code: e594300c e792210c e1a01000 e5840004 (e7930002)
---[ end trace 5da3b5167c1ecdda ]---
Reported-by: Kevin
Re: SMP local timers and their CPUfreq notifiers setup on OMAP3
On 17/02/12 12:28, Santosh Shilimkar wrote:
On Friday 17 February 2012 04:36 PM, Marc Zyngier wrote:
On 17/02/12 10:40, Shilimkar, Santosh wrote:
On Fri, Feb 17, 2012 at 3:17 PM, Marc Zyngier marc.zyng...@arm.com wrote:
Hi Santosh,
On Fri, 17 Feb 2012 13:18:37 +0530, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[..]
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 4285daa..265a18a 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -129,7 +129,7 @@ static struct notifier_block twd_cpufreq_nb = {
static int twd_cpufreq_init(void)
{
- if (!IS_ERR(twd_clk))
+ if ((!twd_evt) (!__this_cpu_ptr(twd_evt)) (!IS_ERR(twd_clk)))
Erm... Shouldn't that rather be:
if (twd_evt *__this_cpu_ptr(twd_evt) !IS_ERR(twd_clk))
My bad. You are right. Updated patch below.
Tested on OMAP3430 SDP with CPUFREQ enabled.
Regards
Santosh
From f58c515a9d1a2c729c05a726d5176843381952ae Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 17 Feb 2012 11:11:28 +0530
Subject: [PATCH] ARM: smp_twd: Don't register CPUFREQ notifiers if local
timers are not initialised.
Current ARM local timer code registers CPUFREQ notifiers even in case
the twd_timer_setup() isn't called. That seems to be wrong and
would eventually lead to kernel crash on the CPU frequency transitions
on the SOCs where the local timer doesn't exist or broken because of
hardware BUG. Fix it by testing twd_evt and *__this_cpu_ptr(twd_evt).
The issue was observed with v3.3-rc3 and building an OMAP2+ kernel
on OMAP3 SOC which doesn't have TWD.
Below is the dump for reference :
Unable to handle kernel paging request at virtual address 007e900
pgd = cdc2
[007e9000] *pgd=
Internal error: Oops: 5 [#1] SMP
Modules linked in:
CPU: 0Not tainted (3.3.0-rc3-pm+debug+initramfs #9)
PC is at twd_update_frequency+0x34/0x48
LR is at twd_update_frequency+0x10/0x48
pc : [c001382c]lr : [c0013808]psr: 6093
sp : ce311dd8 ip : fp :
r10: r9 : 0001 r8 : ce31
r7 : c0440458 r6 : c00137f8 r5 : r4 : c0947a74
r3 : r2 : 007e9000 r1 : r0 :
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment usr
Control: 10c5387d Table: 8dc20019 DAC: 0015
Process sh (pid: 599, stack limit = 0xce3102f8)
Stack: (0xce311dd8 to 0xce312000)
1dc0: 6000c
1de0: 0001 0002 0
1e00: c093d8f0 ce311ebc 0001 0001 ce310
1e20: c001386c c0437c4c c0e95b60 c0e95ba8 0001 c0e95bf8 4
1e40: c005ef74 ce31 c0435cf0 ce311ebc 0
1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 0
1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 8
1ea0: c08ba040 c033364c ce311ecc c0433b50 0002 ffea c0330
1ec0: 0007a120 0007a120 2201 ce357
1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 0002 c032f47c 00034
1f00: c0331cac ce352b40 0007 c032f6d0 ce352bbc 0003d090 c0930
1f20: c093d8bc c03306a4 0007 ce311f80 0007 cdc2aec0 ce358
1f40: ce8d20c0 0007 b6fe5000 ce311f80 0007 ce31 c
1f60: c000de74 ce987400 ce8d20c0 b6fe5000 c
1f80: 001fbac8 0007 001fbac8 4
1fa0: c000df04 c000dd60 0007 001fbac8 0001 b6fe5000 0
1fc0: 0007 001fbac8 0007 0004 b6fe5000 00202
1fe0: beb565f8 00101ffc 8e8c 6010 0001 0
[c001382c] (twd_update_frequency+0x34/0x48) from [c008ac4c] )
[c008ac4c] (smp_call_function_single+0x17c/0x1c8) from [c0013)
[c0013890] (twd_cpufreq_transition+0x24/0x30) from [c0437c4c)
[c0437c4c] (notifier_call_chain+0x44/0x84) from [c005efe4] ()
[c005efe4] (__srcu_notifier_call_chain+0x70/0xa4) from [c005f)
[c005f030] (srcu_notifier_call_chain+0x18/0x20) from [c032fe2)
[c032fe2c] (cpufreq_notify_transition+0xc8/0x1b0) from [c0333)
[c033364c] (omap_target+0x1b4/0x28c) from [c032f47c] (__cpuf)
[c032f47c] (__cpufreq_driver_target+0x50/0x64) from [c0331d24)
[c0331d24] (cpufreq_set+0x78/0x98) from [c032f6d0] (store_sc)
[c032f6d0] (store_scaling_setspeed+0x5c/0x74) from [c03306a4)
[c03306a4] (store+0x58/0x74) from [c014d868] (sysfs_write_fi)
[c014d868] (sysfs_write_file+0x80/0xb4) from [c00f2c2c] (vfs)
[c00f2c2c] (vfs_write+0xa8/0x138) from [c00f2e9c] (sys_write)
[c00f2e9c] (sys_write+0x40/0x6c) from [c000dd60] (ret_fast_s)
Code: e594300c e792210c e1a01000 e5840004 (e7930002)
---[ end trace 5da3b5167c1ecdda ]---
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/kernel/smp_twd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
Re: [PATCH 5/5] ARM: dts: OMAP5: Specify nonsecure PPI IRQ for arch timer
On 18/01/13 15:32, Santosh Shilimkar wrote:
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
timer. This fixes the following errors seen on DT OMAP5 boot..
[0.00] arch_timer: No interrupt available, giving up
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..7a78d1b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -35,8 +35,12 @@
compatible = arm,cortex-a15;
timer {
compatible = arm,armv7-timer;
- /* 14th PPI IRQ, active low level-sensitive */
- interrupts = 1 14 0x308;
+ /*
+ * PPI secure/nonsecure IRQ,
+ * active low level-sensitive
+ */
+ interrupts = 1 13 0x308,
+ 1 14 0x308;
Care to add the virtual and HYP timer interrupts? So KVM can get a
chance to run on this HW...
clock-frequency = 6144000;
};
};
@@ -44,8 +48,12 @@
compatible = arm,cortex-a15;
timer {
compatible = arm,armv7-timer;
- /* 14th PPI IRQ, active low level-sensitive */
- interrupts = 1 14 0x308;
+ /*
+ * PPI secure/nonsecure IRQ,
+ * active low level-sensitive
+ */
+ interrupts = 1 13 0x308,
+ 1 14 0x308;
Same here.
clock-frequency = 6144000;
};
};
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: OMAP5: Specify nonsecure PPI IRQ for arch timer
On 18/01/13 17:00, Santosh Shilimkar wrote:
On Friday 18 January 2013 09:32 PM, Marc Zyngier wrote:
On 18/01/13 15:32, Santosh Shilimkar wrote:
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
timer. This fixes the following errors seen on DT OMAP5 boot..
[0.00] arch_timer: No interrupt available, giving up
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..7a78d1b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -35,8 +35,12 @@
compatible = arm,cortex-a15;
timer {
compatible = arm,armv7-timer;
- /* 14th PPI IRQ, active low level-sensitive */
- interrupts = 1 14 0x308;
+ /*
+* PPI secure/nonsecure IRQ,
+* active low level-sensitive
+*/
+ interrupts = 1 13 0x308,
+1 14 0x308;
Care to add the virtual and HYP timer interrupts? So KVM can get a
chance to run on this HW...
Thanks Marc for spotting it. Will take care of it.
I just realised something silly... You have one timer node *per cpu*,
and this is not really expected.
The driver really wants one single node. See
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts for an example.
Oh, and your GIC node could do with some updating too (no VGIC regs or
interrupt).
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: OMAP5: Specify nonsecure PPI IRQ for arch timer
On Sat, 19 Jan 2013 00:21:22 +0530, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Friday 18 January 2013 10:38 PM, Marc Zyngier wrote:
On 18/01/13 17:00, Santosh Shilimkar wrote:
On Friday 18 January 2013 09:32 PM, Marc Zyngier wrote:
On 18/01/13 15:32, Santosh Shilimkar wrote:
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
timer. This fixes the following errors seen on DT OMAP5 boot..
[0.00] arch_timer: No interrupt available, giving up
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..7a78d1b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -35,8 +35,12 @@
compatible = arm,cortex-a15;
timer {
compatible = arm,armv7-timer;
- /* 14th PPI IRQ, active low level-sensitive */
- interrupts = 1 14 0x308;
+ /*
+ * PPI secure/nonsecure IRQ,
+ * active low level-sensitive
+ */
+ interrupts = 1 13 0x308,
+ 1 14 0x308;
Care to add the virtual and HYP timer interrupts? So KVM can get a
chance to run on this HW...
Thanks Marc for spotting it. Will take care of it.
I just realised something silly... You have one timer node *per cpu*,
and this is not really expected.
This was discussed on the list here [1]
Benoit suggested to add per CPU node since arch timer is per
CPU and DT should describe the hw the way it is. Did we miss
something ?
The current approach is not to duplicate banked resources. We do not have
duplicated twd-timer nodes on Cortex A9, we do not expose multiple CPU
interfaces for the GIC...
And speaking of the GIC: how do you interpret the CPU mask in the
interrupt field of the timer? The value 0x3xx in the third field is there
to indicate that CPU0 and CPU1 are getting interrupted by the timer. What
does it mean when you duplicate it?
M.
--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 21/03/13 11:06, Mark Rutland wrote: Hi Rob, (adding Marc to Cc as he may have comments). On Wed, Mar 20, 2013 at 10:34:35PM +, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com This converts arm and arm64 to use CLKSRC_OF DT based initialization for the arch timer. A new function arch_timer_arch_init is added to allow for arch specific setup. This has a side effect of enabling sched_clock on omap5 and exynos5. There should not be any reason not to use the arch timers for sched_clock. Nice! I was just about to post a (slightly updated) version of Thomas Abraham's arch_timer clocksource_of_init patch, but this seems much more comprehensive. I have some other arch_timer patches which may clash, but they could be rebased atop of this. Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Russell King li...@arm.linux.org.uk Cc: Kukjin Kim kgene@samsung.com Cc: Tony Lindgren t...@atomide.com Cc: Simon Horman ho...@verge.net.au Cc: Magnus Damm magnus.d...@gmail.com Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com Cc: John Stultz john.stu...@linaro.org Cc: Thomas Gleixner t...@linutronix.de Cc: linux-samsung-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux...@vger.kernel.org --- This is dependent on my CLKSRC_OF clean-up in arm-soc, my 64-bit sched_clock support series, and Arnd's default machine descriptor patch (for default clocksource_of_init call). This is only compile tested on arm. The full series (including sp804 work) is available here: git://sources.calxeda.com/kernel/linux.git arm-timers Rob [...] diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c index d0ad789..6215717 100644 --- a/arch/arm/mach-vexpress/v2m.c +++ b/arch/arm/mach-vexpress/v2m.c @@ -1,6 +1,7 @@ /* * Versatile Express V2M Motherboard Support */ +#include linux/clocksource.h #include linux/device.h #include linux/amba/bus.h #include linux/amba/mmci.h @@ -23,7 +24,6 @@ #include linux/regulator/machine.h #include linux/vexpress.h -#include asm/arch_timer.h #include asm/mach-types.h #include asm/sizes.h #include asm/mach/arch.h @@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void) irq_of_parse_and_map(node, 0)); } - arch_timer_of_register(); - - if (arch_timer_sched_clock_init() != 0) - versatile_sched_clock_init(vexpress_get_24mhz_clock_base(), + versatile_sched_clock_init(vexpress_get_24mhz_clock_base(), 2400); } On TC2 this series leads to using the vexpress 24MHz clock as the sched clock in preference to the architected timer: Architected local timer running at 24.00MHz (virt). Switching to timer-based delay loop Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source As they both have the same frequency, neither overrides the other, and whichever gets registered last is used as the sched_clock. As accesses to the architected timer are going to have a much lower overhead, this isn't very nice (and it could be better to use it even if it had a lower frequency). Indeed. And if I look at it with my KVM hat on, it is even worse (the guest will exit all the way to platform emulation in userspace on each sched_clock read - a sure performance killer). Of course, emulating a VE is not the best option, but that's all we have so far when using QEMU as platform emulation. M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On 2013-08-13 10:46, Mark Rutland wrote:
[Adding Marc to Cc]
On Tue, Aug 13, 2013 at 08:24:31AM +0100, Rajendra Nayak wrote:
[]..
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /*
+* PPI secure/nonsecure IRQ,
+* active low level-sensitive
+*/
+ interrupts = 1 13 0x308,
+1 14 0x308;
+ clock-frequency = 6144000;
+ };
+ };
The cpu nodes should have a reg matching their unit-address, and a
device_type = cpu.
The timer nodes should *not* be under the CPU nodes. They should
be
under under the root node. I realise that it makes intuitive sense
to
describe per-cpu resources this way, but that's not the way the
bindings
are intended to be used (does thei DT even work?).
No virtual/hypervisor interrupts?
Mark, all valid points. I just updated the patch to include all the
missing
interrupts and registers for timer and gic and moved the timer node
out as
its supposed to be.
Great!
Do you really need the clock-frequency property? It's far
preferrable to
have your bootloader do the right thing and program CNTFRQ with
the
correct value.
I kept the clock-frequency property since our bootloader does not
handle this
and I am not sure if its a good idea to have the dependency on
bootloader
to do this.
There is precedent for handling it this way, but it would be far
nicer
to fix the bootloader to set CNTFRQ. For one thing it's only
writeable
from the secure side, so a host os can't fix it up for guests that
might
depend on it rather than dt. I realise it's not necessarily as simple
as
it sounds to fix that up, however.
Indeed, having the wrong CNTFRQ in the host has the unfortunate effect
of propagating the crap into the guests.
While this can be worked around for Linux guests (you have to hack the
DT passed to the guests, which is very unpleasant at best and varies
from one host to another), there is nothing you can do for non-DT
guests.
So please, fix it in your firmware/boot-ROM while it is still time.
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On 2013-08-14 11:25, Rajendra Nayak wrote:
From: R Sricharan r.sricha...@ti.com
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart devices on board.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Benoit, I am reposting the dts files for dra so you can pick it up
for 3.12.
Rest of the core support is already pulled in by Tony.
[...]
diff --git a/arch/arm/boot/dts/dra7.dtsi
b/arch/arm/boot/dts/dra7.dtsi
new file mode 100644
index 000..ad18fb2
--- /dev/null
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -0,0 +1,574 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated -
http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on omap4.dtsi
+ */
+
+#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/pinctrl/dra.h
+
+#include skeleton.dtsi
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+
+ compatible = ti,dra7xx;
+ interrupt-parent = gic;
+
+ aliases {
+ serial0 = uart1;
+ serial1 = uart2;
+ serial2 = uart3;
+ serial3 = uart4;
+ serial4 = uart5;
+ serial5 = uart6;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a15;
+ reg = 0;
+ };
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a15;
+ reg = 1;
+ };
+ };
+
+ timer {
+ compatible = arm,armv7-timer;
+ interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 14 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 11 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 10 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW);
+ };
+
+ gic: interrupt-controller@48211000 {
+ compatible = arm,cortex-a15-gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48211000 0x1000,
+ 0x48212000 0x1000,
+ 0x48214000 0x2000,
+ 0x48216000 0x2000;
If you have the virtualization extensions, where is the maintenance
interrupt?
M.
--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On 30/09/13 14:59, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Isn't this just another chained interrupt controller? How is it GIC specific? M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On 30/09/13 15:22, Santosh Shilimkar wrote: On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote: On 30/09/13 14:59, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Isn't this just another chained interrupt controller? How is it GIC specific? No it isn't a irq controller rather a event router. Patch is missing reference to the previous discussion. Previous discussion is here [1] Regards, Santosh [1] https://lkml.org/lkml/2013/9/13/413 Right. I need to go and understand that bit first. Thanks Santosh. M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs
On 25/11/13 16:28, Santosh Shilimkar wrote: On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote: On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com wrote: Boot-CPU entry into the HYP mode is managed in boot-loader but the secondary CPUs directly jumps to kernel during boot. Same path is also used for CPU hotplug as well during suspend for secondary CPU. Hence patch the secondary CPU boot path for hyp mode etry. Cc: Marc Zyngier marc.zyng...@arm.com Cc: Christoffer Dall christoffer.d...@linaro.org Cc: Tony Lindgren t...@atomide.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 75e9295..4844dd8 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -22,6 +22,7 @@ /* Physical address needed since MMU not enabled yet on secondary core */ #define AUX_CORE_BOOT0_PA 0x48281800 +#define API_HYP_ENTRY 0x102 /* * OMAP5 specific entry point for secondary CPU to jump from ROM @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 and r4, r4, #0x0f cmp r0, r4 bne wait +#ifdef CONFIG_KVM_ARM_HOST + ldr r12, =API_HYP_ENTRY + adr r0, hyp_boot + smc #0 +hyp_boot: +#endif b secondary_startup END(omap5_secondary_startup) /* hmm, this means that currently running this in a guest will fail to bring-up SMP, right? Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build will not enable CONFIG_KVM_ARM_HOST and things should be fine then. Right ? Absolutely not. We're way past the one image per usage model, and I fully expect the same kernel to boot both as a guest and a host. Otherwise, multiplatform is just a joke. Couldn't you create a little wrapper-pen in U-Boot instead, which replicates the omap boot protocol and takes care of the hyp-mode startup there instead, keeping this completely out of the kernel? Its not just booting but CPU hotplug also follows the same path so we need the mechanism in kernel to switch mode. In general, I think its important to consider the aspect with CPU PM. CPUs are not going to go through the boot-loaders in those paths and hence need of HYP entry in the kernel will be must. I definitely agree that you need to consider PM as well. But we've decided a long time ago that we wouldn't take that kind of code in the kernel. Your CPU has to reach the kernel in HYP, and that is down to your boot protocol to take care off that. There are a few options. Christoffer mentioned having a pen, and you also could implement PSCI fairly easily (I've recently posted a u-boot patch series to take care of this, though there is still a fair bit of work required). Whatever the approach is, the bottom line remains: your CPU enters the kernel in HYP. Cheers, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
All the Cortex-{A7,A15} implementations are using a GICv2. Same for
the current arm64 platforms.
Turns out that most of these platforms have described their GIC CPU
interface size as being 4kB. while it is actually 8kB (the GICC_DIR
register lives at offset 0x1000).
This was found when converting the GIC driver to use EOImode==1 on
GICv2-based systems. It uses the GICC_DIR register, and the result
is a very early firework...
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos5410.dtsi | 2 +-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
arch/arm/boot/dts/omap5.dtsi| 2 +-
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/sun6i-a31.dtsi| 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi| 2 +-
arch/arm/boot/dts/tegra114.dtsi | 2 +-
arch/arm/boot/dts/tegra124.dtsi | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm64/boot/dts/apm-storm.dtsi | 2 +-
arch/arm64/boot/dts/foundation-v8.dts | 2 +-
arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
21 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/axm55xx.dtsi b/arch/arm/boot/dts/axm55xx.dtsi
index ea288f0..40aacc9 100644
--- a/arch/arm/boot/dts/axm55xx.dtsi
+++ b/arch/arm/boot/dts/axm55xx.dtsi
@@ -62,7 +62,7 @@
#address-cells = 0;
interrupt-controller;
reg = 0x20 0x01001000 0 0x1000,
- 0x20 0x01002000 0 0x1000,
+ 0x20 0x01002000 0 0x2000,
0x20 0x01004000 0 0x2000,
0x20 0x01006000 0 0x2000;
interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) |
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c29945e..65329ff 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -46,7 +46,7 @@
interrupt-controller;
#interrupt-cells = 3;
reg = 0x48211000 0x1000,
- 0x48212000 0x1000,
+ 0x48212000 0x2000,
0x48214000 0x2000,
0x48216000 0x2000;
interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_HIGH);
diff --git a/arch/arm/boot/dts/ecx-2000.dts b/arch/arm/boot/dts/ecx-2000.dts
index 2ccbb57f..c15e7e0 100644
--- a/arch/arm/boot/dts/ecx-2000.dts
+++ b/arch/arm/boot/dts/ecx-2000.dts
@@ -99,7 +99,7 @@
interrupt-controller;
interrupts = 1 9 0xf04;
reg = 0xfff11000 0x1000,
- 0xfff12000 0x1000,
+ 0xfff12000 0x2000,
0xfff14000 0x2000,
0xfff16000 0x2000;
};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 3e678fa..bbd177a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -173,7 +173,7 @@
#interrupt-cells = 3;
interrupt-controller;
reg = 0x10481000 0x1000,
- 0x10482000 0x1000,
+ 0x10482000 0x2000,
0x10484000 0x2000,
0x10486000 0x2000;
interrupts = 1 9 0xf04;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608..15fdc3b 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -44,7 +44,7 @@
#interrupt-cells = 3;
interrupt-controller;
reg = 0x10481000 0x1000,
- 0x10482000 0x1000,
+ 0x10482000 0x2000,
0x10484000 0x2000,
0x10486000 0x2000;
interrupts = 1 9 0xf04;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index 5398a60..c0e2341 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -161,7 +161,7 @@
#size-cells = 0;
interrupt-controller;
reg = 0x10481000 0x1000,
- 0x10482000 0x1000,
+ 0x10482000 0x2000,
0x10484000 0x2000,
0x10486000
Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size
On Wed, Jun 25 2014 at 01:21:17 PM, Rob Herring robherri...@gmail.com wrote:
On Wed, Jun 25, 2014 at 5:37 AM, Marc Zyngier marc.zyng...@arm.com wrote:
All the Cortex-{A7,A15} implementations are using a GICv2. Same for
the current arm64 platforms.
Turns out that most of these platforms have described their GIC CPU
interface size as being 4kB. while it is actually 8kB (the GICC_DIR
register lives at offset 0x1000).
This was found when converting the GIC driver to use EOImode==1 on
GICv2-based systems. It uses the GICC_DIR register, and the result
is a very early firework...
What's your plan for making the kernel change? Updating the dts files
is good, but that doesn't immediately help you if you have old dtbs.
See at the end of https://lkml.org/lkml/2014/6/25/243
Basically, we stay with a GICv1 behaviour if we detect the mess.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
Acked-by: Rob Herring r...@kernel.org
Thanks,
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this context may be
illegal (specially if coming from the idle state, where RCU would be
in a quiescent state).
A possible fix would be to wrap calls to irq_find_mapping into a
RCU_NONIDLE macro, but that really looks ugly.
This patch series introduce another generic IRQ entry point
(handle_domain_irq), which has the exact same behaviour as handle_IRQ
(as defined on arm, arm64 and openrisc), except that it also takes a
irq_domain pointer. This allows the logical IRQ lookup to be done
inside the irq_{enter,exit} section, which contains a
rcu_irq_{enter,exit}, making it safe.
A number of irqchips are then converted to this new entry point. I've
converted all the direct users of irq_find_mapping, except for the
cases where it was used as a chained handler (chained_irq_{enter,exit}
makes it safe). Users of irq_linear_revmap are safe as well. I've
given it some light testing on arm64.
The series is also available in my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
handle_domain_irq
From v1 [1]:
- Made handle_domain_irq a generic function
- Added OpenRISC to the list of affected architectures
- Converted more interrupt controllers
- Rebased on v3.17-rc1
[1]: https://lkml.org/lkml/2014/7/8/381
Marc Zyngier (26):
genirq: add irq_domain-aware core IRQ handler
arm64: convert handle_IRQ to use __handle_domain_irq
ARM: convert handle_IRQ to use __handle_domain_irq
openrisc: convert handle_IRQ to use __handle_domain_irq
irqchip: GIC: convert to handle_domain_irq
irqchip: armada-370-xp: convert to handle_domain_irq
irqchip: clps711x: convert to handle_domain_irq
irqchip: mmp: convert to handle_domain_irq
irqchip: mxs: convert to handle_domain_irq
irqchip: orion: convert to handle_domain_irq
irqchip: s3c24xx: convert to handle_domain_irq
irqchip: sirfsoc: convert to handle_domain_irq
irqchip: sun4i: convert to handle_domain_irq
irqchip: versatile-fpga: convert to handle_domain_irq
irqchip: vic: convert to handle_domain_irq
irqchip: vt8500: convert to handle_domain_irq
irqchip: zevio: convert to handle_domain_irq
irqchip: GICv3: convert to handle_domain_irq
irqchip: atmel-aic: convert to handle_domain_irq
irqchip: atmel-aic5: convert to handle_domain_irq
irqchip: or1k-pic: convert to handle_domain_irq
ARM: imx: avic: convert to handle_domain_irq
ARM: imx: tzic: convert to handle_domain_irq
ARM: omap2: irq: convert to handle_domain_irq
arm64: get rid of handle_IRQ
openrisc: get rid of handle_IRQ
arch/arm/Kconfig | 1 +
arch/arm/kernel/irq.c| 19 +---
arch/arm/mach-imx/avic.c | 2 +-
arch/arm/mach-imx/tzic.c | 3 +--
arch/arm/mach-omap2/irq.c| 3 +--
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/hardirq.h | 2 --
arch/arm64/kernel/irq.c | 27 ---
arch/openrisc/Kconfig| 1 +
arch/openrisc/include/asm/irq.h | 1 -
arch/openrisc/kernel/irq.c | 12 ---
drivers/irqchip/irq-armada-370-xp.c | 19
drivers/irqchip/irq-atmel-aic.c | 4 +---
drivers/irqchip/irq-atmel-aic5.c | 4 +---
drivers/irqchip/irq-clps711x.c | 18 ++--
drivers/irqchip/irq-gic-v3.c | 13 ++-
drivers/irqchip/irq-gic.c| 3 +--
drivers/irqchip/irq-mmp.c| 10 -
drivers/irqchip/irq-mxs.c| 3 +--
drivers/irqchip/irq-or1k-pic.c | 4 ++--
drivers/irqchip/irq-orion.c | 5 ++---
drivers/irqchip/irq-s3c24xx.c| 4 +---
drivers/irqchip/irq-sirfsoc.c| 6 ++
drivers/irqchip/irq-sun4i.c | 5 ++---
drivers/irqchip/irq-versatile-fpga.c | 2 +-
drivers/irqchip/irq-vic.c| 2 +-
drivers/irqchip/irq-vt8500.c | 5 ++---
drivers/irqchip/irq-zevio.c | 3 +--
include/linux/irqdesc.h | 19
kernel/irq/Kconfig | 3 +++
kernel/irq/irqdesc.c | 42
31 files changed, 116 insertions(+), 130 deletions(-)
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/26] ARM: convert handle_IRQ to use __handle_domain_irq
In order to limit code duplication, convert the architecture specific
handle_IRQ to use the generic __handle_domain_irq function.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/Kconfig | 1 +
arch/arm/kernel/irq.c | 19 +--
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c49a775..5918d40 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -24,6 +24,7 @@ config ARM
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
+ select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL if (AEABI !OABI_COMPAT)
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 2c42576..0509d07 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -65,24 +65,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
*/
void handle_IRQ(unsigned int irq, struct pt_regs *regs)
{
- struct pt_regs *old_regs = set_irq_regs(regs);
-
- irq_enter();
-
- /*
-* Some hardware gives randomly wrong interrupts. Rather
-* than crashing, do something sensible.
-*/
- if (unlikely(irq = nr_irqs)) {
- if (printk_ratelimit())
- printk(KERN_WARNING Bad IRQ%u\n, irq);
- ack_bad_irq(irq);
- } else {
- generic_handle_irq(irq);
- }
-
- irq_exit();
- set_irq_regs(old_regs);
+ __handle_domain_irq(NULL, irq, false, regs);
}
/*
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 13/26] irqchip: sun4i: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-sun4i.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index 6fcef4a..64155b6 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -136,7 +136,7 @@ IRQCHIP_DECLARE(allwinner_sun4i_ic,
allwinner,sun4i-a10-ic, sun4i_of_init);
static void __exception_irq_entry sun4i_handle_irq(struct pt_regs *regs)
{
- u32 irq, hwirq;
+ u32 hwirq;
/*
* hwirq == 0 can mean one of 3 things:
@@ -154,8 +154,7 @@ static void __exception_irq_entry sun4i_handle_irq(struct
pt_regs *regs)
return;
do {
- irq = irq_find_mapping(sun4i_irq_domain, hwirq);
- handle_IRQ(irq, regs);
+ handle_domain_irq(sun4i_irq_domain, hwirq, regs);
hwirq = readl(sun4i_irq_base + SUN4I_IRQ_VECTOR_REG) 2;
} while (hwirq != 0);
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 26/26] openrisc: get rid of handle_IRQ
The openrisc irqchip driver has been converted to handle_domain_irq,
making it possible to remove the handle_IRQ stub entierely.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/openrisc/include/asm/irq.h | 1 -
arch/openrisc/kernel/irq.c | 5 -
2 files changed, 6 deletions(-)
diff --git a/arch/openrisc/include/asm/irq.h b/arch/openrisc/include/asm/irq.h
index b84634c..d9eee0a 100644
--- a/arch/openrisc/include/asm/irq.h
+++ b/arch/openrisc/include/asm/irq.h
@@ -24,7 +24,6 @@
#define NO_IRQ (-1)
-void handle_IRQ(unsigned int, struct pt_regs *);
extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
#endif /* __ASM_OPENRISC_IRQ_H__ */
diff --git a/arch/openrisc/kernel/irq.c b/arch/openrisc/kernel/irq.c
index e9aaf28..35e478a 100644
--- a/arch/openrisc/kernel/irq.c
+++ b/arch/openrisc/kernel/irq.c
@@ -48,11 +48,6 @@ void __init set_handle_irq(void (*handle_irq)(struct pt_regs
*))
handle_arch_irq = handle_irq;
}
-void handle_IRQ(unsigned int irq, struct pt_regs *regs)
-{
- __handle_domain_irq(NULL, irq, false, regs);
-}
-
void __irq_entry do_IRQ(struct pt_regs *regs)
{
handle_arch_irq(regs);
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 25/26] arm64: get rid of handle_IRQ
All the arm64 irqchip drivers have been converted to handle_domain_irq,
making it possible to remove the handle_IRQ stub entierely.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm64/include/asm/hardirq.h | 2 --
arch/arm64/kernel/irq.c | 11 ---
2 files changed, 13 deletions(-)
diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
index 0be6782..e8a3268 100644
--- a/arch/arm64/include/asm/hardirq.h
+++ b/arch/arm64/include/asm/hardirq.h
@@ -47,8 +47,6 @@ static inline void ack_bad_irq(unsigned int irq)
irq_err_count++;
}
-extern void handle_IRQ(unsigned int, struct pt_regs *);
-
/*
* No arch-specific IRQ flags.
*/
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 2c0e2a7..67ca197 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -40,17 +40,6 @@ int arch_show_interrupts(struct seq_file *p, int prec)
return 0;
}
-/*
- * handle_IRQ handles all hardware IRQ's. Decoded IRQs should
- * not come via this function. Instead, they should provide their
- * own 'handler'. Used by platform code implementing C-based 1st
- * level decoding.
- */
-void handle_IRQ(unsigned int irq, struct pt_regs *regs)
-{
- __handle_domain_irq(NULL, irq, false, regs);
-}
-
void __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
{
if (handle_arch_irq)
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 21/26] irqchip: or1k-pic: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- drivers/irqchip/irq-or1k-pic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-or1k-pic.c b/drivers/irqchip/irq-or1k-pic.c index 17ff033..e93d079 100644 --- a/drivers/irqchip/irq-or1k-pic.c +++ b/drivers/irqchip/irq-or1k-pic.c @@ -113,7 +113,7 @@ static inline int pic_get_irq(int first) else hwirq = hwirq + first - 1; - return irq_find_mapping(root_domain, hwirq); + return hwirq; } static void or1k_pic_handle_irq(struct pt_regs *regs) @@ -121,7 +121,7 @@ static void or1k_pic_handle_irq(struct pt_regs *regs) int irq = -1; while ((irq = pic_get_irq(irq + 1)) != NO_IRQ) - handle_IRQ(irq, regs); + handle_domain_irq(root_domain, irq, regs); } static int or1k_map(struct irq_domain *d, unsigned int irq, irq_hw_number_t hw) -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 19/26] irqchip: atmel-aic: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- drivers/irqchip/irq-atmel-aic.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/irqchip/irq-atmel-aic.c b/drivers/irqchip/irq-atmel-aic.c index a82869e..9a2cf3c 100644 --- a/drivers/irqchip/irq-atmel-aic.c +++ b/drivers/irqchip/irq-atmel-aic.c @@ -68,12 +68,10 @@ aic_handle(struct pt_regs *regs) irqnr = irq_reg_readl(gc-reg_base + AT91_AIC_IVR); irqstat = irq_reg_readl(gc-reg_base + AT91_AIC_ISR); - irqnr = irq_find_mapping(aic_domain, irqnr); - if (!irqstat) irq_reg_writel(0, gc-reg_base + AT91_AIC_EOICR); else - handle_IRQ(irqnr, regs); + handle_domain_irq(aic_domain, irqnr, regs); } static int aic_retrigger(struct irq_data *d) -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 22/26] ARM: imx: avic: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- arch/arm/mach-imx/avic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/avic.c b/arch/arm/mach-imx/avic.c index 24b103c..1a89323 100644 --- a/arch/arm/mach-imx/avic.c +++ b/arch/arm/mach-imx/avic.c @@ -144,7 +144,7 @@ static void __exception_irq_entry avic_handle_irq(struct pt_regs *regs) if (nivector == 0x) break; - handle_IRQ(irq_find_mapping(domain, nivector), regs); + handle_domain_irq(domain, nivector, regs); } while (1); } -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 23/26] ARM: imx: tzic: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-imx/tzic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/tzic.c b/arch/arm/mach-imx/tzic.c
index 1d4f384..4de65ee 100644
--- a/arch/arm/mach-imx/tzic.c
+++ b/arch/arm/mach-imx/tzic.c
@@ -141,8 +141,7 @@ static void __exception_irq_entry tzic_handle_irq(struct
pt_regs *regs)
while (stat) {
handled = 1;
irqofs = fls(stat) - 1;
- handle_IRQ(irq_find_mapping(domain,
- irqofs + i * 32), regs);
+ handle_domain_irq(domain, irqofs + i * 32,
regs);
stat = ~(1 irqofs);
}
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 20/26] irqchip: atmel-aic5: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- drivers/irqchip/irq-atmel-aic5.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/irqchip/irq-atmel-aic5.c b/drivers/irqchip/irq-atmel-aic5.c index edb2270..04fe2c1 100644 --- a/drivers/irqchip/irq-atmel-aic5.c +++ b/drivers/irqchip/irq-atmel-aic5.c @@ -78,12 +78,10 @@ aic5_handle(struct pt_regs *regs) irqnr = irq_reg_readl(gc-reg_base + AT91_AIC5_IVR); irqstat = irq_reg_readl(gc-reg_base + AT91_AIC5_ISR); - irqnr = irq_find_mapping(aic5_domain, irqnr); - if (!irqstat) irq_reg_writel(0, gc-reg_base + AT91_AIC5_EOICR); else - handle_IRQ(irqnr, regs); + handle_domain_irq(aic5_domain, irqnr, regs); } static void aic5_mask(struct irq_data *d) -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 18/26] irqchip: GICv3: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-gic-v3.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 57eaa5a..9e31449 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -274,14 +274,13 @@ static asmlinkage void __exception_irq_entry
gic_handle_irq(struct pt_regs *regs
irqnr = gic_read_iar();
if (likely(irqnr 15 irqnr 1020)) {
- u64 irq = irq_find_mapping(gic_data.domain, irqnr);
- if (likely(irq)) {
- handle_IRQ(irq, regs);
- continue;
+ int err;
+ err = handle_domain_irq(gic_data.domain, irqnr, regs);
+ if (err) {
+ WARN_ONCE(true, Unexpected SPI received!\n);
+ gic_write_eoir(irqnr);
}
-
- WARN_ONCE(true, Unexpected SPI received!\n);
- gic_write_eoir(irqnr);
+ continue;
}
if (irqnr 16) {
gic_write_eoir(irqnr);
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 24/26] ARM: omap2: irq: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-omap2/irq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 35b8590..a62ba5a 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -248,8 +248,7 @@ out:
irqnr = ACTIVEIRQ_MASK;
if (irqnr) {
- irqnr = irq_find_mapping(domain, irqnr);
- handle_IRQ(irqnr, regs);
+ handle_domain_irq(domain, irqnr, regs);
handled_irq = 1;
}
} while (irqnr);
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 17/26] irqchip: zevio: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-zevio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-zevio.c b/drivers/irqchip/irq-zevio.c
index ceb3a43..e4ef74e 100644
--- a/drivers/irqchip/irq-zevio.c
+++ b/drivers/irqchip/irq-zevio.c
@@ -56,8 +56,7 @@ static void __exception_irq_entry zevio_handle_irq(struct
pt_regs *regs)
while (readl(zevio_irq_io + IO_STATUS)) {
irqnr = readl(zevio_irq_io + IO_CURRENT);
- irqnr = irq_find_mapping(zevio_irq_domain, irqnr);
- handle_IRQ(irqnr, regs);
+ handle_domain_irq(zevio_irq_domain, irqnr, regs);
};
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/26] irqchip: s3c24xx: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-s3c24xx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index 78a6acc..c8d373f 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -339,7 +339,6 @@ static inline int s3c24xx_handle_intc(struct s3c_irq_intc
*intc,
{
int pnd;
int offset;
- int irq;
pnd = __raw_readl(intc-reg_intpnd);
if (!pnd)
@@ -365,8 +364,7 @@ static inline int s3c24xx_handle_intc(struct s3c_irq_intc
*intc,
if (!(pnd (1 offset)))
offset = __ffs(pnd);
- irq = irq_find_mapping(intc-domain, intc_offset + offset);
- handle_IRQ(irq, regs);
+ handle_domain_irq(intc-domain, intc_offset + offset, regs);
return true;
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/26] irqchip: sirfsoc: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-sirfsoc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-sirfsoc.c b/drivers/irqchip/irq-sirfsoc.c
index 5e54f6d..a469355 100644
--- a/drivers/irqchip/irq-sirfsoc.c
+++ b/drivers/irqchip/irq-sirfsoc.c
@@ -50,12 +50,10 @@ sirfsoc_alloc_gc(void __iomem *base, unsigned int
irq_start, unsigned int num)
static void __exception_irq_entry sirfsoc_handle_irq(struct pt_regs *regs)
{
void __iomem *base = sirfsoc_irqdomain-host_data;
- u32 irqstat, irqnr;
+ u32 irqstat;
irqstat = readl_relaxed(base + SIRFSOC_INIT_IRQ_ID);
- irqnr = irq_find_mapping(sirfsoc_irqdomain, irqstat 0xff);
-
- handle_IRQ(irqnr, regs);
+ handle_domain_irq(sirfsoc_irqdomain, irqstat 0xff, regs);
}
static int __init sirfsoc_irq_init(struct device_node *np,
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/26] irqchip: mxs: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- drivers/irqchip/irq-mxs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-mxs.c b/drivers/irqchip/irq-mxs.c index 4044ff2..e4acf1e 100644 --- a/drivers/irqchip/irq-mxs.c +++ b/drivers/irqchip/irq-mxs.c @@ -78,8 +78,7 @@ asmlinkage void __exception_irq_entry icoll_handle_irq(struct pt_regs *regs) irqnr = __raw_readl(icoll_base + HW_ICOLL_STAT_OFFSET); __raw_writel(irqnr, icoll_base + HW_ICOLL_VECTOR); - irqnr = irq_find_mapping(icoll_domain, irqnr); - handle_IRQ(irqnr, regs); + handle_domain_irq(icoll_domain, irqnr, regs); } static int icoll_irq_domain_map(struct irq_domain *d, unsigned int virq, -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/26] irqchip: orion: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-orion.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index 34d18b4..ad0c0f6 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -43,9 +43,8 @@ __exception_irq_entry orion_handle_irq(struct pt_regs *regs)
gc-mask_cache;
while (stat) {
u32 hwirq = __fls(stat);
- u32 irq = irq_find_mapping(orion_irq_domain,
- gc-irq_base + hwirq);
- handle_IRQ(irq, regs);
+ handle_domain_irq(orion_irq_domain,
+ gc-irq_base + hwirq, regs);
stat = ~(1 hwirq);
}
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/26] irqchip: versatile-fpga: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-versatile-fpga.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-versatile-fpga.c
b/drivers/irqchip/irq-versatile-fpga.c
index ccf5854..1ab4517 100644
--- a/drivers/irqchip/irq-versatile-fpga.c
+++ b/drivers/irqchip/irq-versatile-fpga.c
@@ -96,7 +96,7 @@ static int handle_one_fpga(struct fpga_irq_data *f, struct
pt_regs *regs)
while ((status = readl(f-base + IRQ_STATUS))) {
irq = ffs(status) - 1;
- handle_IRQ(irq_find_mapping(f-domain, irq), regs);
+ handle_domain_irq(f-domain, irq, regs);
handled = 1;
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/26] irqchip: vic: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-vic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 7d35287..54089de 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -219,7 +219,7 @@ static int handle_one_vic(struct vic_device *vic, struct
pt_regs *regs)
while ((stat = readl_relaxed(vic-base + VIC_IRQ_STATUS))) {
irq = ffs(stat) - 1;
- handle_IRQ(irq_find_mapping(vic-domain, irq), regs);
+ handle_domain_irq(vic-domain, irq, regs);
handled = 1;
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/26] irqchip: mmp: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-mmp.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index 1c3e2c9..c0da57b 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -196,26 +196,24 @@ static struct mmp_intc_conf mmp2_conf = {
static void __exception_irq_entry mmp_handle_irq(struct pt_regs *regs)
{
- int irq, hwirq;
+ int hwirq;
hwirq = readl_relaxed(mmp_icu_base + PJ1_INT_SEL);
if (!(hwirq SEL_INT_PENDING))
return;
hwirq = SEL_INT_NUM_MASK;
- irq = irq_find_mapping(icu_data[0].domain, hwirq);
- handle_IRQ(irq, regs);
+ handle_domain_irq(icu_data[0].domain, hwirq, regs);
}
static void __exception_irq_entry mmp2_handle_irq(struct pt_regs *regs)
{
- int irq, hwirq;
+ int hwirq;
hwirq = readl_relaxed(mmp_icu_base + PJ4_INT_SEL);
if (!(hwirq SEL_INT_PENDING))
return;
hwirq = SEL_INT_NUM_MASK;
- irq = irq_find_mapping(icu_data[0].domain, hwirq);
- handle_IRQ(irq, regs);
+ handle_domain_irq(icu_data[0].domain, hwirq, regs);
}
/* MMP (ARMv5) */
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 16/26] irqchip: vt8500: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-vt8500.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-vt8500.c b/drivers/irqchip/irq-vt8500.c
index eb6e91e..b7af816 100644
--- a/drivers/irqchip/irq-vt8500.c
+++ b/drivers/irqchip/irq-vt8500.c
@@ -181,7 +181,7 @@ static struct irq_domain_ops vt8500_irq_domain_ops = {
static void __exception_irq_entry vt8500_handle_irq(struct pt_regs *regs)
{
u32 stat, i;
- int irqnr, virq;
+ int irqnr;
void __iomem *base;
/* Loop through each active controller */
@@ -198,8 +198,7 @@ static void __exception_irq_entry vt8500_handle_irq(struct
pt_regs *regs)
continue;
}
- virq = irq_find_mapping(intc[i].domain, irqnr);
- handle_IRQ(virq, regs);
+ handle_domain_irq(intc[i].domain, irqnr, regs);
}
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/26] irqchip: GIC: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-gic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 4b959e6..480bae8 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -270,8 +270,7 @@ static void __exception_irq_entry gic_handle_irq(struct
pt_regs *regs)
irqnr = irqstat GICC_IAR_INT_ID_MASK;
if (likely(irqnr 15 irqnr 1021)) {
- irqnr = irq_find_mapping(gic-domain, irqnr);
- handle_IRQ(irqnr, regs);
+ handle_domain_irq(gic-domain, irqnr, regs);
continue;
}
if (irqnr 16) {
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/26] openrisc: convert handle_IRQ to use __handle_domain_irq
In order to limit code duplication, convert the architecture specific
handle_IRQ to use the generic __handle_domain_irq function.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/openrisc/Kconfig | 1 +
arch/openrisc/kernel/irq.c | 9 +
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 88e8336..e5a693b 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -8,6 +8,7 @@ config OPENRISC
select OF
select OF_EARLY_FLATTREE
select IRQ_DOMAIN
+ select HANDLE_DOMAIN_IRQ
select HAVE_MEMBLOCK
select ARCH_REQUIRE_GPIOLIB
select HAVE_ARCH_TRACEHOOK
diff --git a/arch/openrisc/kernel/irq.c b/arch/openrisc/kernel/irq.c
index 967eb14..e9aaf28 100644
--- a/arch/openrisc/kernel/irq.c
+++ b/arch/openrisc/kernel/irq.c
@@ -50,14 +50,7 @@ void __init set_handle_irq(void (*handle_irq)(struct pt_regs
*))
void handle_IRQ(unsigned int irq, struct pt_regs *regs)
{
- struct pt_regs *old_regs = set_irq_regs(regs);
-
- irq_enter();
-
- generic_handle_irq(irq);
-
- irq_exit();
- set_irq_regs(old_regs);
+ __handle_domain_irq(NULL, irq, false, regs);
}
void __irq_entry do_IRQ(struct pt_regs *regs)
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/26] irqchip: armada-370-xp: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-armada-370-xp.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/irqchip/irq-armada-370-xp.c
b/drivers/irqchip/irq-armada-370-xp.c
index 574aba0..fa75a29 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -393,13 +393,15 @@ static void armada_370_xp_handle_msi_irq(struct pt_regs
*regs, bool is_chained)
if (!(msimask BIT(msinr)))
continue;
- irq = irq_find_mapping(armada_370_xp_msi_domain,
- msinr - 16);
-
- if (is_chained)
+ if (is_chained) {
+ irq = irq_find_mapping(armada_370_xp_msi_domain,
+ msinr - 16);
generic_handle_irq(irq);
- else
- handle_IRQ(irq, regs);
+ } else {
+ irq = msinr - 16;
+ handle_domain_irq(armada_370_xp_msi_domain,
+ irq, regs);
+ }
}
}
#else
@@ -444,9 +446,8 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
break;
if (irqnr 1) {
- irqnr = irq_find_mapping(armada_370_xp_mpic_domain,
- irqnr);
- handle_IRQ(irqnr, regs);
+ handle_domain_irq(armada_370_xp_mpic_domain,
+ irqnr, regs);
continue;
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/26] genirq: add irq_domain-aware core IRQ handler
Calling irq_find_mapping from outside a irq_{enter,exit} section is
unsafe and produces ugly messages if CONFIG_PROVE_RCU is enabled:
If coming from the idle state, the rcu_read_lock call in irq_find_mapping
will generate an unpleasant warning:
quote
===
[ INFO: suspicious RCU usage. ]
3.16.0-rc1+ #135 Not tainted
---
include/linux/rcupdate.h:871 rcu_read_lock() used illegally while idle!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
#0: (rcu_read_lock){..}, at: [ffc00010206c]
irq_find_mapping+0x4c/0x198
/quote
As this issue is fairly widespread and involves at least three
different architectures, a possible solution is to add a new
handle_domain_irq entry point into the generic IRQ code that
the interrupt controller code can call.
This new function takes an irq_domain, and calls into irq_find_domain
inside the irq_{enter,exit} block. An additional lookup parameter is
used to allow non-domain architecture code to be replaced by this as well.
Interrupt controllers can then be updated to use the new mechanism.
This code is sitting behind a new CONFIG_HANDLE_DOMAIN_IRQ, as not all
architectures implement set_irq_regs (yes, mn10300, I'm looking at you...).
Reported-by: Vladimir Murzin vladimir.mur...@arm.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
include/linux/irqdesc.h | 19 +++
kernel/irq/Kconfig | 3 +++
kernel/irq/irqdesc.c| 42 ++
3 files changed, 64 insertions(+)
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 472c021..ff24667 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -12,6 +12,8 @@ struct irq_affinity_notify;
struct proc_dir_entry;
struct module;
struct irq_desc;
+struct irq_domain;
+struct pt_regs;
/**
* struct irq_desc - interrupt descriptor
@@ -118,6 +120,23 @@ static inline void generic_handle_irq_desc(unsigned int
irq, struct irq_desc *de
int generic_handle_irq(unsigned int irq);
+#ifdef CONFIG_HANDLE_DOMAIN_IRQ
+/*
+ * Convert a HW interrupt number to a logical one using a IRQ domain,
+ * and handle the result interrupt number. Return -EINVAL if
+ * conversion failed. Providing a NULL domain indicates that the
+ * conversion has already been done.
+ */
+int __handle_domain_irq(struct irq_domain *domain, unsigned int hwirq,
+ bool lookup, struct pt_regs *regs);
+
+static inline int handle_domain_irq(struct irq_domain *domain,
+ unsigned int hwirq, struct pt_regs *regs)
+{
+ return __handle_domain_irq(domain, hwirq, true, regs);
+}
+#endif
+
/* Test to see if a driver has successfully requested an irq */
static inline int irq_has_action(unsigned int irq)
{
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index d269cec..225086b 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -55,6 +55,9 @@ config GENERIC_IRQ_CHIP
config IRQ_DOMAIN
bool
+config HANDLE_DOMAIN_IRQ
+ bool
+
config IRQ_DOMAIN_DEBUG
bool Expose hardware/virtual IRQ mapping via debugfs
depends on IRQ_DOMAIN DEBUG_FS
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 1487a12..a1782f8 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -14,6 +14,7 @@
#include linux/kernel_stat.h
#include linux/radix-tree.h
#include linux/bitmap.h
+#include linux/irqdomain.h
#include internals.h
@@ -336,6 +337,47 @@ int generic_handle_irq(unsigned int irq)
}
EXPORT_SYMBOL_GPL(generic_handle_irq);
+#ifdef CONFIG_HANDLE_DOMAIN_IRQ
+/**
+ * __handle_domain_irq - Invoke the handler for a HW irq belonging to a domain
+ * @domain:The domain where to perform the lookup
+ * @hwirq: The HW irq number to convert to a logical one
+ * @lookup:Whether to perform the domain lookup or not
+ * @regs: Register file coming from the low-level handling code
+ *
+ * Returns:0 on success, or -EINVAL if conversion has failed
+ */
+int __handle_domain_irq(struct irq_domain *domain, unsigned int hwirq,
+ bool lookup, struct pt_regs *regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+ unsigned int irq = hwirq;
+ int ret = 0;
+
+ irq_enter();
+
+#ifdef CONFIG_IRQ_DOMAIN
+ if (lookup)
+ irq = irq_find_mapping(domain, hwirq);
+#endif
+
+ /*
+* Some hardware gives randomly wrong interrupts. Rather
+* than crashing, do something sensible.
+*/
+ if (unlikely(!irq || irq = nr_irqs)) {
+ ack_bad_irq(irq);
+ ret = -EINVAL;
+ } else {
+ generic_handle_irq(irq);
+ }
+
+ irq_exit();
+ set_irq_regs(old_regs);
+ return ret;
+}
+#endif
+
/* Dynamic interrupt handling */
/**
--
2.0.4
[PATCH v2 02/26] arm64: convert handle_IRQ to use __handle_domain_irq
In order to limit code duplication, convert the architecture specific
handle_IRQ to use the generic __handle_domain_irq function.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/irq.c | 18 +-
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..1f16ed9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -30,6 +30,7 @@ config ARM64
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
+ select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 0f08dfd..2c0e2a7 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -48,23 +48,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
*/
void handle_IRQ(unsigned int irq, struct pt_regs *regs)
{
- struct pt_regs *old_regs = set_irq_regs(regs);
-
- irq_enter();
-
- /*
-* Some hardware gives randomly wrong interrupts. Rather
-* than crashing, do something sensible.
-*/
- if (unlikely(irq = nr_irqs)) {
- pr_warn_ratelimited(Bad IRQ%u\n, irq);
- ack_bad_irq(irq);
- } else {
- generic_handle_irq(irq);
- }
-
- irq_exit();
- set_irq_regs(old_regs);
+ __handle_domain_irq(NULL, irq, false, regs);
}
void __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/26] irqchip: clps711x: convert to handle_domain_irq
Use the new handle_domain_irq method to handle interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-clps711x.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
index 33340dc..33127f1 100644
--- a/drivers/irqchip/irq-clps711x.c
+++ b/drivers/irqchip/irq-clps711x.c
@@ -76,24 +76,20 @@ static struct {
static asmlinkage void __exception_irq_entry clps711x_irqh(struct pt_regs
*regs)
{
- u32 irqnr, irqstat;
+ u32 irqstat;
do {
irqstat = readw_relaxed(clps711x_intc-intmr[0])
readw_relaxed(clps711x_intc-intsr[0]);
- if (irqstat) {
- irqnr = irq_find_mapping(clps711x_intc-domain,
-fls(irqstat) - 1);
- handle_IRQ(irqnr, regs);
- }
+ if (irqstat)
+ handle_domain_irq(clps711x_intc-domain,
+ fls(irqstat) - 1, regs);
irqstat = readw_relaxed(clps711x_intc-intmr[1])
readw_relaxed(clps711x_intc-intsr[1]);
- if (irqstat) {
- irqnr = irq_find_mapping(clps711x_intc-domain,
-fls(irqstat) - 1 + 16);
- handle_IRQ(irqnr, regs);
- }
+ if (irqstat)
+ handle_domain_irq(clps711x_intc-domain,
+ fls(irqstat) - 1 + 16, regs);
} while (irqstat);
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/26] arm64: convert handle_IRQ to use __handle_domain_irq
On 26/08/14 17:51, Catalin Marinas wrote:
On Tue, Aug 26, 2014 at 11:03:17AM +0100, Marc Zyngier wrote:
In order to limit code duplication, convert the architecture specific
handle_IRQ to use the generic __handle_domain_irq function.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/irq.c | 18 +-
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..1f16ed9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -30,6 +30,7 @@ config ARM64
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
+select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 0f08dfd..2c0e2a7 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -48,23 +48,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
*/
void handle_IRQ(unsigned int irq, struct pt_regs *regs)
{
-struct pt_regs *old_regs = set_irq_regs(regs);
-
-irq_enter();
-
-/*
- * Some hardware gives randomly wrong interrupts. Rather
- * than crashing, do something sensible.
- */
-if (unlikely(irq = nr_irqs)) {
-pr_warn_ratelimited(Bad IRQ%u\n, irq);
-ack_bad_irq(irq);
-} else {
-generic_handle_irq(irq);
-}
-
-irq_exit();
-set_irq_regs(old_regs);
+__handle_domain_irq(NULL, irq, false, regs);
}
The only thing that's missing is a pr_warn_ratelimited(). Do we still
need it? We could add it to ack_bad_irq() though.
Indeed, we could move the warning to ack_bad_irq(), which is always
architecture specific. I'll add that to the next version of the series.
Either way:
Acked-by: Catalin Marinas catalin.mari...@arm.com
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/26] genirq: add irq_domain-aware core IRQ handler
On 26/08/14 18:42, Stephen Boyd wrote:
On 08/26/14 03:03, Marc Zyngier wrote:
Calling irq_find_mapping from outside a irq_{enter,exit} section is
unsafe and produces ugly messages if CONFIG_PROVE_RCU is enabled:
If coming from the idle state, the rcu_read_lock call in irq_find_mapping
will generate an unpleasant warning:
quote
===
[ INFO: suspicious RCU usage. ]
3.16.0-rc1+ #135 Not tainted
---
include/linux/rcupdate.h:871 rcu_read_lock() used illegally while idle!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
#0: (rcu_read_lock){..}, at: [ffc00010206c]
irq_find_mapping+0x4c/0x198
Do you have the whole stacktrace? I don't see where this is called
outside of irq_enter() from within the idle loop, but maybe I missed
something.
Hi Stephen,
Digging into my email, one of the traces looked like this:
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc1+ #135
Call trace:
[ffc882cc] dump_backtrace+0x0/0x12c
[ffc88408] show_stack+0x10/0x1c
[ffc0004ee5f0] dump_stack+0x74/0xc4
[ffcedfbc] lockdep_rcu_suspicious+0xe8/0x124
[ffc00010218c] irq_find_mapping+0x16c/0x198
[ffc8130c] gic_handle_irq+0x38/0xcc
Most drivers call irq_find_mapping outside of irq_enter()/irq_exit(), as
this is in handle_IRQ().
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner t...@linutronix.de
wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this context may be
illegal (specially if coming from the idle state, where RCU would be
in a quiescent state).
A possible fix would be to wrap calls to irq_find_mapping into a
RCU_NONIDLE macro, but that really looks ugly.
This patch series introduce another generic IRQ entry point
(handle_domain_irq), which has the exact same behaviour as handle_IRQ
(as defined on arm, arm64 and openrisc), except that it also takes a
irq_domain pointer. This allows the logical IRQ lookup to be done
inside the irq_{enter,exit} section, which contains a
rcu_irq_{enter,exit}, making it safe.
Looks good. Should this be routed to the genirq tree?
I'm happy for you to take this series, provided the architecture
maintainers agree on it (I'm still to hear from the openrisc guys, and
their mailing-list seems to positively hate my guts).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
[Dropping li...@openrisc.net from the CC list]
On 03/09/14 13:09, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Jason Cooper wrote:
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
t...@linutronix.de wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this context may be
illegal (specially if coming from the idle state, where RCU would be
in a quiescent state).
A possible fix would be to wrap calls to irq_find_mapping into a
RCU_NONIDLE macro, but that really looks ugly.
This patch series introduce another generic IRQ entry point
(handle_domain_irq), which has the exact same behaviour as handle_IRQ
(as defined on arm, arm64 and openrisc), except that it also takes a
irq_domain pointer. This allows the logical IRQ lookup to be done
inside the irq_{enter,exit} section, which contains a
rcu_irq_{enter,exit}, making it safe.
Looks good. Should this be routed to the genirq tree?
I'm happy for you to take this series, provided the architecture
maintainers agree on it (I'm still to hear from the openrisc guys, and
their mailing-list seems to positively hate my guts).
I think everyone's had a chance to look over it by now. Thomas, shall I
take the series?
Yes please.
Do you want a pull request? Or are you picking up the patches from the ML?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On 03/09/14 13:25, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Marc Zyngier wrote:
[Dropping li...@openrisc.net from the CC list]
On 03/09/14 13:09, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Jason Cooper wrote:
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
t...@linutronix.de wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this context may be
illegal (specially if coming from the idle state, where RCU would be
in a quiescent state).
A possible fix would be to wrap calls to irq_find_mapping into a
RCU_NONIDLE macro, but that really looks ugly.
This patch series introduce another generic IRQ entry point
(handle_domain_irq), which has the exact same behaviour as handle_IRQ
(as defined on arm, arm64 and openrisc), except that it also takes a
irq_domain pointer. This allows the logical IRQ lookup to be done
inside the irq_{enter,exit} section, which contains a
rcu_irq_{enter,exit}, making it safe.
Looks good. Should this be routed to the genirq tree?
I'm happy for you to take this series, provided the architecture
maintainers agree on it (I'm still to hear from the openrisc guys, and
their mailing-list seems to positively hate my guts).
I think everyone's had a chance to look over it by now. Thomas, shall I
take the series?
Yes please.
Do you want a pull request? Or are you picking up the patches from the ML?
Did you pick up the Acked/Reviewed/Ignored-by tags?
I have them in a separate branch that can be pushed out as required.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On 03/09/14 13:37, Jason Cooper wrote:
On Wed, Sep 03, 2014 at 02:25:09PM +0200, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Marc Zyngier wrote:
[Dropping li...@openrisc.net from the CC list]
On 03/09/14 13:09, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Jason Cooper wrote:
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
t...@linutronix.de wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this context may be
illegal (specially if coming from the idle state, where RCU would be
in a quiescent state).
A possible fix would be to wrap calls to irq_find_mapping into a
RCU_NONIDLE macro, but that really looks ugly.
This patch series introduce another generic IRQ entry point
(handle_domain_irq), which has the exact same behaviour as handle_IRQ
(as defined on arm, arm64 and openrisc), except that it also takes a
irq_domain pointer. This allows the logical IRQ lookup to be done
inside the irq_{enter,exit} section, which contains a
rcu_irq_{enter,exit}, making it safe.
Looks good. Should this be routed to the genirq tree?
I'm happy for you to take this series, provided the architecture
maintainers agree on it (I'm still to hear from the openrisc guys, and
their mailing-list seems to positively hate my guts).
I think everyone's had a chance to look over it by now. Thomas, shall I
take the series?
Yes please.
Do you want a pull request? Or are you picking up the patches from the ML?
Did you pick up the Acked/Reviewed/Ignored-by tags?
Marc, unless you've already done it, I'll pull from the ml, since I need
to apply the Acked-bys and tweak the subject lines.
If you're going to repaint the subject lines, then I'll leave you to it! ;-)
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 07/12/14 18:03, Nishanth Menon wrote: Marc, On 11:16-20141207, Nishanth Menon wrote: On 13:46-20141206, Marc Zyngier wrote: After my series removing the gic_arch_extn hack, I figured that the next step was to expunge the GIC driver of the routable domain horror. There is a few reasons for this: - The allocation of interrupts in this domain is fairly similar to what we do for MSI (see the GICv2m driver), and stacked domains have proved to be a fitting solution. - The current description in DT is currently entierely inaccurate, and as we already broke it for the OMAP WUGEN block, we might as well do it again for the TI crossbar. - The way crossbar, WUGEN and GIC interract is quite complex (this is effectively a stack of three interrupt controllers with interesting exceptions and braindead routing), and stacked domains are the right abstraction for that. - Other platforms (Freescale Vybrid) are starting to come up with the same type of things, and it'd be good to avoid them following the same broken model. - It removes a few lines from the code base so it can't completely be a bad idea! So this patch series does exactly that: make the crossbar a stacked interrupt controller that only takes care of setting up the routing, fix the DTs to represent the actual HW, and remove a bit of the craziness from the GIC code. As for the previous series: - I haven't been able to test this at all, I don't have access to the HW. TI people, please test and post fixes, as I expect I introduced a few bugs. - This actively *breaks* existing setups. If you boot a new kernel with an old DT, interrupt routing *will* be broken. Old kernels on a new DT won't boot either! You've been warned. This really outline the necessity of actually describing the HW in device trees... As for the patches, they are on top of 3.18-rc7 + tip/irq/irqdomain-arm + the gic_arch_extn removal series. I've pushed the code to: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/die-gic-arch-extn-die-die-die Comments welcome, M. Marc Zyngier (5): genirq: Add irqchip_set_wake_parent irqchip: crossbar: convert dra7 crossbar to stacked domains DT: update ti,irq-crossbar binding irqchip: GIC: get rid of routable domain DT: arm,gic: kill arm,routable-irqs Documentation/devicetree/bindings/arm/gic.txt | 6 - .../devicetree/bindings/arm/omap/crossbar.txt | 18 +- arch/arm/boot/dts/dra7.dtsi| 10 +- arch/arm/boot/dts/dra72x.dtsi | 3 +- arch/arm/boot/dts/dra74x.dtsi | 5 +- arch/arm/mach-omap2/omap4-common.c | 4 - drivers/irqchip/irq-crossbar.c | 202 - drivers/irqchip/irq-gic.c | 59 +- include/linux/irq.h| 1 + include/linux/irqchip/arm-gic.h| 6 - include/linux/irqchip/irq-crossbar.h | 11 -- kernel/irq/chip.c | 16 ++ 12 files changed, 153 insertions(+), 188 deletions(-) delete mode 100644 include/linux/irqchip/irq-crossbar.h -- 2.1.3 Patches are available here: https://patchwork.kernel.org/patch/5449231/ https://patchwork.kernel.org/patch/5449241/ https://patchwork.kernel.org/patch/5449271/ https://patchwork.kernel.org/patch/5449261/ https://patchwork.kernel.org/patch/5449251/ dra7xx-evm(3.18-rc7): Boot PASS: http://slexy.org/raw/s2PXWFB47A dra7xx-evm(irq branch): Boot FAIL: http://slexy.org/raw/s2xMgD4zkP Would you want me to debug more - dts changes perhaps? Yes, it would be useful to find out. One thing that strikes me is that the kernel boots all the way, so I assume IRQs are actually up and running. One thing though. The irq branch shows this: [ 15.359025] pbias_mmc_omap5: disabling and the MMC subsystem never initializes. I'm pretty sure this is related. Config option? Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 08/12/14 22:41, Nishanth Menon wrote: Anyways.. The following diff[1] on top of your branch makes DRA7 work - I assume you will squash as needed and repost with linux-omap mailing list in CC. Brilliant. I'll squash that into my tree and repost at some point. I increased the scope of testing knowing that WUGEN is present in many A9 based TI platforms as well.. and at least OMAP4 showed flakiness in my testing.. Also a few notes: Stuff like: am437x is a bit questionable (interrupt-parent probably should be wugen?) 175: 0 GIC 39 tps65218 OMAP5: (should be wugen?) 308: 4323 0 GIC 106 OMAP UART2 411: 0 0 GIC 151 twl6040 405: 1 0 GIC 39 palmas Well, I can't really tell. Someone with access to the documentation should be able to find out. OMAP4 serial port is flaky - not sure if it is due to routing of GIC to UART2 and not via WUGEN IRQ branch: with my fix applied: - [...] 18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not expected) 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not expected) If I read the log correctly, the serial port stops responding after a while? [...] I suggest skipping 3.19 if possible and giving it a more detailed time in linux-next with omap4 etc being more thoroughly being tested before letting it through, if possible. None of that code is for 3.19 (that ship has sailed a long time ago). My plan is to hit 3.20, so it should be in -next by -rc4 or so. [1] - diff arch/arm/boot/dts/dra7-evm.dts |2 +- arch/arm/boot/dts/dra7.dtsi| 23 +-- drivers/irqchip/irq-crossbar.c |4 ++-- 3 files changed, 16 insertions(+), 13 deletions(-) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index c6ce625..d024429 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -323,7 +323,7 @@ status = okay; pinctrl-names = default; pinctrl-0 = uart1_pins; - interrupts-extended = gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH, + interrupts-extended = crossbar_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH, dra7_pmx_core 0x3e0; }; Ah, I obviously missed quite a few of these... [...] diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c index b44915a..f7daff0 100644 --- a/drivers/irqchip/irq-crossbar.c +++ b/drivers/irqchip/irq-crossbar.c @@ -99,7 +99,7 @@ static int allocate_gic_irq(struct irq_domain *domain, unsigned virq, if (err) cb-irq_map[i] = IRQ_FREE; else - cb-write(hwirq, i); + cb-write(i, hwirq); return err; } @@ -353,4 +353,4 @@ static int __init irqcrossbar_init(struct device_node *node, return 0; } -IRQCHIP_DECLARE(ti_irqcrossbar, ti,irqcrossbar, irqcrossbar_init); +IRQCHIP_DECLARE(ti_irqcrossbar, ti,irq-crossbar, irqcrossbar_init); Ah, nice catch. Thanks a lot for the testing and the fixes. I'll try to get a panda up and running (I'm sure I have one collecting dust somewhere), and see if I can get it to behave. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 09/12/14 18:17, Nishanth Menon wrote:
On 09:53-20141209, Marc Zyngier wrote:
On 08/12/14 22:41, Nishanth Menon wrote:
Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
assume you will squash as needed and repost with linux-omap mailing list
in CC.
Brilliant. I'll squash that into my tree and repost at some point.
K, it will be nice to have a reflow of the series based on v3.19-rc1
since there are dts dependencies and we dont want folks to have
regressions on their platforms of choice..
Obviously, my tests are basic boot tests and should get a few weeks(as
you already mentioned) on linux-next to get properly soaked
I increased the scope of testing knowing that WUGEN is present in many
A9 based TI platforms as well.. and at least OMAP4 showed flakiness in
my testing.. Also a few notes:
Stuff like: am437x is a bit questionable (interrupt-parent probably should
be wugen?)
175: 0 GIC 39 tps65218
OMAP5: (should be wugen?)
308: 4323 0 GIC 106 OMAP UART2
411: 0 0 GIC 151 twl6040
405: 1 0 GIC 39 palmas
Well, I can't really tell. Someone with access to the documentation
should be able to find out.
AM437x: http://www.ti.com/lit/pdf/spruhl7
OMAP5: http://www.ti.com/lit/pdf/swpu249
yeah, we should be able to do them as well - trivially since they follow
the same structure as other SoCs without crossbar.
Done some stuff in that department.
OMAP4 serial port is flaky - not sure if it is due to routing of GIC to
UART2 and not via WUGEN
IRQ branch: with my fix applied:
-
[...]
18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not
expected)
19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not
expected)
If I read the log correctly, the serial port stops responding after a while?
yeah - dug at the omap4 ones a bit, obviously once the deeper c states
are hit, we'd like wakeupgen to wakeup CPU else we will be sluggish in
the sense that the event is detected when some other wakeupgen enabled
interrupt takes place.
I realised that as well once I got a panda up and running.
Adding the following makes my panda work fine.
1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20o8DaBvh
2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s222JndDdh
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 1505135..8b6d50e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -371,8 +371,8 @@
twl: twl@48 {
reg = 0x48;
/* IRQ# = 7 */
- interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N
cascaded to gic */
- interrupt-parent = gic;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N
cascaded to wakeupgen to gic */
+ interrupt-parent = wakeupgen;
};
[...]
I already fixed those in my tree, in a slightly different way: no need
to have an interrupt parent at all, as we're going to inherit the
default anyway.
I've pushed another version of the branch, with the crossbar rework
sitting *before* the WUGEN hacks. That should hopefully make bisection work.
If you can give it a shake, that'd be most appreciated. I'll repost the
branch in a couple of days.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On 15/01/15 17:04, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150115 06:53]: On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon n...@ti.com wrote: On 14:28-20150115, Marc Zyngier wrote: Assuming the workaround I posted earlier works, the OMAP/DRA7 part of this series is going to require some rework too (I need to know where these legacy interrupts are attached: crossbar, WUGEN, or GIC?). crossbar will never work with legacy static interrupts anyways - since there was never a static interrupt possible - I believe we had removed all the legacy hardcoded interrupt definitions for DRA7. ideally, they should all be dt only now. Yes, I guessed as much after looking at the DRA7XX hwmod. So only OMAP4/5 is b0rken at the moment. I can probably work around it as I did in this example patch, just by changing the compatible strings for the xlate callback. Very ugly. For the -rc, it seems the wakeupen still needs a fix as based on grepping for OMAP44XX_IRQ_GIC_START. Got any great ideas for that? I think this one is fine. It computes the SPI number based on the hwirq coming from the GIC. That direction is completely unaffected by the linear domain stuff. It is only when you try to use a hardware IRQ as a Linux IRQ that you run into trouble. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On Thu, Jan 15 2015 at 2:27:56 pm GMT, Arnd Bergmann a...@arndb.de wrote: On Thursday 15 January 2015 13:42:57 Marc Zyngier wrote: Of course, this is in no way a proper fix, but I suppose the OMAP DT is still missing a few bits... I must be missing something here, but all the interrupts are listed correctly in the DT, so what is the omap_hwmod_irq_info actually achieving on omap4 and omap5? Would it work if we just remove the incorrect copy of the resource and use the one that comes from DT? By the look of it, omap_hwmod_irq_info serves multiple purposes: - low level configuration (pads, probably more stuff) - interrupt description for some drivers, using resources. It should be fairly easy to do the latter, but the former looks more tricky (it would push the pad configuration down to the drivers, which is avoided at the moment). Probably there is a workable strategy, but my knowledge about OMAP is close to *nothing*... M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Work around hardcoded interrupts
Commit 9a1091ef0017 (irqchip: gic: Support hierarchy irq domain)
changed the GIC driver to use a non-legacy IRQ domain on DT
platforms. This patch assumes that DT-driven systems are getting
all of their interrupts from device tree.
Turns out that OMAP has quite a few hidden gems, and still uses
hardcoded interrupts despite having fairly complete DTs.
This patch attempts to work around these by offering a translation
method that can be called directly from the hwmod code, if present.
The same hack is sprinkled over PRCM and TWL.
It isn't pretty, but it seems to do the job without having to add
more hacks to the interrupt controller code.
Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/omap4-common.c | 32 ++
arch/arm/mach-omap2/omap_hwmod.c | 10 --
arch/arm/mach-omap2/omap_hwmod.h | 1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 5 +
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 1 +
arch/arm/mach-omap2/prcm-common.h | 1 +
arch/arm/mach-omap2/prm44xx.c | 1 +
arch/arm/mach-omap2/prm_common.c | 14 +++--
arch/arm/mach-omap2/twl-common.c | 5 -
10 files changed, 66 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 377eea8..b664494 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -211,6 +211,7 @@ extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
extern struct device *omap4_get_dsp_device(void);
+unsigned int omap4_xlate_irq(unsigned int hwirq);
void omap_gic_of_init(void);
#ifdef CONFIG_CACHE_L2X0
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index b7cb44a..cc30e49 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -256,6 +256,38 @@ static int __init omap4_sar_ram_init(void)
}
omap_early_initcall(omap4_sar_ram_init);
+static struct of_device_id gic_match[] = {
+ { .compatible = arm,cortex-a9-gic, },
+ { .compatible = arm,cortex-a15-gic, },
+ { },
+};
+
+static struct device_node *gic_node;
+
+unsigned int omap4_xlate_irq(unsigned int hwirq)
+{
+ struct of_phandle_args irq_data;
+ unsigned int irq;
+
+ if (!gic_node)
+ gic_node = of_find_matching_node(NULL, gic_match);
+
+ if (WARN_ON(!gic_node))
+ return hwirq;
+
+ irq_data.np = gic_node;
+ irq_data.args_count = 3;
+ irq_data.args[0] = 0;
+ irq_data.args[1] = hwirq - OMAP44XX_IRQ_GIC_START;
+ irq_data.args[2] = IRQ_TYPE_LEVEL_HIGH;
+
+ irq = irq_create_of_mapping(irq_data);
+ if (WARN_ON(!irq))
+ irq = hwirq;
+
+ return irq;
+}
+
void __init omap_gic_of_init(void)
{
struct device_node *np;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908d..9025fff 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3534,9 +3534,15 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
mpu_irqs_cnt = _count_mpu_irqs(oh);
for (i = 0; i mpu_irqs_cnt; i++) {
+ unsigned int irq;
+
+ if (oh-xlate_irq)
+ irq = oh-xlate_irq((oh-mpu_irqs + i)-irq);
+ else
+ irq = (oh-mpu_irqs + i)-irq;
(res + r)-name = (oh-mpu_irqs + i)-name;
- (res + r)-start = (oh-mpu_irqs + i)-irq;
- (res + r)-end = (oh-mpu_irqs + i)-irq;
+ (res + r)-start = irq;
+ (res + r)-end = irq;
(res + r)-flags = IORESOURCE_IRQ;
r++;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 35ca6ef..5b42faf 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -676,6 +676,7 @@ struct omap_hwmod {
spinlock_t _lock;
struct list_headnode;
struct omap_hwmod_ocp_if*_mpu_port;
+ unsigned int(*xlate_irq)(unsigned int);
u16 flags;
u8 mpu_rt_idx;
u8 response_lat;
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c314b3c..f5e68a7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -479,6 +479,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
.class = omap44xx_dma_hwmod_class,
.clkdm_name = l3_dma_clkdm,
.mpu_irqs = omap44xx_dma_system_irqs,
+ .xlate_irq
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon n...@ti.com wrote: On 14:28-20150115, Marc Zyngier wrote: Assuming the workaround I posted earlier works, the OMAP/DRA7 part of this series is going to require some rework too (I need to know where these legacy interrupts are attached: crossbar, WUGEN, or GIC?). crossbar will never work with legacy static interrupts anyways - since there was never a static interrupt possible - I believe we had removed all the legacy hardcoded interrupt definitions for DRA7. ideally, they should all be dt only now. Yes, I guessed as much after looking at the DRA7XX hwmod. So only OMAP4/5 is b0rken at the moment. I can probably work around it as I did in this example patch, just by changing the compatible strings for the xlate callback. Very ugly. M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On 16/01/15 16:56, Arnd Bergmann wrote: On Thursday 15 January 2015 07:37:48 Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150115 06:46]: On Thu, Jan 15 2015 at 2:27:56 pm GMT, Arnd Bergmann a...@arndb.de wrote: On Thursday 15 January 2015 13:42:57 Marc Zyngier wrote: Probably there is a workable strategy, but my knowledge about OMAP is close to *nothing*... I have a feeling this might bite other platforms too and we just have not noticed it yet.. I'm looking through the entire tree now, scanning for machines that have GIC and use IORESOURCE_IRQ or DEFINE_RES_IRQ in their platform code. Most platforms using GIC are completely converted to DT and have no hardcoded legacy IRQs. I have checked that cns3xxx and realview are both fine by inspection. The only one I'm not sure about is shmobile, which looks like it might suffer from the same problem. Simon/Magnus, could you verify this with a multiplatform kernel on any SoC that has GIC and uses devices that have interrupts defined in setup-*.c or board-*.c? There are 3 patches floating around for shmobile, converting their non-DT support to directly initializing the GIC instead of relying on irqchip_init(). That's assuming their DT implementation doesn't use any of these device declarations. If they do, we could use a hack similar to the one I implemented for OMAP, populating the virtual IRQ in the resource at boot time, just after the irqchip initialization. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3,15/21] ARM: exynos4/5: convert pmu wakeup to stacked domains
Hi Pankaj, On 15/01/15 06:41, Pankaj Dubey wrote: +CC: Thomas Abraham thomas...@samsung.com Hi Mark, On Monday 12 January 2015 11:56 PM, Marc Zyngier wrote: Exynos has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the fact that the PMU block is actually the first interrupt controller in the chain for RTC, kernels with this patch applied wont have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs may not even boot. Also, I stronly suspect that there is more than two wake-up interrupts on these platforms, but I leave it to the maintainers to fix their mess. Signed-off-by: Marc Zyngier marc.zyng...@arm.com I tested this series on Exynos5250, using kgene/for-next and linux-next/next-20150114, but S2R failed on Exynos5250 based SMDK board. Following is the log I got on SMDK5250 board, (note I have added some debugging log to know what is happening) I can see is S3C-RTC's enable_irq_wake is failing with error -6. I also observed that even though we are adding pmu_domain_ops using irq_domain_add_hierarchy, but none of pmu_domain_ops are getting called. Please let me know if I am missing anything or do I need to modify anything to test S2R on Exynos SoC. Thanks for giving it a go. One think I noticed is that I forgot to add a #interrupt-cells = 3; to the pmu_system_controller node. Also, it would be interesting to know what is the hwirq associated with the irq_desc you've printed below. Thanks, M. - echo +10 /sys/class/rtc/rtc1/wakealarm; sleep 1; echo mem /sys/power/sta te [ 257.428163] PM: Syncing filesystems ... done. [ 257.431786] Freezing user space processes ... (elapsed 0.003 seconds) done. [ 257.439680] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 257.544451] wake enabled for irq 116 [ 257.546916] CPU: 0 PID: 1311 Comm: ash Not tainted 3.19.0-rc4-next-20150114-00023-g492ff37 #15 [ 257.555141] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 257.561231] [c0014430] (unwind_backtrace) from [c0011594] (show_stack+0x10/0x14) [ 257.568948] [c0011594] (show_stack) from [c0418b00] (dump_stack+0x84/0xc4) [ 257.576151] [c0418b00] (dump_stack) from [c005ce30] (set_irq_wake_real+0x58/0x8c) [ 257.583961] [c005ce30] (set_irq_wake_real) from [c005cef0] (irq_set_irq_wake+0x8c/0xf0) [ 257.592295] [c005cef0] (irq_set_irq_wake) from [c02e9d94] (s3c_rtc_suspend+0xb8/0xdc) [ 257.600456] [c02e9d94] (s3c_rtc_suspend) from [c0298c80] (dpm_run_callback.isra.13+0x1c/0x60) [ 257.609308] [c0298c80] (dpm_run_callback.isra.13) from [c02996a0] (__device_suspend+0x128/0x2d0) [ 257.618422] [c02996a0] (__device_suspend) from [c029a850] (dpm_suspend+0x64/0x22c) [ 257.626320] [c029a850] (dpm_suspend) from [c0058488] (suspend_devices_and_enter+0x88/0x3dc) [ 257.634999] [c0058488] (suspend_devices_and_enter) from [c00589c8] (pm_suspend+0x1ec/0x24c) [ 257.643680] [c00589c8] (pm_suspend) from [c00576e0] (state_store+0x68/0xb8) [ 257.650972] [c00576e0] (state_store) from [c012835c] (kernfs_fop_write+0xb8/0x19c) [ 257.658870] [c012835c] (kernfs_fop_write) from [c00cf620] (vfs_write+0xa0/0x1ac) [ 257.666595] [c00cf620] (vfs_write) from [c00cfc78] (SyS_write+0x44/0x9c) [ 257.673625] [c00cfc78] (SyS_write) from [c000e6e0] (ret_fast_syscall+0x0/0x30) [ 257.681176] genirq: PKD: irq_desc-name: (null): irq: 60 [ 257.686469] genirq: PKD: set_irq_wake_real: ret: -6 [ 257.691349] s3c-rtc 101e.rtc: enable_irq_wake failed: -6 [ 257.708926] PM: suspend of devices complete after 260.482 msecs [ 257.713362] BUCK9: No configuration [ 257.716840] BUCK8: No configuration [ 257.720309] BUCK7: No configuration [ 257.723776] BUCK6: No configuration [ 257.727254] P1.8V_BUCK_OUT5: No configuration [ 257.731597] LDO26: No configuration [ 257.735066] LDO25: No configuration [ 257.738532] LDO24: No configuration [ 257.742009] LDO23: No configuration [ 257.745481] LDO22: No configuration [ 257.748954] LDO21: No configuration [ 257.752419] LDO20: No configuration [ 257.755897] LDO19: No configuration [ 257.759370] LDO18: No configuration [ 257.762835] LDO17: No configuration [ 257.766314] P1.8V_LDO_OUT16: No configuration [ 257.770653] P1.0V_LDO_OUT15: No configuration [ 257.774994] P1.8V_LDO_OUT14: No configuration [ 257.779334] P1.8V_LDO_OUT13: No configuration [ 257.783668] P3.0V_LDO_OUT12: No configuration [ 257.788013] P1.8V_LDO_OUT11: No configuration [ 257.792353] P1.8V_LDO_OUT10: No configuration [ 257.796693] LDO9: No configuration [ 257.800079] P1.0V_LDO_OUT8: No configuration [ 257.804332] P1.1V_LDO_OUT7
[PATCH v2] ARM: OMAP: Work around hardcoded interrupts
Commit 9a1091ef0017 (irqchip: gic: Support hierarchy irq domain)
changed the GIC driver to use a non-legacy IRQ domain on DT
platforms. This patch assumes that DT-driven systems are getting
all of their interrupts from device tree.
Turns out that OMAP has quite a few hidden gems, and still uses
hardcoded interrupts despite having fairly complete DTs.
This patch attempts to work around these by offering a translation
method that can be called directly from the hwmod code, if present.
The same hack is sprinkled over PRCM and TWL.
It isn't pretty, but it seems to do the job without having to add
more hacks to the interrupt controller code.
Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
From v1:
- OMAP4 can either get the PRM interrupt from hwmod or from device tree.
In the latter case, remove the xlate_irq method.
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/omap4-common.c | 32 ++
arch/arm/mach-omap2/omap_hwmod.c | 10 --
arch/arm/mach-omap2/omap_hwmod.h | 1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 5 +
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 1 +
arch/arm/mach-omap2/prcm-common.h | 1 +
arch/arm/mach-omap2/prm44xx.c | 5 -
arch/arm/mach-omap2/prm_common.c | 14 +++--
arch/arm/mach-omap2/twl-common.c | 5 -
10 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 377eea8..b664494 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -211,6 +211,7 @@ extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
extern struct device *omap4_get_dsp_device(void);
+unsigned int omap4_xlate_irq(unsigned int hwirq);
void omap_gic_of_init(void);
#ifdef CONFIG_CACHE_L2X0
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index b7cb44a..cc30e49 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -256,6 +256,38 @@ static int __init omap4_sar_ram_init(void)
}
omap_early_initcall(omap4_sar_ram_init);
+static struct of_device_id gic_match[] = {
+ { .compatible = arm,cortex-a9-gic, },
+ { .compatible = arm,cortex-a15-gic, },
+ { },
+};
+
+static struct device_node *gic_node;
+
+unsigned int omap4_xlate_irq(unsigned int hwirq)
+{
+ struct of_phandle_args irq_data;
+ unsigned int irq;
+
+ if (!gic_node)
+ gic_node = of_find_matching_node(NULL, gic_match);
+
+ if (WARN_ON(!gic_node))
+ return hwirq;
+
+ irq_data.np = gic_node;
+ irq_data.args_count = 3;
+ irq_data.args[0] = 0;
+ irq_data.args[1] = hwirq - OMAP44XX_IRQ_GIC_START;
+ irq_data.args[2] = IRQ_TYPE_LEVEL_HIGH;
+
+ irq = irq_create_of_mapping(irq_data);
+ if (WARN_ON(!irq))
+ irq = hwirq;
+
+ return irq;
+}
+
void __init omap_gic_of_init(void)
{
struct device_node *np;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908d..9025fff 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3534,9 +3534,15 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
mpu_irqs_cnt = _count_mpu_irqs(oh);
for (i = 0; i mpu_irqs_cnt; i++) {
+ unsigned int irq;
+
+ if (oh-xlate_irq)
+ irq = oh-xlate_irq((oh-mpu_irqs + i)-irq);
+ else
+ irq = (oh-mpu_irqs + i)-irq;
(res + r)-name = (oh-mpu_irqs + i)-name;
- (res + r)-start = (oh-mpu_irqs + i)-irq;
- (res + r)-end = (oh-mpu_irqs + i)-irq;
+ (res + r)-start = irq;
+ (res + r)-end = irq;
(res + r)-flags = IORESOURCE_IRQ;
r++;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 35ca6ef..5b42faf 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -676,6 +676,7 @@ struct omap_hwmod {
spinlock_t _lock;
struct list_headnode;
struct omap_hwmod_ocp_if*_mpu_port;
+ unsigned int(*xlate_irq)(unsigned int);
u16 flags;
u8 mpu_rt_idx;
u8 response_lat;
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c314b3c..f5e68a7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -479,6 +479,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
.class
Re: [PATCH v4 15/21] ARM: exynos4/5: convert pmu wakeup to stacked domains
Hi Pankaj,
On 2015-01-20 07:42, Pankaj Dubey wrote:
Hi Marc,
On Monday 19 January 2015 03:14 PM, Marc Zyngier wrote:
Exynos has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the fact that the PMU block is actually the first
interrupt controller in the chain for RTC, kernels with this patch
applied wont have any suspend-resume facility when booted
with old DTs, and old kernels with updated DTs may not even boot.
Also, I stronly suspect that there is more than two wake-up
interrupts on these platforms, but I leave it to the maintainers
to fix their mess.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
I tested this patch series on SMDK5250 board.
With the addition of #interrupt-cells = 3;in PMU device node S2R
is working on Exynos5250 based SMDK board.
Thanks for letting me know. Can I add your Tested-by tag on this?
arch/arm/boot/dts/exynos4.dtsi| 4 ++
arch/arm/boot/dts/exynos5250.dtsi | 4 ++
arch/arm/boot/dts/exynos5420.dtsi | 4 ++
arch/arm/mach-exynos/exynos.c | 14 ++---
arch/arm/mach-exynos/suspend.c| 122
++
5 files changed, 129 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi
b/arch/arm/boot/dts/exynos4.dtsi
index b8168f1..0e7d74e 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -141,6 +141,9 @@
pmu_system_controller: system-controller@1002 {
compatible = samsung,exynos4210-pmu, syscon;
reg = 0x1002 0x4000;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
};
dsi_0: dsi@11C8 {
@@ -253,6 +256,7 @@
rtc@1007 {
compatible = samsung,s3c6410-rtc;
reg = 0x1007 0x100;
+ interrupt-parent = pmu_system_controller;
interrupts = 0 44 0, 0 45 0;
clocks = clock CLK_RTC;
clock-names = rtc;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a229fc..1dc5f6b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -194,6 +194,9 @@
clock-names = clkout16;
clocks = clock CLK_FIN_PLL;
#clock-cells = 1;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
};
sysreg_system_controller: syscon@1005 {
@@ -230,6 +233,7 @@
rtc: rtc@101E {
clocks = clock CLK_RTC;
clock-names = rtc;
+ interrupt-parent = pmu_system_controller;
status = disabled;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 517e50f..35ecd36 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -309,6 +309,7 @@
rtc: rtc@101E {
clocks = clock CLK_RTC;
clock-names = rtc;
+ interrupt-parent = pmu_system_controller;
status = disabled;
};
@@ -748,6 +749,9 @@
clock-names = clkout16;
clocks = clock CLK_FIN_PLL;
#clock-cells = 1;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
};
sysreg_system_controller: syscon@1005 {
diff --git a/arch/arm/mach-exynos/exynos.c
b/arch/arm/mach-exynos/exynos.c
index c13d083..e417fdc 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -175,16 +175,15 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+/*
+ * Apparently, these SoCs are not able to wake-up from suspend
using
+ * the PMU. Too bad. Should they suddenly become capable of such a
+ * feat, the matches below should be moved to suspend.c.
+ */
static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = samsung,exynos3250-pmu },
As I know Exynos3250, S2R support has been added in kgene/for-next
and should work as expected so we may need to do update
exynos_wkup_irq for exynos3250 and remove it from this list, so
that
it's S2R should not break. I am adding concern engineer (+cc: Chanwoo
Choi) in the loop.
That would have to be an additional patch, unless we decide to delay
this series.
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
On 21/01/15 16:30, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150119 01:48]: OMAP4/5 has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the WUGEN HW block, kernels with this patch applied won't have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs won't even boot. On a platform with this patch applied, the system looks like this: root@bacon-fat:~# cat /proc/interrupts CPU0 CPU1 16: 0 0 WUGEN 37 gp_timer 19: 233799 155916 GIC 27 arch_timer 23: 0 0 WUGEN 9 l3-dbg-irq 24: 1 0 WUGEN 10 l3-app-irq 27:282 0 WUGEN 13 omap-dma-engine 44: 0 0 4ae1.gpio 13 DMA You may want to update this part for the fix :) Ah, yes. Thanks for noticing this. I gave this a quick boot test on am437x-gp-evm and the interrupts look OK with the fix also applied: # cat /proc/interrupts CPU0 16:657 WUGEN 68 gp_timer 18: 0 WUGEN 9 l3-dbg-irq 19: 0 WUGEN 10 l3-app-irq 20: 5 WUGEN 12 edma 22: 0 WUGEN 14 edma_error 23: 96 WUGEN 72 OMAP UART0 33: 0 44e07000.gpio 6 mmc0 158: 52 WUGEN 70 44e0b000.i2c 159: 0 WUGEN 71 4802a000.i2c 160: 35 WUGEN 64 mmc0 161: 0 WUGEN 40 4a10.ethernet 162: 7739 WUGEN 41 4a10.ethernet 163: 7608 WUGEN 42 4a10.ethernet 164: 0 WUGEN 43 4a10.ethernet 170: 0 WUGEN 100 gpmc 180: 0 WUGEN 7 tps65218 IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts IPI6: 0 IRQ work interrupts IPI7: 0 completion interrupts Err: 0 Interesting. No TWD timer on this one? Also verified that suspend and resume to a serial console event works on omap4430-sdp. So please feel free to add: Acked-by: Tony Lindgren t...@atomide.com Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 00/21] irqchip: gic: killing gic_arch_extn and co, slowly
The gic_arch_extn hack that a number of platform use has been nagging me for too long. It is only there for the benefit of a few platform, and yet it impacts all GIC users. Moreover, it gives people the wrong idea (let's use it to put some new custom hack in there...). But now that stacked irq domains have been merged into 3.19, the time has come for gic_arch_extn to meet the Big Bit Bucket. This patch series takes several steps towards the elimination of gic_arch_extn: - moves Tegra's legacy interrupt controller support to drivers/irqchip, implementing a stacked domain on top of the standard GIC. - OMAP, imx6 and exynos are also converted to stacked domains, but their implementation is left in place (the code is far too intricately mixed with other details of the platform for me to even try to move it). Some OMAP variants get a special treatment as we also kill the crossbar horror (more on that below). - shmobile, ux500 and zynq are only slightly modified. - The GIC itself is cleaned up, and some other bits and bobs are adjusted for a good measure. About the TI crossbar: - The allocation of interrupts in this domain is fairly similar to what we do for MSI (see the GICv2m driver), and stacked domains have proved to be a fitting solution. - The current description in DT is currently entierely inaccurate, and as we're already breaking it for the WUGEN block, we might as well do it again for the crossbar. - The way crossbar, WUGEN and GIC interract is quite complex (this is effectively a stack of three interrupt controllers with interesting exceptions and braindead routing), and stacked domains are the right abstraction for that. - Other platforms (Freescale Vybrid) are starting to come up with the same type of things, and it'd be good to avoid them following the same broken model. - It removes a few lines from the code base so it can't completely be a bad idea! So this patch series does exactly that: make the crossbar a stacked interrupt controller that only takes care of setting up the routing, fix the DTs to represent the actual HW, and remove a bit of the craziness from the GIC code. It is worth realizing that: - I haven't been able to test this as much as I would have wanted to (it's only been tested on tegra2, omap4 and omap5). - I've created DT bindings when needed, updated existing ones, but I haven't created a binding for platforms that already used an undocumented one (imx6, I'm looking at you). - I've relaxed quite a bit of the locking in the GIC code. I believe this is safe, but someone else should give it a long hard look. - This actively *breaks* existing setups. Once you boot a new kernel with an old DT, suspend/resume *will* be broken. Old kernels on a new DT won't even boot! You've been warned. This really outline the necessity of actually describing the HW in device trees... As for the patches, they are on top of 3.19-rc3 + the patch posted here [4]. I've pushed the code to: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/die-gic-arch-extn-die-die-die I'm still targetting 3.20 for this, but obviously things are getting quite tight. I'd very much like to hear from the maintainers about their views concerning this series. Thanks, M. * From v4 [3]: - Rebased on top of the patch working around hardcoded IRQ on OMAP4/5 [4] - Fixed more iMX6 DTs (Stephan) - Fixed Exynos4/5 DTs * From v2 [2]: - Addressed numerous comments from Thierry - Merged bug fixes from Nishanth - Merged bug fix from Stefan * From v1 [1]: - Rebased on 3.19-rc3 - Fixed a number of additional platforms - Added crossbar conversion to stacked domains - Merged bug fixes from Nishanth [4]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317286.html [3]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315385.html [2]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314041.html [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307338.html Marc Zyngier (21): ARM: tegra: irq: nuke leftovers from non-DT support irqchip: tegra: add DT-based support for legacy interrupt controller ARM: tegra: skip gic_arch_extn setup if DT has a LIC node ARM: tegra: update DTs to expose legacy interrupt controller DT: tegra: add binding for the legacy interrupt controller ARM: tegra: remove old LIC support genirq: Add irqchip_set_wake_parent irqchip: crossbar: convert dra7 crossbar to stacked domains DT: update ti,irq-crossbar binding irqchip: GIC: get rid of routable domain DT: arm,gic: kill arm,routable-irqs DT: omap4/5: add binding for the wake-up generator ARM: omap: convert wakeupgen to stacked domains ARM: imx6: convert GPC to stacked domains ARM: exynos4/5: convert pmu wakeup to stacked domains DT: exynos: update PMU binding irqchip: gic: add an entry point to set up irqchip flags ARM: shmobile: remove use
[PATCH v4 08/21] irqchip: crossbar: convert dra7 crossbar to stacked domains
Support for the TI crossbar used on the DRA7 family of chips
is implemented as an ugly hack on the side of the GIC.
Converting it to stacked domains makes it slightly more
palatable, as it results in a cleanup.
Unfortunately, as the DT bindings failed to acknowledge the
fact that this is actually yet another interrupt controller
(the third, actually), we have yet another breakage. Oh well.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 +-
arch/arm/boot/dts/dra7-evm.dts | 2 +-
arch/arm/boot/dts/dra7.dtsi | 35 +++---
arch/arm/boot/dts/dra72-evm.dts | 1 -
arch/arm/boot/dts/dra72x.dtsi | 3 +-
arch/arm/boot/dts/dra74x.dtsi | 5 +-
arch/arm/mach-omap2/omap4-common.c | 4 -
drivers/irqchip/irq-crossbar.c | 207 ++--
include/linux/irqchip/irq-crossbar.h| 11 --
9 files changed, 146 insertions(+), 125 deletions(-)
delete mode 100644 include/linux/irqchip/irq-crossbar.h
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..c2241c2 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -335,7 +335,6 @@
mcp_rtc: rtc@6f {
compatible = microchip,mcp7941x;
reg = 0x6f;
- interrupt-parent = gic;
interrupts = GIC_SPI 2 IRQ_TYPE_LEVEL_LOW; /* IRQ_SYS_1N */
pinctrl-names = default;
@@ -358,7 +357,7 @@
uart3 {
status = okay;
- interrupts-extended = gic GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH,
+ interrupts-extended = crossbar_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH,
dra7_pmx_core 0x248;
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 10b725c..048cfeb 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -423,7 +423,7 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = uart1_pins;
- interrupts-extended = gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH,
+ interrupts-extended = crossbar_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH,
dra7_pmx_core 0x3e0;
};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 22771bc..6f90673 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -13,14 +13,13 @@
#include skeleton.dtsi
#define MAX_SOURCES 400
-#define DIRECT_IRQ(irq) (MAX_SOURCES + irq)
/ {
#address-cells = 1;
#size-cells = 1;
compatible = ti,dra7xx;
- interrupt-parent = gic;
+ interrupt-parent = crossbar_mpu;
aliases {
i2c0 = i2c1;
@@ -50,18 +49,19 @@
GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW);
+ interrupt-parent = gic;
};
gic: interrupt-controller@48211000 {
compatible = arm,cortex-a15-gic;
interrupt-controller;
#interrupt-cells = 3;
- arm,routable-irqs = 192;
reg = 0x48211000 0x1000,
0x48212000 0x1000,
0x48214000 0x2000,
0x48216000 0x2000;
interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_HIGH);
+ interrupt-parent = gic;
};
/*
@@ -91,8 +91,8 @@
ti,hwmods = l3_main_1, l3_main_2;
reg = 0x4400 0x100,
0x4500 0x1000;
- interrupts = GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI DIRECT_IRQ(10) IRQ_TYPE_LEVEL_HIGH;
+ interrupts-extended = crossbar_mpu GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH,
+ gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
prm: prm@4ae06000 {
compatible = ti,dra7-prm;
@@ -344,7 +344,7 @@
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
reg = 0x4806a000 0x100;
- interrupts-extended = gic GIC_SPI 67
IRQ_TYPE_LEVEL_HIGH;
+ interrupts-extended = crossbar_mpu GIC_SPI 67
IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart1;
clock-frequency = 4800;
status = disabled;
@@ -355,7 +355,7 @@
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
reg = 0x4806c000 0x100;
- interrupts-extended = gic GIC_SPI 68
IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH
[PATCH v4 02/21] irqchip: tegra: add DT-based support for legacy interrupt controller
Tegra's LIC (Legacy Interrupt Controller) has been so far only
supported as a weird extension of the GIC, which is not exactly
pretty.
The stacked IRQ domain framework fits this pretty well, and allows
the LIC code to be turned into a standalone irqchip. In the process,
make the driver DT aware, something that was sorely missing from
the mach-tegra implementation.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-tegra.c | 368
2 files changed, 369 insertions(+)
create mode 100644 drivers/irqchip/irq-tegra.c
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 9516a32..59f34be 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_ARCH_HIP04)+= irq-hip04.o
obj-$(CONFIG_ARCH_MMP) += irq-mmp.o
obj-$(CONFIG_ARCH_MVEBU) += irq-armada-370-xp.o
obj-$(CONFIG_ARCH_MXS) += irq-mxs.o
+obj-$(CONFIG_ARCH_TEGRA) += irq-tegra.o
obj-$(CONFIG_ARCH_S3C24XX) += irq-s3c24xx.o
obj-$(CONFIG_DW_APB_ICTL) += irq-dw-apb-ictl.o
obj-$(CONFIG_METAG)+= irq-metag-ext.o
diff --git a/drivers/irqchip/irq-tegra.c b/drivers/irqchip/irq-tegra.c
new file mode 100644
index 000..e1ac65e
--- /dev/null
+++ b/drivers/irqchip/irq-tegra.c
@@ -0,0 +1,368 @@
+/*
+ * Driver code for Tegra's Legacy Interrupt Controller
+ *
+ * Author: Marc Zyngier marc.zyng...@arm.com
+ *
+ * Heavily based on the original arch/arm/mach-tegra/irq.c code:
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * Author:
+ * Colin Cross ccr...@android.com
+ *
+ * Copyright (C) 2010,2013, NVIDIA Corporation
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include linux/io.h
+#include linux/irq.h
+#include linux/irqdomain.h
+#include linux/of_address.h
+#include linux/slab.h
+#include linux/syscore_ops.h
+
+#include dt-bindings/interrupt-controller/arm-gic.h
+
+#include irqchip.h
+
+#define ICTLR_CPU_IEP_VFIQ 0x08
+#define ICTLR_CPU_IEP_FIR 0x14
+#define ICTLR_CPU_IEP_FIR_SET 0x18
+#define ICTLR_CPU_IEP_FIR_CLR 0x1c
+
+#define ICTLR_CPU_IER 0x20
+#define ICTLR_CPU_IER_SET 0x24
+#define ICTLR_CPU_IER_CLR 0x28
+#define ICTLR_CPU_IEP_CLASS0x2C
+
+#define ICTLR_COP_IER 0x30
+#define ICTLR_COP_IER_SET 0x34
+#define ICTLR_COP_IER_CLR 0x38
+#define ICTLR_COP_IEP_CLASS0x3c
+
+#define TEGRA_MAX_NUM_ICTLRS 5
+
+static unsigned int num_ictlrs;
+
+struct tegra_ictlr_soc {
+ unsigned int num_ictlrs;
+};
+
+static const struct tegra_ictlr_soc tegra20_ictlr_soc = {
+ .num_ictlrs = 4,
+};
+
+static const struct tegra_ictlr_soc tegra30_ictlr_soc = {
+ .num_ictlrs = 5,
+};
+
+static const struct of_device_id ictlr_matches[] = {
+ { .compatible = nvidia,tegra30-ictlr, .data = tegra30_ictlr_soc },
+ { .compatible = nvidia,tegra20-ictlr, .data = tegra20_ictlr_soc },
+ { }
+};
+
+struct tegra_ictlr_info {
+ void __iomem *base[TEGRA_MAX_NUM_ICTLRS];
+#ifdef CONFIG_PM_SLEEP
+ u32 cop_ier[TEGRA_MAX_NUM_ICTLRS];
+ u32 cop_iep[TEGRA_MAX_NUM_ICTLRS];
+ u32 cpu_ier[TEGRA_MAX_NUM_ICTLRS];
+ u32 cpu_iep[TEGRA_MAX_NUM_ICTLRS];
+
+ u32 ictlr_wake_mask[TEGRA_MAX_NUM_ICTLRS];
+#endif
+};
+
+static struct tegra_ictlr_info *lic;
+
+static inline void tegra_ictlr_write_mask(struct irq_data *d, unsigned long
reg)
+{
+ void __iomem *base = d-chip_data;
+ u32 mask;
+
+ mask = BIT(d-hwirq % 32);
+ writel_relaxed(mask, base + reg);
+}
+
+static void tegra_mask(struct irq_data *d)
+{
+ tegra_ictlr_write_mask(d, ICTLR_CPU_IER_CLR);
+ irq_chip_mask_parent(d);
+}
+
+static void tegra_unmask(struct irq_data *d)
+{
+ tegra_ictlr_write_mask(d, ICTLR_CPU_IER_SET);
+ irq_chip_unmask_parent(d);
+}
+
+static void tegra_eoi(struct irq_data *d)
+{
+ tegra_ictlr_write_mask(d, ICTLR_CPU_IEP_FIR_CLR);
+ irq_chip_eoi_parent(d);
+}
+
+static int tegra_retrigger(struct irq_data *d)
+{
+ tegra_ictlr_write_mask(d, ICTLR_CPU_IEP_FIR_SET);
+ return irq_chip_retrigger_hierarchy(d);
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int tegra_set_wake(struct irq_data *d, unsigned int enable)
+{
+ u32 irq = d-hwirq;
+ u32 index, mask;
+
+ index = (irq / 32);
+ mask = BIT(irq % 32);
+ if (enable)
+ lic-ictlr_wake_mask[index] |= mask;
+ else
+ lic-ictlr_wake_mask[index] = ~mask
[PATCH v4 07/21] genirq: Add irqchip_set_wake_parent
This proves to be useful with stacked domains, when the current
domain doesn't implement wake-up, but expect the parent to do so.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
include/linux/irq.h | 1 +
kernel/irq/chip.c | 16
2 files changed, 17 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index d09ec7a..3057c48 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -460,6 +460,7 @@ extern void irq_chip_eoi_parent(struct irq_data *data);
extern int irq_chip_set_affinity_parent(struct irq_data *data,
const struct cpumask *dest,
bool force);
+extern int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on);
#endif
/* Handling of unhandled and spurious interrupts: */
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6f1c7a5..eb9a4ea 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -948,6 +948,22 @@ int irq_chip_retrigger_hierarchy(struct irq_data *data)
return -ENOSYS;
}
+
+/**
+ * irq_chip_set_wake_parent - Set/reset wake-up on the parent interrupt
+ * @data: Pointer to interrupt specific data
+ * @on:Whether to set or reset the wake-up capability of this
irq
+ *
+ * Conditional, as the underlying parent chip might not implement it.
+ */
+int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
+{
+ data = data-parent_data;
+ if (data-chip-irq_set_wake)
+ return data-chip-irq_set_wake(data, on);
+
+ return -ENOSYS;
+}
#endif
/**
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/21] ARM: tegra: irq: nuke leftovers from non-DT support
The GIC is now always initialized from DT on tegra, and there is no point in keeping non-DT init code. Acked-by: Thierry Reding tred...@nvidia.com Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- arch/arm/mach-tegra/irq.c | 8 1 file changed, 8 deletions(-) diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c index ab95f53..7f87a50 100644 --- a/arch/arm/mach-tegra/irq.c +++ b/arch/arm/mach-tegra/irq.c @@ -283,13 +283,5 @@ void __init tegra_init_irq(void) gic_arch_extn.irq_set_wake = tegra_set_wake; gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND; - /* -* Check if there is a devicetree present, since the GIC will be -* initialized elsewhere under DT. -*/ - if (!of_have_populated_dt()) - gic_init(0, 29, distbase, - IO_ADDRESS(TEGRA_ARM_PERIF_BASE + 0x100)); - tegra114_gic_cpu_pm_registration(); } -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 04/21] ARM: tegra: update DTs to expose legacy interrupt controller
Describe the legacy interrupt controller in every tegra DTSI files,
and make it the parent of most interrupts.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/tegra114.dtsi | 16 +++-
arch/arm/boot/dts/tegra124.dtsi | 16 +++-
arch/arm/boot/dts/tegra20.dtsi | 15 ++-
arch/arm/boot/dts/tegra30.dtsi | 16 +++-
4 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 4296b53..f58a3d9 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -8,7 +8,7 @@
/ {
compatible = nvidia,tegra114;
- interrupt-parent = gic;
+ interrupt-parent = lic;
host1x@5000 {
compatible = nvidia,tegra114-host1x, simple-bus;
@@ -134,6 +134,19 @@
0x50046000 0x2000;
interrupts = GIC_PPI 9
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH);
+ interrupt-parent = gic;
+ };
+
+ lic: interrupt-controller@60004000 {
+ compatible = nvidia,tegra114-ictlr, nvidia,tegra30-ictlr;
+ reg = 0x60004000 0x100,
+ 0x60004100 0x50,
+ 0x60004200 0x50,
+ 0x60004300 0x50,
+ 0x60004400 0x50;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
};
timer@60005000 {
@@ -766,5 +779,6 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW),
GIC_PPI 10
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW);
+ interrupt-parent = gic;
};
};
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 4be06c6..db85695 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -10,7 +10,7 @@
/ {
compatible = nvidia,tegra124;
- interrupt-parent = gic;
+ interrupt-parent = lic;
#address-cells = 2;
#size-cells = 2;
@@ -173,6 +173,7 @@
0x0 0x50046000 0x0 0x2000;
interrupts = GIC_PPI 9
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH);
+ interrupt-parent = gic;
};
gpu@0,5700 {
@@ -190,6 +191,18 @@
status = disabled;
};
+ lic: interrupt-controller@60004000 {
+ compatible = nvidia,tegra124-ictlr, nvidia,tegra30-ictlr;
+ reg = 0x0 0x60004000 0x0 0x100,
+ 0x0 0x60004100 0x0 0x100,
+ 0x0 0x60004200 0x0 0x100,
+ 0x0 0x60004300 0x0 0x100,
+ 0x0 0x60004400 0x0 0x100;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
+ };
+
timer@0,60005000 {
compatible = nvidia,tegra124-timer, nvidia,tegra20-timer;
reg = 0x0 0x60005000 0x0 0x400;
@@ -955,5 +968,6 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW),
GIC_PPI 10
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW);
+ interrupt-parent = gic;
};
};
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 8acf5d8..362bb21 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -7,7 +7,7 @@
/ {
compatible = nvidia,tegra20;
- interrupt-parent = intc;
+ interrupt-parent = lic;
host1x@5000 {
compatible = nvidia,tegra20-host1x, simple-bus;
@@ -142,6 +142,7 @@
timer@50004600 {
compatible = arm,cortex-a9-twd-timer;
+ interrupt-parent = intc;
reg = 0x50040600 0x20;
interrupts = GIC_PPI 13
(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH);
@@ -154,6 +155,7 @@
0x50040100 0x0100;
interrupt-controller;
#interrupt-cells = 3;
+ interrupt-parent = intc;
};
cache-controller@50043000 {
@@ -165,6 +167,17 @@
cache-level = 2;
};
+ lic: interrupt-controller@60004000 {
+ compatible = nvidia,tegra20-ictlr;
+ reg = 0x60004000 0x100,
+ 0x60004100 0x50,
+ 0x60004200 0x50,
+ 0x60004300 0x50;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = intc;
+ };
+
timer@60005000 {
compatible = nvidia,tegra20-timer;
reg = 0x60005000 0x60;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 99475f6..6bea674 100644
[PATCH v4 06/21] ARM: tegra: remove old LIC support
Now that all DTs have been updated, entierely drop support for
the non-DT code.
This is likely to break platforms that do not update their DT,
so print a warning at boot time.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-tegra/iomap.h | 15
arch/arm/mach-tegra/irq.c | 201 +---
arch/arm/mach-tegra/irq.h | 6 --
3 files changed, 2 insertions(+), 220 deletions(-)
diff --git a/arch/arm/mach-tegra/iomap.h b/arch/arm/mach-tegra/iomap.h
index ee79808..81dc950 100644
--- a/arch/arm/mach-tegra/iomap.h
+++ b/arch/arm/mach-tegra/iomap.h
@@ -31,21 +31,6 @@
#define TEGRA_ARM_INT_DIST_BASE0x50041000
#define TEGRA_ARM_INT_DIST_SIZESZ_4K
-#define TEGRA_PRIMARY_ICTLR_BASE 0x60004000
-#define TEGRA_PRIMARY_ICTLR_SIZE SZ_64
-
-#define TEGRA_SECONDARY_ICTLR_BASE 0x60004100
-#define TEGRA_SECONDARY_ICTLR_SIZE SZ_64
-
-#define TEGRA_TERTIARY_ICTLR_BASE 0x60004200
-#define TEGRA_TERTIARY_ICTLR_SIZE SZ_64
-
-#define TEGRA_QUATERNARY_ICTLR_BASE0x60004300
-#define TEGRA_QUATERNARY_ICTLR_SIZESZ_64
-
-#define TEGRA_QUINARY_ICTLR_BASE 0x60004400
-#define TEGRA_QUINARY_ICTLR_SIZE SZ_64
-
#define TEGRA_TMR1_BASE0x60005000
#define TEGRA_TMR1_SIZESZ_8
diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c
index 1593c4c..3b9098d 100644
--- a/arch/arm/mach-tegra/irq.c
+++ b/arch/arm/mach-tegra/irq.c
@@ -30,43 +30,9 @@
#include board.h
#include iomap.h
-#define ICTLR_CPU_IEP_VFIQ 0x08
-#define ICTLR_CPU_IEP_FIR 0x14
-#define ICTLR_CPU_IEP_FIR_SET 0x18
-#define ICTLR_CPU_IEP_FIR_CLR 0x1c
-
-#define ICTLR_CPU_IER 0x20
-#define ICTLR_CPU_IER_SET 0x24
-#define ICTLR_CPU_IER_CLR 0x28
-#define ICTLR_CPU_IEP_CLASS0x2C
-
-#define ICTLR_COP_IER 0x30
-#define ICTLR_COP_IER_SET 0x34
-#define ICTLR_COP_IER_CLR 0x38
-#define ICTLR_COP_IEP_CLASS0x3c
-
-#define FIRST_LEGACY_IRQ 32
-#define TEGRA_MAX_NUM_ICTLRS 5
-
#define SGI_MASK 0x
-static int num_ictlrs;
-
-static void __iomem *ictlr_reg_base[] = {
- IO_ADDRESS(TEGRA_PRIMARY_ICTLR_BASE),
- IO_ADDRESS(TEGRA_SECONDARY_ICTLR_BASE),
- IO_ADDRESS(TEGRA_TERTIARY_ICTLR_BASE),
- IO_ADDRESS(TEGRA_QUATERNARY_ICTLR_BASE),
- IO_ADDRESS(TEGRA_QUINARY_ICTLR_BASE),
-};
-
#ifdef CONFIG_PM_SLEEP
-static u32 cop_ier[TEGRA_MAX_NUM_ICTLRS];
-static u32 cop_iep[TEGRA_MAX_NUM_ICTLRS];
-static u32 cpu_ier[TEGRA_MAX_NUM_ICTLRS];
-static u32 cpu_iep[TEGRA_MAX_NUM_ICTLRS];
-
-static u32 ictlr_wake_mask[TEGRA_MAX_NUM_ICTLRS];
static void __iomem *tegra_gic_cpu_base;
#endif
@@ -83,140 +49,7 @@ bool tegra_pending_sgi(void)
return false;
}
-static inline void tegra_irq_write_mask(unsigned int irq, unsigned long reg)
-{
- void __iomem *base;
- u32 mask;
-
- BUG_ON(irq FIRST_LEGACY_IRQ ||
- irq = FIRST_LEGACY_IRQ + num_ictlrs * 32);
-
- base = ictlr_reg_base[(irq - FIRST_LEGACY_IRQ) / 32];
- mask = BIT((irq - FIRST_LEGACY_IRQ) % 32);
-
- __raw_writel(mask, base + reg);
-}
-
-static void tegra_mask(struct irq_data *d)
-{
- if (d-hwirq FIRST_LEGACY_IRQ)
- return;
-
- tegra_irq_write_mask(d-hwirq, ICTLR_CPU_IER_CLR);
-}
-
-static void tegra_unmask(struct irq_data *d)
-{
- if (d-hwirq FIRST_LEGACY_IRQ)
- return;
-
- tegra_irq_write_mask(d-hwirq, ICTLR_CPU_IER_SET);
-}
-
-static void tegra_ack(struct irq_data *d)
-{
- if (d-hwirq FIRST_LEGACY_IRQ)
- return;
-
- tegra_irq_write_mask(d-hwirq, ICTLR_CPU_IEP_FIR_CLR);
-}
-
-static void tegra_eoi(struct irq_data *d)
-{
- if (d-hwirq FIRST_LEGACY_IRQ)
- return;
-
- tegra_irq_write_mask(d-hwirq, ICTLR_CPU_IEP_FIR_CLR);
-}
-
-static int tegra_retrigger(struct irq_data *d)
-{
- if (d-hwirq FIRST_LEGACY_IRQ)
- return 0;
-
- tegra_irq_write_mask(d-hwirq, ICTLR_CPU_IEP_FIR_SET);
-
- return 1;
-}
-
#ifdef CONFIG_PM_SLEEP
-static int tegra_set_wake(struct irq_data *d, unsigned int enable)
-{
- u32 irq = d-hwirq;
- u32 index, mask;
-
- if (irq FIRST_LEGACY_IRQ ||
- irq = FIRST_LEGACY_IRQ + num_ictlrs * 32)
- return -EINVAL;
-
- index = ((irq - FIRST_LEGACY_IRQ) / 32);
- mask = BIT((irq - FIRST_LEGACY_IRQ) % 32);
- if (enable)
- ictlr_wake_mask[index] |= mask;
- else
- ictlr_wake_mask[index] = ~mask;
-
- return 0;
-}
-
-static int tegra_legacy_irq_suspend(void)
-{
- unsigned long flags;
- int i;
-
- local_irq_save(flags);
- for (i = 0; i num_ictlrs; i++) {
- void __iomem *ictlr = ictlr_reg_base[i];
- /* Save interrupt state */
- cpu_ier[i] = readl_relaxed(ictlr + ICTLR_CPU_IER);
- cpu_iep[i
[PATCH v4 05/21] DT: tegra: add binding for the legacy interrupt controller
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
.../interrupt-controller/nvidia,tegra-ictlr.txt| 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra-ictlr.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra-ictlr.txt
b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra-ictlr.txt
new file mode 100644
index 000..1099fe0
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra-ictlr.txt
@@ -0,0 +1,43 @@
+NVIDIA Legacy Interrupt Controller
+
+All Tegra SoCs contain a legacy interrupt controller that routes
+interrupts to the GIC, and also serves as a wakeup source. It is also
+referred to as ictlr, hence the name of the binding.
+
+The HW block exposes a number of interrupt controllers, each
+implementing a set of 32 interrupts.
+
+Required properties:
+
+- compatible : should be: nvidia,tegrachip-ictlr. The LIC on
+ subsequent SoCs remained backwards-compatible with Tegra30, so on
+ Tegra generations later than Tegra30 the compatible value should
+ include nvidia,tegra30-ictlr.
+- reg : Specifies base physical address and size of the registers.
+ Each controller must be described separately (Tegra20 has 4 of them,
+ whereas Tegra30 and later have 5
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value must be 3.
+- interrupt-parent : a phandle to the GIC these interrupts are routed
+ to.
+
+Notes:
+
+- Because this HW ultimately routes interrupts to the GIC, the
+ interrupt specifier must be that of the GIC.
+- Only SPIs can use the ictlr as an interrupt parent. SGIs and PPIs
+ are explicitly forbidden.
+
+Example:
+
+ ictlr: interrupt-controller@60004000 {
+ compatible = nvidia,tegra20-ictlr, nvidia,tegra-ictlr;
+ reg = 0x60004000 64,
+ 0x60004100 64,
+ 0x60004200 64,
+ 0x60004300 64;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = intc;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 09/21] DT: update ti,irq-crossbar binding
Make it look like a real interrupt controller.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 4139db3..a9b28d7 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -9,7 +9,9 @@ inputs.
Required properties:
- compatible : Should be ti,irq-crossbar
- reg: Base address and the size of the crossbar registers.
-- ti,max-irqs: Total number of irqs available at the interrupt controller.
+- interrupt-controller: indicates that this block is an interrupt controller.
+- interrupt-parent: the interrupt controller this block is connected to.
+- ti,max-irqs: Total number of irqs available at the parent interrupt
controller.
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be
routed.
- ti,reg-size: Size of a individual register in bytes. Every individual
register is assumed to be of same size. Valid sizes are 1, 2, 4.
@@ -27,13 +29,13 @@ Optional properties:
when the interrupt controller irq is unused (when not provided, default is 0)
Examples:
- crossbar_mpu: @4a02 {
+ crossbar_mpu: crossbar@4a002a48 {
compatible = ti,irq-crossbar;
reg = 0x4a002a48 0x130;
ti,max-irqs = 160;
ti,max-crossbar-sources = 400;
ti,reg-size = 2;
- ti,irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+ ti,irqs-reserved = 0 1 2 3 5 6 131 132;
ti,irqs-skip = 10 133 139 140;
};
@@ -44,10 +46,6 @@ Documentation/devicetree/bindings/arm/gic.txt for further
details.
An interrupt consumer on an SoC using crossbar will use:
interrupts = GIC_SPI request_number interrupt_level
-When the request number is between 0 to that described by
-ti,max-crossbar-sources, it is assumed to be a crossbar mapping. If the
-request_number is greater than ti,max-crossbar-sources, then it is mapped as
a
-quirky hardware mapping direct to GIC.
Example:
device_x@0x4a023000 {
@@ -55,9 +53,3 @@ Example:
interrupts = GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH;
...
};
-
- device_y@0x4a033000 {
- /* Direct mapped GIC SPI 1 used */
- interrupts = GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH;
- ...
- };
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 16/21] DT: exynos: update PMU binding
Document the fact that some Exynos PMUs are capable of acting as
an interrupt controller.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
Documentation/devicetree/bindings/arm/samsung/pmu.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 1e1979b..d698e74 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -28,10 +28,23 @@ Properties:
- clocks : list of phandles and specifiers to all input clocks listed in
clock-names property.
+Optional properties:
+
+Some PMUs are capable of behaving as an interrupt controller (mostly
+to wake up a suspended PMU). In which case, they can have the
+following properties:
+
+- interrupt-controller: indicate that said PMU is an interrupt controller
+
+- interrupt-parent: a phandle indicating which interrupt controller
+ this PMU signals interrupts to.
+
Example :
pmu_system_controller: system-controller@1004 {
compatible = samsung,exynos5250-pmu, syscon;
reg = 0x1004 0x5000;
+ interrupt-controller;
+ interrupt-parent = gic;
#clock-cells = 1;
clock-names = clkout0, clkout1, clkout2, clkout3,
clkout4, clkout8, clkout9;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 14/21] ARM: imx6: convert GPC to stacked domains
IMX6 has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the fact that the GPC block is actually the first
interrupt controller in the chain, kernels with this patch
applied wont have any suspend-resume facility when booted
with old DTs, and old kernels with updated DTs won't even boot.
Tested-by: Stefan Agner ste...@agner.ch
Acked-by: Stefan Agner ste...@agner.ch
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/imx6qdl.dtsi | 7 ++-
arch/arm/boot/dts/imx6sl.dtsi | 6 +-
arch/arm/boot/dts/imx6sx.dtsi | 6 +-
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/gpc.c | 127
arch/arm/mach-imx/mach-imx6q.c | 1 -
arch/arm/mach-imx/mach-imx6sl.c | 1 -
arch/arm/mach-imx/mach-imx6sx.c | 1 -
8 files changed, 119 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 4fc03b7..aff9ded 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -53,6 +53,7 @@
interrupt-controller;
reg = 0x00a01000 0x1000,
0x00a00100 0x100;
+ interrupt-parent = intc;
};
clocks {
@@ -82,7 +83,7 @@
#address-cells = 1;
#size-cells = 1;
compatible = simple-bus;
- interrupt-parent = intc;
+ interrupt-parent = gpc;
ranges;
dma_apbh: dma-apbh@0011 {
@@ -122,6 +123,7 @@
compatible = arm,cortex-a9-twd-timer;
reg = 0x00a00600 0x20;
interrupts = 1 13 0xf01;
+ interrupt-parent = intc;
clocks = clks IMX6QDL_CLK_TWD;
};
@@ -694,8 +696,11 @@
gpc: gpc@020dc000 {
compatible = fsl,imx6q-gpc;
reg = 0x020dc000 0x4000;
+ interrupt-controller;
+ #interrupt-cells = 3;
interrupts = 0 89 IRQ_TYPE_LEVEL_HIGH,
0 90 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-parent = intc;
};
gpr: iomuxc-gpr@020e {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 36ab8e0..0d0962b 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -72,6 +72,7 @@
interrupt-controller;
reg = 0x00a01000 0x1000,
0x00a00100 0x100;
+ interrupt-parent = intc;
};
clocks {
@@ -95,7 +96,7 @@
#address-cells = 1;
#size-cells = 1;
compatible = simple-bus;
- interrupt-parent = intc;
+ interrupt-parent = gpc;
ranges;
ocram: sram@0090 {
@@ -603,7 +604,10 @@
gpc: gpc@020dc000 {
compatible = fsl,imx6sl-gpc, fsl,imx6q-gpc;
reg = 0x020dc000 0x4000;
+ interrupt-controller;
+ #interrupt-cells = 3;
interrupts = 0 89 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-parent = intc;
};
gpr: iomuxc-gpr@020e {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 7a24fee..dabaf89 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -88,6 +88,7 @@
interrupt-controller;
reg = 0x00a01000 0x1000,
0x00a00100 0x100;
+ interrupt-parent = intc;
};
clocks {
@@ -131,7 +132,7 @@
#address-cells = 1;
#size-cells = 1;
compatible = simple-bus;
- interrupt-parent = intc;
+ interrupt-parent = gpc;
ranges;
pmu {
@@ -700,7 +701,10 @@
gpc: gpc@020dc000 {
compatible = fsl,imx6sx-gpc, fsl,imx6q-gpc;
reg = 0x020dc000 0x4000;
+ interrupt-controller;
+ #interrupt-cells = 3;
interrupts = GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-parent = intc;
};
iomuxc: iomuxc@020e {
diff --git
[PATCH v4 15/21] ARM: exynos4/5: convert pmu wakeup to stacked domains
Exynos has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the fact that the PMU block is actually the first
interrupt controller in the chain for RTC, kernels with this patch
applied wont have any suspend-resume facility when booted
with old DTs, and old kernels with updated DTs may not even boot.
Also, I stronly suspect that there is more than two wake-up
interrupts on these platforms, but I leave it to the maintainers
to fix their mess.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/exynos4.dtsi| 4 ++
arch/arm/boot/dts/exynos5250.dtsi | 4 ++
arch/arm/boot/dts/exynos5420.dtsi | 4 ++
arch/arm/mach-exynos/exynos.c | 14 ++---
arch/arm/mach-exynos/suspend.c| 122 ++
5 files changed, 129 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index b8168f1..0e7d74e 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -141,6 +141,9 @@
pmu_system_controller: system-controller@1002 {
compatible = samsung,exynos4210-pmu, syscon;
reg = 0x1002 0x4000;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
};
dsi_0: dsi@11C8 {
@@ -253,6 +256,7 @@
rtc@1007 {
compatible = samsung,s3c6410-rtc;
reg = 0x1007 0x100;
+ interrupt-parent = pmu_system_controller;
interrupts = 0 44 0, 0 45 0;
clocks = clock CLK_RTC;
clock-names = rtc;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a229fc..1dc5f6b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -194,6 +194,9 @@
clock-names = clkout16;
clocks = clock CLK_FIN_PLL;
#clock-cells = 1;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
};
sysreg_system_controller: syscon@1005 {
@@ -230,6 +233,7 @@
rtc: rtc@101E {
clocks = clock CLK_RTC;
clock-names = rtc;
+ interrupt-parent = pmu_system_controller;
status = disabled;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 517e50f..35ecd36 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -309,6 +309,7 @@
rtc: rtc@101E {
clocks = clock CLK_RTC;
clock-names = rtc;
+ interrupt-parent = pmu_system_controller;
status = disabled;
};
@@ -748,6 +749,9 @@
clock-names = clkout16;
clocks = clock CLK_FIN_PLL;
#clock-cells = 1;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
};
sysreg_system_controller: syscon@1005 {
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index c13d083..e417fdc 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -175,16 +175,15 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+/*
+ * Apparently, these SoCs are not able to wake-up from suspend using
+ * the PMU. Too bad. Should they suddenly become capable of such a
+ * feat, the matches below should be moved to suspend.c.
+ */
static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = samsung,exynos3250-pmu },
- { .compatible = samsung,exynos4210-pmu },
- { .compatible = samsung,exynos4212-pmu },
- { .compatible = samsung,exynos4412-pmu },
- { .compatible = samsung,exynos4415-pmu },
- { .compatible = samsung,exynos5250-pmu },
{ .compatible = samsung,exynos5260-pmu },
{ .compatible = samsung,exynos5410-pmu },
- { .compatible = samsung,exynos5420-pmu },
{ /*sentinel*/ },
};
@@ -195,9 +194,6 @@ static void exynos_map_pmu(void)
np = of_find_matching_node(NULL, exynos_dt_pmu_match);
if (np)
pmu_base_addr = of_iomap(np, 0);
-
- if (!pmu_base_addr)
- panic(failed to find exynos pmu register\n);
}
static void __init exynos_init_irq(void)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index f8e7dcd..b325ecd 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -18,7 +18,9 @@
#include linux/syscore_ops.h
#include linux/cpu_pm.h
#include linux/io.h
[PATCH v4 11/21] DT: arm,gic: kill arm,routable-irqs
Nobody will regret it.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
Documentation/devicetree/bindings/arm/gic.txt | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt
b/Documentation/devicetree/bindings/arm/gic.txt
index 8112d0c..631cb71 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -52,11 +52,6 @@ Optional
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
-- arm,routable-irqs : Total number of gic irq inputs which are not directly
- connected from the peripherals, but are routed dynamically
- by a crossbar/multiplexer preceding the GIC. The GIC irq
- input line is assigned dynamically when the corresponding
- peripheral's crossbar line is mapped.
Example:
intc: interrupt-controller@fff11000 {
@@ -64,7 +59,6 @@ Example:
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
- arm,routable-irqs = 160;
reg = 0xfff11000 0x1000,
0xfff10100 0x100;
};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 10/21] irqchip: GIC: get rid of routable domain
The only user of the so called routable domain functionality
now being fixed, let's clean up the GIC.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-gic.c | 59 -
include/linux/irqchip/arm-gic.h | 6 -
2 files changed, 5 insertions(+), 60 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d617ee5..9c30a76 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -795,15 +795,12 @@ static int gic_irq_domain_map(struct irq_domain *d,
unsigned int irq,
irq_domain_set_info(d, irq, hw, gic_chip, d-host_data,
handle_fasteoi_irq, NULL, NULL);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
-
- gic_routable_irq_domain_ops-map(d, irq, hw);
}
return 0;
}
static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
{
- gic_routable_irq_domain_ops-unmap(d, irq);
}
static int gic_irq_domain_xlate(struct irq_domain *d,
@@ -822,16 +819,8 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
*out_hwirq = intspec[1] + 16;
/* For SPIs, we need to add 16 more to get the GIC irq ID number */
- if (!intspec[0]) {
- ret = gic_routable_irq_domain_ops-xlate(d, controller,
-intspec,
-intsize,
-out_hwirq,
-out_type);
-
- if (IS_ERR_VALUE(ret))
- return ret;
- }
+ if (!intspec[0])
+ *out_hwirq += 16;
*out_type = intspec[2] IRQ_TYPE_SENSE_MASK;
@@ -888,37 +877,6 @@ static const struct irq_domain_ops gic_irq_domain_ops = {
.xlate = gic_irq_domain_xlate,
};
-/* Default functions for routable irq domain */
-static int gic_routable_irq_domain_map(struct irq_domain *d, unsigned int irq,
- irq_hw_number_t hw)
-{
- return 0;
-}
-
-static void gic_routable_irq_domain_unmap(struct irq_domain *d,
- unsigned int irq)
-{
-}
-
-static int gic_routable_irq_domain_xlate(struct irq_domain *d,
- struct device_node *controller,
- const u32 *intspec, unsigned int intsize,
- unsigned long *out_hwirq,
- unsigned int *out_type)
-{
- *out_hwirq += 16;
- return 0;
-}
-
-static const struct irq_domain_ops gic_default_routable_irq_domain_ops = {
- .map = gic_routable_irq_domain_map,
- .unmap = gic_routable_irq_domain_unmap,
- .xlate = gic_routable_irq_domain_xlate,
-};
-
-const struct irq_domain_ops *gic_routable_irq_domain_ops =
- gic_default_routable_irq_domain_ops;
-
void __init gic_init_bases(unsigned int gic_nr, int irq_start,
void __iomem *dist_base, void __iomem *cpu_base,
u32 percpu_offset, struct device_node *node)
@@ -926,7 +884,6 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
irq_hw_number_t hwirq_base;
struct gic_chip_data *gic;
int gic_irqs, irq_base, i;
- int nr_routable_irqs;
BUG_ON(gic_nr = MAX_GIC_NR);
@@ -982,15 +939,9 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
gic-gic_irqs = gic_irqs;
if (node) { /* DT case */
- const struct irq_domain_ops *ops =
gic_irq_domain_hierarchy_ops;
-
- if (!of_property_read_u32(node, arm,routable-irqs,
- nr_routable_irqs)) {
- ops = gic_irq_domain_ops;
- gic_irqs = nr_routable_irqs;
- }
-
- gic-domain = irq_domain_add_linear(node, gic_irqs, ops, gic);
+ gic-domain = irq_domain_add_linear(node, gic_irqs,
+
gic_irq_domain_hierarchy_ops,
+ gic);
} else {/* Non-DT case */
/*
* For primary GICs, skip over SGIs.
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 71d706d..3978c5b 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -115,11 +115,5 @@ int gic_get_cpu_id(unsigned int cpu);
void gic_migrate_target(unsigned int new_cpu_id);
unsigned long gic_get_sgir_physaddr(void);
-extern const struct irq_domain_ops *gic_routable_irq_domain_ops;
-static inline void __init register_routable_domain_ops
- (const struct irq_domain_ops *ops)
-{
- gic_routable_irq_domain_ops = ops
[PATCH v4 03/21] ARM: tegra: skip gic_arch_extn setup if DT has a LIC node
If we detect that our DT has a LIC node, don't setup gic_arch_extn,
and skip tegra_legacy_irq_syscore_init as well.
This is only a temporary measure until that code is removed for good.
Acked-by: Thierry Reding tred...@nvidia.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-tegra/irq.c | 12
arch/arm/mach-tegra/tegra.c | 1 -
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c
index 7f87a50..1593c4c 100644
--- a/arch/arm/mach-tegra/irq.c
+++ b/arch/arm/mach-tegra/irq.c
@@ -255,11 +255,22 @@ static void tegra114_gic_cpu_pm_registration(void)
static void tegra114_gic_cpu_pm_registration(void) { }
#endif
+static const struct of_device_id tegra_ictlr_match[] __initconst = {
+ { .compatible = nvidia,tegra20-ictlr },
+ { .compatible = nvidia,tegra30-ictlr },
+ { }
+};
+
void __init tegra_init_irq(void)
{
int i;
void __iomem *distbase;
+ if (of_find_matching_node(NULL, tegra_ictlr_match))
+ goto skip_extn_setup;
+
+ tegra_legacy_irq_syscore_init();
+
distbase = IO_ADDRESS(TEGRA_ARM_INT_DIST_BASE);
num_ictlrs = readl_relaxed(distbase + GIC_DIST_CTR) 0x1f;
@@ -283,5 +294,6 @@ void __init tegra_init_irq(void)
gic_arch_extn.irq_set_wake = tegra_set_wake;
gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
+skip_extn_setup:
tegra114_gic_cpu_pm_registration();
}
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index ef016af..c33fba7 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -82,7 +82,6 @@ static void __init tegra_dt_init_irq(void)
{
tegra_init_irq();
irqchip_init();
- tegra_legacy_irq_syscore_init();
}
static void __init tegra_dt_init(void)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
OMAP4/5 has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the WUGEN HW block, kernels with this patch applied
won't have any suspend-resume facility when booted with old DTs,
and old kernels with updated DTs won't even boot.
On a platform with this patch applied, the system looks like
this:
root@bacon-fat:~# cat /proc/interrupts
CPU0 CPU1
16: 0 0 WUGEN 37 gp_timer
19: 233799 155916 GIC 27 arch_timer
23: 0 0 WUGEN 9 l3-dbg-irq
24: 1 0 WUGEN 10 l3-app-irq
27:282 0 WUGEN 13 omap-dma-engine
44: 0 0 4ae1.gpio 13 DMA
294: 0 0 WUGEN 20 gpmc
297:506 0 WUGEN 56 4807.i2c
298: 0 0 WUGEN 57 48072000.i2c
299: 0 0 WUGEN 61 4806.i2c
300: 0 0 WUGEN 62 4807a000.i2c
301: 8 0 WUGEN 60 4807c000.i2c
308: 2439 0 WUGEN 74 OMAP UART2
312:362 0 WUGEN 83 mmc2
313:502 0 WUGEN 86 mmc0
314: 13 0 WUGEN 94 mmc1
350: 0 0 PRCM pinctrl, pinctrl
406: 35155709 0 GIC 109 ehci_hcd:usb1
407: 0 0 WUGEN 7 palmas
409: 0 0 WUGEN 119 twl6040
410: 0 0 twl6040 5 twl6040_irq_ready
411: 0 0 twl6040 0 twl6040_irq_th
IPI0: 0 1 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 95334 902334 Rescheduling interrupts
IPI3: 0 0 Function call interrupts
IPI4:479648 Single function call interrupts
IPI5: 0 0 CPU stop interrupts
IPI6: 0 0 IRQ work interrupts
IPI7: 0 0 completion interrupts
Err: 0
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/am4372.dtsi | 11 ++-
arch/arm/boot/dts/am437x-gp-evm.dts | 1 -
arch/arm/boot/dts/am437x-sk-evm.dts | 1 -
arch/arm/boot/dts/am43x-epos-evm.dts | 1 -
arch/arm/boot/dts/dra7.dtsi | 12 ++-
arch/arm/boot/dts/dra72x.dtsi | 2 +-
arch/arm/boot/dts/dra74x.dtsi | 2 +-
arch/arm/boot/dts/omap4-duovero.dtsi | 2 -
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +-
arch/arm/boot/dts/omap4-sdp.dts | 8 +-
arch/arm/boot/dts/omap4-var-som-om44.dtsi | 2 -
arch/arm/boot/dts/omap4.dtsi | 18 -
arch/arm/boot/dts/omap5-cm-t54.dts| 1 -
arch/arm/boot/dts/omap5-uevm.dts | 2 -
arch/arm/boot/dts/omap5.dtsi | 26 ---
arch/arm/mach-omap2/omap-wakeupgen.c | 125 +++---
arch/arm/mach-omap2/omap-wakeupgen.h | 1 -
arch/arm/mach-omap2/omap4-common.c| 17 ++--
18 files changed, 162 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index b62a1cd..9d672a7 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -15,7 +15,7 @@
/ {
compatible = ti,am4372, ti,am43;
- interrupt-parent = gic;
+ interrupt-parent = wakeupgen;
aliases {
@@ -48,6 +48,15 @@
#interrupt-cells = 3;
reg = 0x48241000 0x1000,
0x48240100 0x0100;
+ interrupt-parent = gic;
+ };
+
+ wakeupgen: interrupt-controller@48281000 {
+ compatible = ti,omap4-wugen-mpu;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48281000 0x1000;
+ interrupt-parent = gic;
};
l2-cache-controller@48242000 {
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 7eaae4c..69f2313 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -280,7 +280,6 @@
reg = 0x24;
compatible = ti,tps65218;
interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
- interrupt-parent = gic;
interrupt-controller;
#interrupt-cells = 2;
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 53bbfc9..029bade 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -334,7 +334,6 @@
tps@24 {
compatible = ti,tps65218;
reg = 0x24;
- interrupt-parent = gic;
interrupts = GIC_SPI 7
[PATCH v4 20/21] ARM: zynq: switch from gic_arch_extn to gic_set_irqchip_flags
Instead of directly touching gic_arch_extn, which is about to
be removed, use gic_set_irqchip_flags instead.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-zynq/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 26f92c2..82734d5 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -188,7 +188,7 @@ static void __init zynq_map_io(void)
static void __init zynq_irq_init(void)
{
- gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND;
+ gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND);
irqchip_init();
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 12/21] DT: omap4/5: add binding for the wake-up generator
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
.../interrupt-controller/ti,omap4-wugen-mpu| 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
new file mode 100644
index 000..43effa0
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
@@ -0,0 +1,33 @@
+TI OMAP4 Wake-up Generator
+
+All TI OMAP4/5 (and their derivatives) an interrupt controller that
+routes interrupts to the GIC, and also serves as a wakeup source. It
+is also referred to as WUGEN-MPU, hence the name of the binding.
+
+Reguired properties:
+
+- compatible : should contain at least ti,omap4-wugen-mpu or
+ ti,omap5-wugen-mpu
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value must be 3.
+- interrupt-parent : a phandle to the GIC these interrupts are routed
+ to.
+
+Notes:
+
+- Because this HW ultimately routes interrupts to the GIC, the
+ interrupt specifier must be that of the GIC.
+- Only SPIs can use the WUGEN as an interrupt parent. SGIs and PPIs
+ are explicitly forbiden.
+
+Example:
+
+ wakeupgen: interrupt-controller@48281000 {
+ compatible = ti,omap5-wugen-mpu, ti,omap4-wugen-mpu;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48281000 0x1000;
+ interrupt-parent = gic;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 18/21] ARM: shmobile: remove use of gic_arch_extn.irq_set_wake
shmobile only uses gic_arch_extn.irq_set_wake to prevent the GIC
from returning -ENXIO when receiving a wake-up configuration request.
It is a lot simpler to tell the irq layer that we don't need any
configuration by using the IRQCHIP_SKIP_SET_WAKE, thanks to the
new gic_set_irqchip_flags function.
Acked-by: Simon Horman horms+rene...@verge.net.au
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-shmobile/intc-sh73a0.c | 7 +--
arch/arm/mach-shmobile/setup-r8a7779.c | 7 +--
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-shmobile/intc-sh73a0.c
b/arch/arm/mach-shmobile/intc-sh73a0.c
index 9e36180..fd63ae6 100644
--- a/arch/arm/mach-shmobile/intc-sh73a0.c
+++ b/arch/arm/mach-shmobile/intc-sh73a0.c
@@ -252,11 +252,6 @@ static irqreturn_t sh73a0_intcs_demux(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static int sh73a0_set_wake(struct irq_data *data, unsigned int on)
-{
- return 0; /* always allow wakeup */
-}
-
#define PINTER0_PHYS 0xe69000a0
#define PINTER1_PHYS 0xe69000a4
#define PINTER0_VIRT IOMEM(0xe69000a0)
@@ -318,8 +313,8 @@ void __init sh73a0_init_irq(void)
void __iomem *gic_cpu_base = IOMEM(0xf100);
void __iomem *intevtsa = ioremap_nocache(0xffd20100, PAGE_SIZE);
+ gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE);
gic_init(0, 29, gic_dist_base, gic_cpu_base);
- gic_arch_extn.irq_set_wake = sh73a0_set_wake;
register_intc_controller(intcs_desc);
register_intc_controller(intc_pint0_desc);
diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c
b/arch/arm/mach-shmobile/setup-r8a7779.c
index 6156d17..989de2d 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -713,14 +713,9 @@ void __init r8a7779_init_late(void)
}
#ifdef CONFIG_USE_OF
-static int r8a7779_set_wake(struct irq_data *data, unsigned int on)
-{
- return 0; /* always allow wakeup */
-}
-
void __init r8a7779_init_irq_dt(void)
{
- gic_arch_extn.irq_set_wake = r8a7779_set_wake;
+ gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE);
irqchip_init();
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
