Skip to content

Commit 6bd9549

Browse files
Eugeniy Paltsevdlezcano
authored andcommitted
clocksource/drivers/arc_timer: Add comments about locking while read GFRC
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: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Acked-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
1 parent 3ca5768 commit 6bd9549

File tree

1 file changed

+14
-0
lines changed

1 file changed

+14
-0
lines changed

drivers/clocksource/arc_timer.c

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -61,6 +61,20 @@ static u64 arc_read_gfrc(struct clocksource *cs)
6161
unsigned long flags;
6262
u32 l, h;
6363

64+
/*
65+
* From a programming model pov, there seems to be just one instance of
66+
* MCIP_CMD/MCIP_READBACK however micro-architecturally there's
67+
* an instance PER ARC CORE (not per cluster), and there are dedicated
68+
* hardware decode logic (per core) inside ARConnect to handle
69+
* simultaneous read/write accesses from cores via those two registers.
70+
* So several concurrent commands to ARConnect are OK if they are
71+
* trying to access two different sub-components (like GFRC,
72+
* inter-core interrupt, etc...). HW also supports simultaneously
73+
* accessing GFRC by multiple cores.
74+
* That's why it is safe to disable hard interrupts on the local CPU
75+
* before access to GFRC instead of taking global MCIP spinlock
76+
* defined in arch/arc/kernel/mcip.c
77+
*/
6478
local_irq_save(flags);
6579

6680
__mcip_cmd(CMD_GFRC_READ_LO, 0);

0 commit comments

Comments
 (0)