On 02/21/2018 12:31 PM, Vineet Gupta wrote:
Hi Eugeniy,
Starting from ARC HS v3.0
From the STAR fix, it seem this was fixed in HS 2.1c, so you should be able to
test it on HSDK, which was my next question: where and how did you test this and
verify that it works as we think it does. I trie
On 02/07/2018 05:20 PM, Vineet Gupta wrote:
Didn't do ;)
Is Arnd's patch good to merge or do we need a fixup?
From: Arnd Bergmann
Subject: bug.h: work around GCC PR82365 in BUG()
Looking at functions with large stack frames across all architectures led
me discovering that BUG() suffers fro
Hi Eugeniy,
On 02/21/2018 01:40 AM, Eugeniy Paltsev wrote:
Currently GFRC is running regardless state of ARC cores in the SMP cluster.
That means even if ARC cores are halted when doing JTAG debugging GFRC
[our source of wall-time] continues to run giving us unexpected warnings
once we allow ARC
On Wed, Feb 21, 2018 at 7:57 PM, Evgeniy Didin
wrote:
> In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") have
> been made
> changes which can cause multiply overflow for 32-bit systems. It was caught
> on arc/hsdk board
> when "drto_ms" should be 671, but it was 70 and tha
Hi Evgeniy
On 02/21/2018 09:57 AM, Evgeniy Didin wrote:
In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") have
been made
changes which can cause multiply overflow for 32-bit systems.
Awesome, thx for quickly narrowing it down. I tried the fix and it cures my
issue.
It
TIMER0 interrupt ACK is different for ARC700 and HS3x cores.
This came to light in some internal discussions and it is nice to have
this documented rather than digging up the PRM (Prog Ref Manual) again
Signed-off-by: Vineet Gupta
---
drivers/clocksource/arc_timer.c | 11 ---
1 file cha
In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") have
been made
changes which can cause multiply overflow for 32-bit systems. It was caught on
arc/hsdk board
when "drto_ms" should be 671, but it was 70 and that caused a flow of
stack-traces just copying
file from mmc.
Let
Currently GFRC is running regardless state of ARC cores in the SMP cluster.
That means even if ARC cores are halted when doing JTAG debugging GFRC
[our source of wall-time] continues to run giving us unexpected warnings
once we allow ARC cores to run due to some tasks being stuck for too
long.
Sta
Setup MCIP debug mask according cpu possible mask instead of
use hardcoded one.
Signed-off-by: Eugeniy Paltsev
---
arch/arc/kernel/mcip.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c
index e87a4ea..da73258 1006
As we have option in u-boot to set CPU mask for running linux,
we want to pass information to kernel about CPU cores should
be brought up. So we patch kernel dtb in u-boot to set
possible-cpus property.
This also allows us to have correctly setuped MCIP debug mask.
Signed-off-by: Eugeniy Paltsev
10 matches
Mail list logo