[PATCH 4/5] ARCv2: Elide sending new cross core intr if receiver didn't ack prev
ARConnect/MCIP IPI sending has a retry-wait loop in case caller had
not seen a previous such interrupt. Turns out that it is not needed at
all. Linux cross core calling allows coalescing multiple IPIs to same
receiver - it is fine as long as there is one.
This logic is built into upper layer already, at a higher level of
abstraction. ipi_send_msg_one() sets the actual msg payload, but it only
calls MCIP IPI sending if msg holder was empty (using
atomic-set-new-and-get-old construct). Thus it is unlikely that the
retry-wait looping was ever getting exercised at all.
Cc: Chuck Jordan
Cc: Peter Zijlstra
Signed-off-by: Vineet Gupta
---
arch/arc/kernel/mcip.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c
index e30d5d428330..7afc3c703ed1 100644
--- a/arch/arc/kernel/mcip.c
+++ b/arch/arc/kernel/mcip.c
@@ -40,26 +40,19 @@ static void mcip_ipi_send(int cpu)
return;
}
+ raw_spin_lock_irqsave(&mcip_lock, flags);
+
/*
-* NOTE: We must spin here if the other cpu hasn't yet
-* serviced a previous message. This can burn lots
-* of time, but we MUST follows this protocol or
-* ipi messages can be lost!!!
-* Also, we must release the lock in this loop because
-* the other side may get to this same loop and not
-* be able to ack -- thus causing deadlock.
+* If receiver already has a pending interrupt, elide sending this one.
+* Linux cross core calling works well with concurrent IPIs
+* coalesced into one
+* see arch/arc/kernel/smp.c: ipi_send_msg_one()
*/
+ __mcip_cmd(CMD_INTRPT_READ_STATUS, cpu);
+ ipi_was_pending = read_aux_reg(ARC_REG_MCIP_READBACK);
+ if (!ipi_was_pending)
+ __mcip_cmd(CMD_INTRPT_GENERATE_IRQ, cpu);
- do {
- raw_spin_lock_irqsave(&mcip_lock, flags);
- __mcip_cmd(CMD_INTRPT_READ_STATUS, cpu);
- ipi_was_pending = read_aux_reg(ARC_REG_MCIP_READBACK);
- if (ipi_was_pending == 0)
- break; /* break out but keep lock */
- raw_spin_unlock_irqrestore(&mcip_lock, flags);
- } while (1);
-
- __mcip_cmd(CMD_INTRPT_GENERATE_IRQ, cpu);
raw_spin_unlock_irqrestore(&mcip_lock, flags);
#ifdef CONFIG_ARC_IPI_DBG
--
2.5.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 0/5] ARC IPI related fix
Hi, This cam eout of debugging a csd deadlock on ARC. The fix itself is 1/5, rest of patches are additional improvements, optimizations while we are at it. Thx, -Vineet Vineet Gupta (5): ARCv2: SMP: Emulate IPI to self using software triggered interrupt ARC: [intc-compact] Remove IPI setup from ARCompact port ARCv2: SMP: Push IPI_IRQ into IPI provider ARCv2: Elide sending new cross core intr if receiver didn't ack prev ARC: SMP: No need for CONFIG_ARC_IPI_DBG arch/arc/Kconfig | 8 -- arch/arc/include/asm/irq.h| 2 -- arch/arc/include/asm/irqflags-arcv2.h | 11 arch/arc/kernel/intc-compact.c| 3 -- arch/arc/kernel/mcip.c| 52 ++- arch/arc/kernel/smp.c | 3 -- 6 files changed, 38 insertions(+), 41 deletions(-) -- 2.5.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/5] ARCv2: SMP: Emulate IPI to self using software triggered interrupt
ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to
local core. So use core intc capability to trigger software
interrupt to self, using an unsued IRQ #21.
This showed up as csd deadlock with LTP trace_sched on a dual core
system. This test acts as scheduler fuzzer, triggering all sorts of
schedulting activity. Trouble starts with IPI to self, which doesn't get
delivered (effectively lost due to H/w capability), but the msg intended
to be sent remain enqueued in per-cpu @ipi_data.
All subsequent IPIs to this core from other cores get elided due to the
IPI coalescing optimization in ipi_send_msg_one() where a pending msg
implies an IPI already sent and assumes other core is yet to ack it.
After the elided IPI, other core simply goes into csd_lock_wait()
but never comes out as this core never sees the interrupt.
Fixes STAR 9001008624
Cc: Peter Zijlstra
Cc: [4.2]
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/irqflags-arcv2.h | 11 +++
arch/arc/kernel/mcip.c| 15 +++
2 files changed, 26 insertions(+)
diff --git a/arch/arc/include/asm/irqflags-arcv2.h
b/arch/arc/include/asm/irqflags-arcv2.h
index 1fc18ee06cf2..37c2f751eebf 100644
--- a/arch/arc/include/asm/irqflags-arcv2.h
+++ b/arch/arc/include/asm/irqflags-arcv2.h
@@ -22,6 +22,7 @@
#define AUX_IRQ_CTRL 0x00E
#define AUX_IRQ_ACT0x043 /* Active Intr across all levels */
#define AUX_IRQ_LVL_PEND 0x200 /* Pending Intr across all levels */
+#define AUX_IRQ_HINT 0x201 /* For generating Soft Interrupts */
#define AUX_IRQ_PRIORITY 0x206
#define ICAUSE 0x40a
#define AUX_IRQ_SELECT 0x40b
@@ -115,6 +116,16 @@ static inline int arch_irqs_disabled(void)
return arch_irqs_disabled_flags(arch_local_save_flags());
}
+static inline void arc_softirq_trigger(int irq)
+{
+ write_aux_reg(AUX_IRQ_HINT, irq);
+}
+
+static inline void arc_softirq_clear(int irq)
+{
+ write_aux_reg(AUX_IRQ_HINT, 0);
+}
+
#else
.macro IRQ_DISABLE scratch
diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c
index 002c5fcf8947..9e1bd03b87a6 100644
--- a/arch/arc/kernel/mcip.c
+++ b/arch/arc/kernel/mcip.c
@@ -11,9 +11,12 @@
#include
#include
#include
+#include
#include
#include
+#define SOFTIRQ_IRQ21
+
static char smp_cpuinfo_buf[128];
static int idu_detected;
@@ -22,6 +25,7 @@ static DEFINE_RAW_SPINLOCK(mcip_lock);
static void mcip_setup_per_cpu(int cpu)
{
smp_ipi_irq_setup(cpu, IPI_IRQ);
+ smp_ipi_irq_setup(cpu, SOFTIRQ_IRQ);
}
static void mcip_ipi_send(int cpu)
@@ -29,6 +33,12 @@ static void mcip_ipi_send(int cpu)
unsigned long flags;
int ipi_was_pending;
+ /* ARConnect can only send IPI to others */
+ if (unlikely(cpu == raw_smp_processor_id())) {
+ arc_softirq_trigger(SOFTIRQ_IRQ);
+ return;
+ }
+
/*
* NOTE: We must spin here if the other cpu hasn't yet
* serviced a previous message. This can burn lots
@@ -63,6 +73,11 @@ static void mcip_ipi_clear(int irq)
unsigned long flags;
unsigned int __maybe_unused copy;
+ if (unlikely(irq == SOFTIRQ_IRQ)) {
+ arc_softirq_clear(irq);
+ return;
+ }
+
raw_spin_lock_irqsave(&mcip_lock, flags);
/* Who sent the IPI */
--
2.5.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 3/5] ARCv2: SMP: Push IPI_IRQ into IPI provider
Signed-off-by: Vineet Gupta --- arch/arc/include/asm/irq.h | 1 - arch/arc/kernel/mcip.c | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/include/asm/irq.h b/arch/arc/include/asm/irq.h index bc5103637326..49014f0ef36d 100644 --- a/arch/arc/include/asm/irq.h +++ b/arch/arc/include/asm/irq.h @@ -19,7 +19,6 @@ #else #define TIMER0_IRQ 16 #define TIMER1_IRQ 17 -#define IPI_IRQ 19 #endif #include diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c index 9e1bd03b87a6..e30d5d428330 100644 --- a/arch/arc/kernel/mcip.c +++ b/arch/arc/kernel/mcip.c @@ -15,6 +15,7 @@ #include #include +#define IPI_IRQ19 #define SOFTIRQ_IRQ21 static char smp_cpuinfo_buf[128]; -- 2.5.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 2/5] ARC: [intc-compact] Remove IPI setup from ARCompact port
There is no real ARC700 based SMP SoC so remove IPI definition.
EZChip's SMP ARC700 is going to use a different intc and IPI provider
anyways.
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/irq.h | 1 -
arch/arc/kernel/intc-compact.c | 3 ---
2 files changed, 4 deletions(-)
diff --git a/arch/arc/include/asm/irq.h b/arch/arc/include/asm/irq.h
index 4fd7d62a6e30..bc5103637326 100644
--- a/arch/arc/include/asm/irq.h
+++ b/arch/arc/include/asm/irq.h
@@ -16,7 +16,6 @@
#ifdef CONFIG_ISA_ARCOMPACT
#define TIMER0_IRQ 3
#define TIMER1_IRQ 4
-#define IPI_IRQ(NR_CPU_IRQS-1) /* dummy to enable SMP build
for up hardware */
#else
#define TIMER0_IRQ 16
#define TIMER1_IRQ 17
diff --git a/arch/arc/kernel/intc-compact.c b/arch/arc/kernel/intc-compact.c
index 06bcedf19b62..224d1c3aa9c4 100644
--- a/arch/arc/kernel/intc-compact.c
+++ b/arch/arc/kernel/intc-compact.c
@@ -81,9 +81,6 @@ static int arc_intc_domain_map(struct irq_domain *d, unsigned
int irq,
{
switch (irq) {
case TIMER0_IRQ:
-#ifdef CONFIG_SMP
- case IPI_IRQ:
-#endif
irq_set_chip_and_handler(irq, &onchip_intc, handle_percpu_irq);
break;
default:
--
2.5.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5/5] ARC: SMP: No need for CONFIG_ARC_IPI_DBG
This was more relevant during SMP bringup.
The warning for bogus msg better be visible always.
Signed-off-by: Vineet Gupta
---
arch/arc/Kconfig | 8
arch/arc/kernel/mcip.c | 9 +
arch/arc/kernel/smp.c | 3 ---
3 files changed, 1 insertion(+), 19 deletions(-)
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 4abc81907071..8a188bc1786a 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -532,14 +532,6 @@ config ARC_DBG_TLB_MISS_COUNT
Counts number of I and D TLB Misses and exports them via Debugfs
The counters can be cleared via Debugfs as well
-if SMP
-
-config ARC_IPI_DBG
- bool "Debug Inter Core interrupts"
- default n
-
-endif
-
endif
config ARC_UBOOT_SUPPORT
diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c
index 7afc3c703ed1..7b4af70ffd18 100644
--- a/arch/arc/kernel/mcip.c
+++ b/arch/arc/kernel/mcip.c
@@ -65,7 +65,6 @@ static void mcip_ipi_clear(int irq)
{
unsigned int cpu, c;
unsigned long flags;
- unsigned int __maybe_unused copy;
if (unlikely(irq == SOFTIRQ_IRQ)) {
arc_softirq_clear(irq);
@@ -77,7 +76,7 @@ static void mcip_ipi_clear(int irq)
/* Who sent the IPI */
__mcip_cmd(CMD_INTRPT_CHECK_SOURCE, 0);
- copy = cpu = read_aux_reg(ARC_REG_MCIP_READBACK); /* 1,2,4,8... */
+ cpu = read_aux_reg(ARC_REG_MCIP_READBACK); /* 1,2,4,8... */
/*
* In rare case, multiple concurrent IPIs sent to same target can
@@ -91,12 +90,6 @@ static void mcip_ipi_clear(int irq)
} while (cpu);
raw_spin_unlock_irqrestore(&mcip_lock, flags);
-
-#ifdef CONFIG_ARC_IPI_DBG
- if (c != __ffs(copy))
- pr_info("IPIs from %x coalesced to %x\n",
- copy, raw_smp_processor_id());
-#endif
}
static void mcip_probe_n_setup(void)
diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c
index ef6e9e15b82a..424e937da5c8 100644
--- a/arch/arc/kernel/smp.c
+++ b/arch/arc/kernel/smp.c
@@ -336,11 +336,8 @@ irqreturn_t do_IPI(int irq, void *dev_id)
int rc;
rc = __do_IPI(msg);
-#ifdef CONFIG_ARC_IPI_DBG
- /* IPI received but no valid @msg */
if (rc)
pr_info("IPI with bogus msg %ld in %ld\n", msg, copy);
-#endif
pending &= ~(1U << msg);
} while (pending);
--
2.5.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Interesting csd deadlock on ARC
On Tue, Feb 23, 2016 at 10:51:42AM +0530, Vineet Gupta wrote: > On Friday 19 February 2016 12:17 PM, Vineet Gupta wrote: > > Hi Peter, > > > > I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2 > > and it > > turned out to be lot more interesting than I'd hoped for. This is stock v4.4 > > > > Trouble starts with an IPI to self which doesn't get delivered as the > > inter-core > > interrupt providing h/w is not capable of IPI to self (which I found as > > part of > > debugging this). Subsequent IPIs from other cores to this core get elided > > as well > > due to the IPI coalescing optimization in arch/arc/kernel/smp.c: > > ipi_send_msg_one() > > > > There are ways to use a different h/w mechanism to solve the trigger issue > > and I'd > > hoped to just implement arch_irq_work_raise(). Yes, there are other architectures that use other means for self-IPI, IIRC PowerPC has to program their timer in the past to generate a local interrupt. > > But the trouble is the call stack > > for this issue: IPI to self is triggered from > > > > sys_sched_setscheduler > >__balance_callback > >pull_rt_task > > irq_work_queue_on <-- called with @cpu == self > > > > Looking into irq_work.c, irq_work_queue() is what is semantically needed, > > specifically arch_irq_work_raise() will not be called, which means I need > > arch_send_call_function_single_ipi() to be able to IPI to self cpu also. Is > > that > > expected from arch code > > What I actually meant was is it OK for irq_work_queue_on() to be called > locally > (is this a sched bug/optimization(. Further if it is OK to be called, does it > need > to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or > arch_send_call_function_single_ipi() is expected to handle sending IPI to > self ! Right, so I'm not actually sure we started out with this requirement. But you're not the first to run into this, see: lkml.kernel.org/r/cajz5v0glanksuziqq25qtcynqeox43yd9jnju_xxwbdyajf...@mail.gmail.com Initially I think irq_work_queue_on() was only used remotely, but I think it makes sense to allow the current cpu, esp. since people seem to be using it like that. Now the distinct difference between arch_irq_work_raise() and arch_send_call_function_single_ipi() is that arch_irq_work_raise() should be NMI-safe. So on x86 it has to be extra careful about the lapic state, whereas the regular IPI code doesn't. I seem to have forgotten the status of NMIs on ARC, but this is something to make a note of. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Interesting csd deadlock on ARC
>> What I actually meant was is it OK for irq_work_queue_on() to be called >> locally >> (is this a sched bug/optimization(. Further if it is OK to be called, does >> it need >> to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or >> arch_send_call_function_single_ipi() is expected to handle sending IPI to >> self ! > > Right, so I'm not actually sure we started out with this requirement. > But you're not the first to run into this, see: > > > lkml.kernel.org/r/cajz5v0glanksuziqq25qtcynqeox43yd9jnju_xxwbdyajf...@mail.gmail.com Thx for the link, very helpful. I've posted fix for ARC which uses software interrupt and is thus UP/SMP safe. > Initially I think irq_work_queue_on() was only used remotely, but I > think it makes sense to allow the current cpu, esp. since people seem to > be using it like that. > > Now the distinct difference between arch_irq_work_raise() and > arch_send_call_function_single_ipi() is that arch_irq_work_raise() > should be NMI-safe. Ok - so when I implement interrupt priorities (aka NMI for ARC), this needs to be highest. > > So on x86 it has to be extra careful about the lapic state, whereas the > regular IPI code doesn't. > > I seem to have forgotten the status of NMIs on ARC, but this is > something to make a note of. Not had a chance to go back to it since we last discussed. I've just been swamped with bug fixing like this one :-( Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Interesting csd deadlock on ARC
On Tue, Feb 23, 2016 at 03:51:23PM +0530, Vineet Gupta wrote: > > > > Now the distinct difference between arch_irq_work_raise() and > > arch_send_call_function_single_ipi() is that arch_irq_work_raise() > > should be NMI-safe. > > Ok - so when I implement interrupt priorities (aka NMI for ARC), this needs > to be > highest. So on x86 the issue is that the NMI can interrupt someone else writing to the lapic. So there's a bit of extra care to be taken. If your platform doesn't suffer such issues, then that should be fine. The only requirement for irq_work is that it runs after the NMI completes and runs from regular IRQ context. There are no strict interrupt priority requirements, only that it happens. > > I seem to have forgotten the status of NMIs on ARC, but this is > > something to make a note of. > > Not had a chance to go back to it since we last discussed. > I've just been swamped with bug fixing like this one :-( Yeah, I'm familiar with the problem ... ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: Interesting csd deadlock on ARC
>From: Peter Zijlstra [mailto:pet...@infradead.org] >Sent: Tuesday, February 23, 2016 12:40 PM >The only requirement for irq_work is that it runs after the NMI completes and >runs from regular IRQ context. >There are no strict interrupt priority >requirements, only that it happens. We here already use self IPI and irq_work on ARC (with no NMI concerns). Please see patch at: https://github.com/EZchip/linux/commit/e42556738e610295f917c79dae166373cd11de88 Noam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 0/4 RESEND] Add I2S/ADV7511 audio support for ARC AXS10x boards
ARC AXS10x platforms consist of a mainboard with several peripherals. One of those peripherals is an HDMI output port controlled by ADV7511 transmitter. This patch set adds audio for the ADV7511 transmitter and I2S audio for the AXS10x platform. Jose Abreu (4): [adv7511] Add audio support [adv7511] Update defconfigs so that audio is enabled [dwc] Add I2S HDMI audio support using custom platform driver [dwc] Update defconfigs so that I2S is enabled arch/arc/boot/dts/axs10x_mb.dtsi | 20 +- arch/arc/configs/axs101_defconfig |4 + arch/arc/configs/axs103_defconfig |6 + arch/arc/configs/axs103_smp_defconfig |6 + drivers/gpu/drm/i2c/Kconfig |8 + drivers/gpu/drm/i2c/Makefile |2 + drivers/gpu/drm/i2c/adv7511.c | 1024 - drivers/gpu/drm/i2c/adv7511.h | 41 ++ drivers/gpu/drm/i2c/adv7511_audio.c | 310 ++ drivers/gpu/drm/i2c/adv7511_core.c| 1005 include/sound/soc-dai.h |1 + sound/soc/dwc/Kconfig |1 + sound/soc/dwc/Makefile|4 +- sound/soc/dwc/designware_i2s.c| 139 - sound/soc/dwc/designware_pcm.c| 264 + sound/soc/dwc/designware_pcm.h| 21 + 16 files changed, 1813 insertions(+), 1043 deletions(-) delete mode 100644 drivers/gpu/drm/i2c/adv7511.c create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c create mode 100644 sound/soc/dwc/designware_pcm.c create mode 100644 sound/soc/dwc/designware_pcm.h -- 1.9.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 2/4 RESEND] ARC: axs10x: Update defconfigs so that audio is enabled
The defconfigs for the AXS boards were updated so that ALSA SoC is enabled and also the audio for the ADV7511 HDMI transmitter. Signed-off-by: Jose Abreu --- arch/arc/configs/axs101_defconfig | 3 +++ arch/arc/configs/axs103_defconfig | 5 + arch/arc/configs/axs103_smp_defconfig | 5 + 3 files changed, 13 insertions(+) diff --git a/arch/arc/configs/axs101_defconfig b/arch/arc/configs/axs101_defconfig index e359099..7c22163 100644 --- a/arch/arc/configs/axs101_defconfig +++ b/arch/arc/configs/axs101_defconfig @@ -113,3 +113,6 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_PREEMPT is not set # CONFIG_FTRACE is not set +CONFIG_SOUND=y +CONFIG_SND=y +CONFIG_SND_SOC=y diff --git a/arch/arc/configs/axs103_defconfig b/arch/arc/configs/axs103_defconfig index 323486d..d63aef0 100644 --- a/arch/arc/configs/axs103_defconfig +++ b/arch/arc/configs/axs103_defconfig @@ -76,12 +76,14 @@ CONFIG_SERIAL_OF_PLATFORM=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_DESIGNWARE_PLATFORM=y +CONFIG_DRM=y # CONFIG_HWMON is not set CONFIG_FB=y # CONFIG_VGA_CONSOLE is not set CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_LOGO=y +CONFIG_DRM_I2C_ADV7511=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set # CONFIG_LOGO_LINUX_CLUT224 is not set @@ -114,3 +116,6 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_PREEMPT is not set # CONFIG_FTRACE is not set +CONFIG_SOUND=y +CONFIG_SND=y +CONFIG_SND_SOC=y diff --git a/arch/arc/configs/axs103_smp_defconfig b/arch/arc/configs/axs103_smp_defconfig index 66191cd..f4b51ce 100644 --- a/arch/arc/configs/axs103_smp_defconfig +++ b/arch/arc/configs/axs103_smp_defconfig @@ -77,12 +77,14 @@ CONFIG_SERIAL_OF_PLATFORM=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_DESIGNWARE_PLATFORM=y +CONFIG_DRM=y # CONFIG_HWMON is not set CONFIG_FB=y # CONFIG_VGA_CONSOLE is not set CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_LOGO=y +CONFIG_DRM_I2C_ADV7511=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set # CONFIG_LOGO_LINUX_CLUT224 is not set @@ -115,3 +117,6 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_PREEMPT is not set # CONFIG_FTRACE is not set +CONFIG_SOUND=y +CONFIG_SND=y +CONFIG_SND_SOC=y -- 1.9.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 3/4 RESEND] ASoC: dwc: Add I2S HDMI audio support using custom platform driver
HDMI audio support was added to the AXS board using an
I2S cpu driver and a custom platform driver.
The platform driver supports two channels @ 16 bits with
rates 32k, 44.1k and 48k. ALSA Simple audio card is used to
glue the cpu, platform and codec driver (adv7511).
Signed-off-by: Jose Abreu
---
arch/arc/boot/dts/axs10x_mb.dtsi | 20 ++-
sound/soc/dwc/Kconfig| 1 +
sound/soc/dwc/Makefile | 4 +-
sound/soc/dwc/designware_i2s.c | 139 +++--
sound/soc/dwc/designware_pcm.c | 264 +++
sound/soc/dwc/designware_pcm.h | 21
6 files changed, 430 insertions(+), 19 deletions(-)
create mode 100644 sound/soc/dwc/designware_pcm.c
create mode 100644 sound/soc/dwc/designware_pcm.h
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index e00e5bb..c137376 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -130,12 +130,23 @@
interrupts = <14>;
};
- i2c@0x1e000 {
- compatible = "snps,designware-i2c";
+ i2s: i2s@0x1e000 {
+ compatible = "snps,designware-i2s";
reg = <0x1e000 0x100>;
- clock-frequency = <40>;
- clocks = <&i2cclk>;
interrupts = <15>;
+ #sound-dai-cells = <0>;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "AXS10X HDMI Audio";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,cpu {
+ sound-dai = <&i2s>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&adv7511>;
+ };
};
i2c@0x1f000 {
@@ -155,6 +166,7 @@
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
adi,clock-delay = <0x03>;
+ #sound-dai-cells = <0>;
ports {
#address-cells = <1>;
diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..bc3fae7 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -2,6 +2,7 @@ config SND_DESIGNWARE_I2S
tristate "Synopsys I2S Device Driver"
depends on CLKDEV_LOOKUP
select SND_SOC_GENERIC_DMAENGINE_PCM
+ select SND_SIMPLE_CARD
help
Say Y or M if you want to add support for I2S driver for
Synopsys desigwnware I2S device. The device supports upto
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..4d8f869 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,3 @@
# SYNOPSYS Platform Support
-obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
-
+obj-$(CONFIG_SND_DESIGNWARE_I2S) += dwc_i2s.o
+dwc_i2s-y := designware_i2s.o designware_pcm.o
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index bff258d..db9aced 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -25,6 +25,8 @@
#include
#include
+#include "designware_pcm.h"
+
/* common register for all channel */
#define IER0x000
#define IRER 0x004
@@ -84,6 +86,11 @@
#define MAX_CHANNEL_NUM8
#define MIN_CHANNEL_NUM2
+/* PLL registers addresses */
+#define PLL_IDIV_ADDR 0xE00100A0
+#define PLL_FBDIV_ADDR 0xE00100A4
+#define PLL_ODIV_ADDR 0xE00100A8
+
union dw_i2s_snd_dma_data {
struct i2s_dma_data pd;
struct snd_dmaengine_dai_dma_data dt;
@@ -100,12 +107,32 @@ struct dw_i2s_dev {
struct device *dev;
u32 ccr;
u32 xfer_resolution;
+ u32 xfer_bytes;
+ u32 fifo_th;
/* data related to DMA transfers b/w i2s and DMAC */
union dw_i2s_snd_dma_data play_dma_data;
union dw_i2s_snd_dma_data capture_dma_data;
struct i2s_clk_config_data config;
int (*i2s_clk_cfg)(struct i2s_clk_config_data *config);
+ int (*pcm_get)(u32 *lsample, u32 *rsample, int bytes, int buf_size);
+};
+
+struct dw_i2s_pll {
+ unsigned int rate;
+ unsigned int data_width;
+ unsigned int idiv;
+ unsigned int fbdiv;
+ unsigned int odiv;
+};
+
+static const struct dw_i2s_pll dw_i2s_pll_cfg[] = {
+ { 32000, 16, 0x104, 0x451, 0x10E38 }, /* 32 kHz */
+ { 32000, 32, 0x82, 0x451, 0x10E38 },
+ { 44100, 16, 0x104, 0x596, 0x10D35},/* 44.1 kHz */
+ { 44100, 32, 0x82, 0x596, 0x10D35 },
+ { 48000, 16, 0x208, 0xA28, 0x10B2C }, /* 48 kHz */
+ { 48000, 32, 0x104, 0xA28, 0x10B2C },
};
static inline void i2s_wr
[PATCH 4/4 RESEND] ARC: axs10x: Update defconfigs so that I2S is enabled
The defconfigs for the AXS boards were updated to enable Designware I2S driver. Signed-off-by: Jose Abreu --- arch/arc/configs/axs101_defconfig | 1 + arch/arc/configs/axs103_defconfig | 1 + arch/arc/configs/axs103_smp_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/arch/arc/configs/axs101_defconfig b/arch/arc/configs/axs101_defconfig index 7c22163..dd38d03 100644 --- a/arch/arc/configs/axs101_defconfig +++ b/arch/arc/configs/axs101_defconfig @@ -116,3 +116,4 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_SOC=y +CONFIG_SND_DESIGNWARE_I2S=y diff --git a/arch/arc/configs/axs103_defconfig b/arch/arc/configs/axs103_defconfig index d63aef0..ff7162e 100644 --- a/arch/arc/configs/axs103_defconfig +++ b/arch/arc/configs/axs103_defconfig @@ -119,3 +119,4 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_SOC=y +CONFIG_SND_DESIGNWARE_I2S=y diff --git a/arch/arc/configs/axs103_smp_defconfig b/arch/arc/configs/axs103_smp_defconfig index f4b51ce..b9f4671 100644 --- a/arch/arc/configs/axs103_smp_defconfig +++ b/arch/arc/configs/axs103_smp_defconfig @@ -120,3 +120,4 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_SOC=y +CONFIG_SND_DESIGNWARE_I2S=y -- 1.9.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/4] drm: Add DT bindings documentation for ARC PGU display controller
On Fri, Feb 19, 2016 at 04:03:52PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> ---
> .../devicetree/bindings/display/snps,arcpgu.txt| 74
> ++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
>
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..c8382fb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,74 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> + - compatible: "snps,arcpgu"
Seems like this should be more specific. Is there some sort or
versioning with ARC blocks?
> + - reg: Physical base address and length of the controller's registers.
> + - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> + - clock-names: A list of clock names. For ARC PGU it should contain:
> + - "pxlclk" for the clock feeding the output PLL of the controller.
> + - encoder-slave: Phandle of encoder chip.
This is unnecessary with the OF graph.
> +
> +Required sub-nodes:
> + - port: The PGU connection to an encoder chip. The connection is modelled
> +using the OF graph bindings specified in
> +Documentation/devicetree/bindings/graph.txt.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@0x {
Unit address should not have '0x'
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <&clock_node>;
> + clock-names = "pxlclk";
> + encoder-slave = <&encoder_node>;
> +
> + port {
> + pgu_output: endpoint {
> + remote-endpoint = <&hdmi_enc_input>;
> + };
> + };
> + };
> +
> + /* HDMI encoder on I2C bus */
> + i2c@0x {
> + compatible = "...";
> +
> + encoder_node:encoder_node@0x{
I2C addresses would be 8-bit only.
> + compatible="...";
> +
> + ports {
> + port@0 {
> + reg = <0>;
> + hdmi_enc_input:endpoint {
> + remote-endpoint = <&pgu_output>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + hdmi_enc_output:endpoint {
> + remote-endpoint =
> <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> + }
> +
> + hdmi0: connector {
> + compatible = "hdmi-connector";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_enc_output>;
> + };
> + };
> + };
> +};
> --
> 2.5.0
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Fix misspellings in comments.
Signed-off-by: Adam Buchbinder
---
arch/arc/include/asm/cmpxchg.h | 2 +-
arch/arc/include/asm/entry-compact.h | 2 +-
arch/arc/include/asm/pgtable.h | 2 +-
arch/arc/kernel/stacktrace.c | 2 +-
arch/arc/kernel/time.c | 4 ++--
arch/arc/mm/cache.c | 2 +-
arch/arc/mm/highmem.c| 2 +-
arch/arc/mm/tlb.c| 8
8 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h
index af7a2db..a444be6 100644
--- a/arch/arc/include/asm/cmpxchg.h
+++ b/arch/arc/include/asm/cmpxchg.h
@@ -149,7 +149,7 @@ static inline unsigned long __xchg(unsigned long val,
volatile void *ptr,
* Since xchg() doesn't always do that, it would seem that following defintion
* is incorrect. But here's the rationale:
* SMP : Even xchg() takes the atomic_ops_lock, so OK.
- * LLSC: atomic_ops_lock are not relevent at all (even if SMP, since LLSC
+ * LLSC: atomic_ops_lock are not relevant at all (even if SMP, since LLSC
* is natively "SMP safe", no serialization required).
* UP : other atomics disable IRQ, so no way a difft ctxt atomic_xchg()
* could clobber them. atomic_xchg() itself would be 1 insn, so it
diff --git a/arch/arc/include/asm/entry-compact.h
b/arch/arc/include/asm/entry-compact.h
index 1aff3be..1d8f57c 100644
--- a/arch/arc/include/asm/entry-compact.h
+++ b/arch/arc/include/asm/entry-compact.h
@@ -231,7 +231,7 @@
/* free up r9 as scratchpad */
PROLOG_FREEUP_REG r9, @int\LVL\()_saved_reg
- /* Which mode (user/kernel) was the system in when intr occured */
+ /* Which mode (user/kernel) was the system in when intr occurred */
lr r9, [status32_l\LVL\()]
SWITCH_TO_KERNEL_STK
diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index d426d42..ec2af62 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -12,7 +12,7 @@
* - Utilise some unused free bits to confine PTE flags to 12 bits
* This is a must for 4k pg-sz
*
- * vineetg: Mar 2011 - changes to accomodate MMU TLB Page Descriptor mods
+ * vineetg: Mar 2011 - changes to accommodate MMU TLB Page Descriptor mods
* -TLB Locking never really existed, except for initial specs
* -SILENT_xxx not needed for our port
* -Per my request, MMU V3 changes the layout of some of the bits
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index 001de4c..e0efff1 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -232,7 +232,7 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
}
/* Another API expected by schedular, shows up in "ps" as Wait Channel
- * Ofcourse just returning schedule( ) would be pointless so unwind until
+ * Of course just returning schedule( ) would be pointless so unwind until
* the function is not in schedular code
*/
unsigned int get_wchan(struct task_struct *tsk)
diff --git a/arch/arc/kernel/time.c b/arch/arc/kernel/time.c
index 156d983..7d9a736 100644
--- a/arch/arc/kernel/time.c
+++ b/arch/arc/kernel/time.c
@@ -55,8 +55,8 @@
#define ARC_REG_TIMER1_CTRL0x101 /* timer 1 control */
#define ARC_REG_TIMER1_CNT 0x100 /* timer 1 count */
-#define TIMER_CTRL_IE (1 << 0) /* Interupt when Count reachs limit */
-#define TIMER_CTRL_NH (1 << 1) /* Count only when CPU NOT halted */
+#define TIMER_CTRL_IE (1 << 0) /* Interrupt when Count reaches limit */
+#define TIMER_CTRL_NH (1 << 1) /* Count only when CPU NOT halted */
#define ARC_TIMER_MAX 0x
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index b65f797..e1d71dc 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -650,7 +650,7 @@ static void __dma_cache_wback_l1(unsigned long start,
unsigned long sz)
/*
* DMA ops for systems with both L1 and L2 caches, but without IOC
- * Both L1 and L2 lines need to be explicity flushed/invalidated
+ * Both L1 and L2 lines need to be explicitly flushed/invalidated
*/
static void __dma_cache_wback_inv_slc(unsigned long start, unsigned long sz)
{
diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
index 92dd92c..04f8332 100644
--- a/arch/arc/mm/highmem.c
+++ b/arch/arc/mm/highmem.c
@@ -18,7 +18,7 @@
/*
* HIGHMEM API:
*
- * kmap() API provides sleep semantics hence refered to as "permanent maps"
+ * kmap() API provides sleep semantics hence referred to as "permanent maps"
* It allows mapping LAST_PKMAP pages, using @last_pkmap_nr as the cursor
* for book-keeping
*
diff --git a/arch/arc/mm/tlb.c b/arch/arc/mm/tlb.c
index daf2bf5..7046c12 100644
--- a/arch/arc/mm/tlb.c
+++ b/arch/arc/mm/tlb.c
@@ -45,7 +45,7 @@
* in interrupt-safe region.
*
* Vineetg: April 23rd Bug #93131
- *Problem: tlb_flush_kernel_range() doesnt do anything if the range to
+ *Problem: tlb_flush_kernel_range() doesn't do anything if the ran
Re: [PATCH 2/4 RESEND] ARC: axs10x: Update defconfigs so that audio is enabled
On Tuesday 23 February 2016 07:22 PM, Jose Abreu wrote: > The defconfigs for the AXS boards were updated so that > ALSA SoC is enabled and also the audio for the ADV7511 > HDMI transmitter. > > Signed-off-by: Jose Abreu > --- > arch/arc/configs/axs101_defconfig | 3 +++ > arch/arc/configs/axs103_defconfig | 5 + > arch/arc/configs/axs103_smp_defconfig | 5 + @Alexey, has this been tested on AXS103. Do we have the right PLL / clocks to get the audio rates - given the lower master clk. Further per out off-list discussion - let us have a seperate config for ARC HS SDP which supports the shipping single hardware configuration and add these fancy things there as well as bumping the clk rate to 100 MHz . Current axs103* configs are more of developer configs and I don't want to bloat their code with things we don't build / download 10 times a day ! > 3 files changed, 13 insertions(+) > > diff --git a/arch/arc/configs/axs101_defconfig > b/arch/arc/configs/axs101_defconfig > index e359099..7c22163 100644 > --- a/arch/arc/configs/axs101_defconfig > +++ b/arch/arc/configs/axs101_defconfig > @@ -113,3 +113,6 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 > # CONFIG_SCHED_DEBUG is not set > # CONFIG_DEBUG_PREEMPT is not set > # CONFIG_FTRACE is not set > +CONFIG_SOUND=y > +CONFIG_SND=y > +CONFIG_SND_SOC=y > diff --git a/arch/arc/configs/axs103_defconfig > b/arch/arc/configs/axs103_defconfig > index 323486d..d63aef0 100644 > --- a/arch/arc/configs/axs103_defconfig > +++ b/arch/arc/configs/axs103_defconfig > @@ -76,12 +76,14 @@ CONFIG_SERIAL_OF_PLATFORM=y > CONFIG_I2C=y > CONFIG_I2C_CHARDEV=y > CONFIG_I2C_DESIGNWARE_PLATFORM=y > +CONFIG_DRM=y > # CONFIG_HWMON is not set > CONFIG_FB=y > # CONFIG_VGA_CONSOLE is not set > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y > CONFIG_LOGO=y > +CONFIG_DRM_I2C_ADV7511=y > # CONFIG_LOGO_LINUX_MONO is not set > # CONFIG_LOGO_LINUX_VGA16 is not set > # CONFIG_LOGO_LINUX_CLUT224 is not set > @@ -114,3 +116,6 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 > # CONFIG_SCHED_DEBUG is not set > # CONFIG_DEBUG_PREEMPT is not set > # CONFIG_FTRACE is not set > +CONFIG_SOUND=y > +CONFIG_SND=y > +CONFIG_SND_SOC=y > diff --git a/arch/arc/configs/axs103_smp_defconfig > b/arch/arc/configs/axs103_smp_defconfig > index 66191cd..f4b51ce 100644 > --- a/arch/arc/configs/axs103_smp_defconfig > +++ b/arch/arc/configs/axs103_smp_defconfig > @@ -77,12 +77,14 @@ CONFIG_SERIAL_OF_PLATFORM=y > CONFIG_I2C=y > CONFIG_I2C_CHARDEV=y > CONFIG_I2C_DESIGNWARE_PLATFORM=y > +CONFIG_DRM=y > # CONFIG_HWMON is not set > CONFIG_FB=y > # CONFIG_VGA_CONSOLE is not set > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y > CONFIG_LOGO=y > +CONFIG_DRM_I2C_ADV7511=y > # CONFIG_LOGO_LINUX_MONO is not set > # CONFIG_LOGO_LINUX_VGA16 is not set > # CONFIG_LOGO_LINUX_CLUT224 is not set > @@ -115,3 +117,6 @@ CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10 > # CONFIG_SCHED_DEBUG is not set > # CONFIG_DEBUG_PREEMPT is not set > # CONFIG_FTRACE is not set > +CONFIG_SOUND=y > +CONFIG_SND=y > +CONFIG_SND_SOC=y ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Interesting csd deadlock on ARC
On Tuesday 23 February 2016 04:28 PM, Noam Camus wrote: >> From: Peter Zijlstra [mailto:pet...@infradead.org] >> Sent: Tuesday, February 23, 2016 12:40 PM > >> The only requirement for irq_work is that it runs after the NMI completes >> and runs from regular IRQ context. >There are no strict interrupt priority >> requirements, only that it happens. > > We here already use self IPI and irq_work on ARC (with no NMI concerns). > Please see patch at: > https://github.com/EZchip/linux/commit/e42556738e610295f917c79dae166373cd11de88 So this relies on 2nd level intc providing the IPI. For UP we still need the software triggered interrupt provided by core intc. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Interesting csd deadlock on ARC
On Tuesday 23 February 2016 03:28 PM, Peter Zijlstra wrote: > On Tue, Feb 23, 2016 at 10:51:42AM +0530, Vineet Gupta wrote: >> On Friday 19 February 2016 12:17 PM, Vineet Gupta wrote: >>> Hi Peter, >>> >>> I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2 >>> and it >>> turned out to be lot more interesting than I'd hoped for. This is stock v4.4 >>> >>> Trouble starts with an IPI to self which doesn't get delivered as the >>> inter-core >>> interrupt providing h/w is not capable of IPI to self (which I found as >>> part of >>> debugging this). Subsequent IPIs from other cores to this core get elided >>> as well >>> due to the IPI coalescing optimization in arch/arc/kernel/smp.c: >>> ipi_send_msg_one() >>> >>> There are ways to use a different h/w mechanism to solve the trigger issue >>> and I'd >>> hoped to just implement arch_irq_work_raise(). > > Yes, there are other architectures that use other means for self-IPI, > IIRC PowerPC has to program their timer in the past to generate a local > interrupt. > >>> But the trouble is the call stack >>> for this issue: IPI to self is triggered from >>> >>> sys_sched_setscheduler >>>__balance_callback >>>pull_rt_task >>> irq_work_queue_on <-- called with @cpu == self >>> >>> Looking into irq_work.c, irq_work_queue() is what is semantically needed, >>> specifically arch_irq_work_raise() will not be called, which means I need >>> arch_send_call_function_single_ipi() to be able to IPI to self cpu also. Is >>> that >>> expected from arch code >> >> What I actually meant was is it OK for irq_work_queue_on() to be called >> locally >> (is this a sched bug/optimization(. Further if it is OK to be called, does >> it need >> to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or >> arch_send_call_function_single_ipi() is expected to handle sending IPI to >> self ! > > Right, so I'm not actually sure we started out with this requirement. > But you're not the first to run into this, see: > > > lkml.kernel.org/r/cajz5v0glanksuziqq25qtcynqeox43yd9jnju_xxwbdyajf...@mail.gmail.com > > Initially I think irq_work_queue_on() was only used remotely, but I > think it makes sense to allow the current cpu, esp. since people seem to > be using it like that. So it seems Russell's questions in the thread above stands still. IMO we need to massage irq_work_queue_on() to handle the case of called for local cpu. This will automatically take care of CONFIG_SMP kernel running on UP hardware. > > Now the distinct difference between arch_irq_work_raise() and > arch_send_call_function_single_ipi() is that arch_irq_work_raise() > should be NMI-safe. > > So on x86 it has to be extra careful about the lapic state, whereas the > regular IPI code doesn't. > > I seem to have forgotten the status of NMIs on ARC, but this is > something to make a note of. > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arc: make sure __delay() never gets executed with 0 loops
On Monday 15 February 2016 10:07 PM, Alexey Brodkin wrote: > Current implementation of __delay() function uses so-called > zero-delay loops. And the only condition to exit that loop is > LP_COUNT (loop count register) = 1 (but not 0 as it might be easily > imagined). So u can fix this better by doing a lp.nz, but > So if our calculation of "loops" gives 0 (and that is pretty possible > given result of multiplication being >> 32) then zero-delay loop > mechanism starts with LP_COUNT=0 and it ends up decrementing LP_COUNT > while staying in the loop effectively producing close to infinite delay > instead of very short one. > > I bumped into it with AXS101 + external DDR controller and caches > disabled. In that case I've got very small > loops_per_jiffy=0xf00: I understand this gives you grief, but the code is doing exactly what it is asked to. Since the system is slow, You are getting only 0xf00 (3840) loop iterations in 10ms. So if you want say a delay of 1 micro-sec, you will need to loop for 3840 / 1 ~ 0 loops This all assumes our lpj computation is correct - otherwise that needs fixing too. Anyways I think for genuine cases where the number of loops is indeed computed to 0 because caller was passing too small a value, it is better to wait for looong time to catch the bugger rather than silently returning. This is one of the cases where disease is better than the cure ! > >8 > Calibrating delay loop... 0.77 BogoMIPS (lpj=3862) > >8 > > And on console output delays were way too long. > > Signed-off-by: Alexey Brodkin > Cc: Vineet Gupta > Please enter the commit message for your changes. Lines starting > --- > arch/arc/include/asm/delay.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arc/include/asm/delay.h b/arch/arc/include/asm/delay.h > index 08e7e2a..1a7a1dc 100644 > --- a/arch/arc/include/asm/delay.h > +++ b/arch/arc/include/asm/delay.h > @@ -57,7 +57,8 @@ static inline void __udelay(unsigned long usecs) >*/ > loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32; > > - __delay(loops); > + if (loops) > + __delay(loops); > } > > #define udelay(n) (__builtin_constant_p(n) ? ((n) > 2 ? __bad_udelay() \ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[GIT PULL] ARC fixes for 4.5-rc6
Hi Linus, A critical bug fix since the last pull request and a sweeping defconfig cleanup from Alexey. Please pull. Thx, -Vineet > The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865: Linux 4.5-rc4 (2016-02-14 13:05:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-4.5-rc6-fixes for you to fetch changes up to d73b73f5626ac0b131b31b7b9457e19201bc570b: ARC: SMP: No need for CONFIG_ARC_IPI_DBG (2016-02-24 11:07:32 +0530) ARC fixes for 4.5-rc5 - Fix for csd deadlock due to missing self IPI - Accompanying IPI cleanups / optimization - Some boot reporting updates for new features Alexey Brodkin (1): arc: get rid of DEVTMPFS dependency on INITRAMFS_SOURCE Vineet Gupta (8): ARC: Assume multiplier is always present ARCv2: boot print Low Latency Memory ARCv2: boot report CCMs (Closely Coupled Memories) ARCv2: SMP: Emulate IPI to self using software triggered interrupt ARC: [intc-compact] Remove IPI setup from ARCompact port ARCv2: SMP: Push IPI_IRQ into IPI provider ARCv2: Elide sending new cross core intr if receiver didn't ack prev ARC: SMP: No need for CONFIG_ARC_IPI_DBG arch/arc/Kconfig | 18 --- arch/arc/Makefile | 4 -- arch/arc/configs/axs101_defconfig | 4 +- arch/arc/configs/axs103_defconfig | 10 +--- arch/arc/configs/axs103_smp_defconfig | 10 +--- arch/arc/configs/nsim_700_defconfig| 5 +- arch/arc/configs/nsim_hs_defconfig | 3 +- arch/arc/configs/nsim_hs_smp_defconfig | 6 +-- arch/arc/configs/nsimosci_defconfig| 2 +- arch/arc/configs/nsimosci_hs_defconfig | 3 +- arch/arc/configs/nsimosci_hs_smp_defconfig | 12 + arch/arc/configs/tb10x_defconfig | 18 +++ arch/arc/include/asm/arcregs.h | 32 +++- arch/arc/include/asm/irq.h | 2 - arch/arc/include/asm/irqflags-arcv2.h | 11 arch/arc/kernel/entry-arcv2.S | 11 ++-- arch/arc/kernel/intc-compact.c | 3 -- arch/arc/kernel/mcip.c | 55 ++-- arch/arc/kernel/setup.c| 80 +++--- arch/arc/kernel/smp.c | 3 -- 20 files changed, 134 insertions(+), 158 deletions(-) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
