On Fri, Feb 15, 2013 at 02:37:49PM +0000, Dietmar Eggemann wrote:
dropped linux-arm-kernel@lists.infradead.org linux-arm-kernel@lists.infradead.org
On 15/02/13 12:06, Jon Medhurst (Tixy) wrote:
On Fri, 2013-02-15 at 10:33 +0000, Lorenzo Pieralisi wrote:
On Fri, Feb 15, 2013 at 10:04:37AM +0000, Jon Medhurst (Tixy) wrote:
On Thu, 2013-02-14 at 17:16 +0000, Will Deacon wrote:
Hi Tixy,
On Thu, Feb 14, 2013 at 05:07:43PM +0000, Jon Medhurst (Tixy) wrote:
The function v7_coherent_kern_range uses the macro icache_line_size to read the current CPUs icache line size for the purpose of invalidating all cache lines in the given range.
Unfortunately, on the TC2 big.LITTLE test chip, the A15 icache line size is 64 bytes, but the A7 size is only 32 bytes. So when the function executes on the A15 it will miss out every alternate cache line for the A7.
There is a signal (IMINLN) to the core which allows A15 to behave as though it has a 32-byte line size and this should be driven correctly for big/little.
How do we set that signal? Is that something we have to set up in Linux or is it something that we expect the Firmware to set up?
If I am not mistaken, SCC register at offset 0x400 (bit 7) allows IMINLN to be forced to 0 (ie Instruction Cache minimum line size == 32 bytes).
This can be done through board.txt so that it is set up as we want.
According to the TRM for TC2 the default value for that register is 0x33330c80, so adding the line "SCC: 0x400 0x33330c00" and incrementing TOTALSCCS does the trick, and the A15's now report an icache size of 32.
We'll have to get everyone with a TC2 to make that change then?
Hi,
I tried with SCC: 0x400 0x33330c00 and incremented TOTALSCCS but it makes no difference for me.
With cpuidle state1 enabled on all CPUs, the system stops after
root@linaro-nano:/sys/kernel/debug/tracing# echo function > current_tracer
When I attach the debugger I can always see that one A15 stopped here:
#0 atomic_add_return( v = <Value not available : Failed to read 4 bytes from address S:0x0000001D because Bus error on memory operation.>, i = 1 ) at atomic.h:62 #1 function_trace_call( ip = 3221328812, parent_ip = 3221331569, op = <Value currently has no location>, pt_regs = <Value currently has no location> ) at trace_functions.c:109 #2 [S:0x00001008]
i r R0 0xC0084E89 3221769865 R1 0x00000001 1 R2 0x00000001 1 R3 0xEF0C4000 4010557440 R4 0xC1BCDE88 3250380424 R5 0x200001D3 536871379 R6 0xC05FB3AC 3227497388 R7 0xC0019E71 3221331569 R8 0xC00193AC 3221328812 R9 0xC0B54EF8 3233107704 R10 0x00000000 0 R11 0x00000000 0 R12 0x00000000 0 SP 0xEF0C5E78 0xEF0C5E78 LR 0xC0084E89 0xC0084E89 <current_thread_info+0x1> PC 0xC0084E9E 0xC0084E9E <atomic_add_return+0x4> CPSR 0x200001F3 nzCvq_ge3ge2ge1ge0_inactive_eAIFTj_SVC
disas 0xC0084E9A S:0xC0084E9A : DMB S:0xC0084E9E : LDREX r2,[r4] <--- PC S:0xC0084EA2 : ADD r2,r2,#1 S:0xC0084EA6 : STREX r1,r2,[r4] S:0xC0084EAA : TEQ r1,#0 S:0xC0084EAE : BNE {pc}-0x10 ; 0xc0084e9e S:0xC0084EB0 : DMB
CP15_SCTLR: 0x50C53879 ... C ... disable
Looks like code relying on ldrex/strex is being run with C bit cleared which is a recipe for disasters.
We should avoid tracing power down functions, I have to compile and disassemble the kernel to be more precise, just guessing.
Lorenzo