From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Date: Tue, 25 Nov 2014 10:51:30 +0000 Subject: [U-Boot] sunxi: CPU disabling In-Reply-To: <54745983.8040108@web.de> References: <5460B64F.2040306@siemens.com> <5460B944.3030401@arm.com> <546999F9.9070009@web.de> <54745983.8040108@web.de> Message-ID: <54745F32.9050408@arm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 25/11/14 10:27, Jan Kiszka wrote: > On 2014-11-17 07:47, Jan Kiszka wrote: >> On 2014-11-10 14:10, Marc Zyngier wrote: >>> On 10/11/14 12:57, Jan Kiszka wrote: >>>> Hi all, >>>> >>>> I'm trying to get Marc's CPU hotplug-anabling patch [1] for sunxi >>>> working on a B-Pi. After the first discussion it became clear that we >>>> need something like flush_dcache_all in the PSCI monitor (I don't think >>>> we need an icache flush, do we?). Does anyone have a clever suggestion >>> >>> No, I-cache can be left alone. >>> >>>> how to reuse the existing code for that? Or do we really need to >>>> re-implement everything, in the worst case in assembly? >>> >>> Why don't you turn the u-boot code into a set of macros, included by >>> both the core u-boot code and the PSCI code? >> >> I've now ported over v7_flush_dcache_all from the Linux kernel. >> >> However, that didn't magically solve the remaining issues with your >> patch: I'm getting crashes on CPU 0 after handling the shoot-down FIQ. >> That is even then the case if I only acknowledge the FIQ on the receiver >> side, don't do any fiddling with CPU1's power states. Only if I >> disabling sending the FIQ from CPU 1, the system remains stable in a CPU >> off/on loop. >> >> Below the patch I'm using. Any ideas if something is wrong with the FIQ >> handler or the setup of this mechanism or whatever? > > Ping. I'm still seeing no light in this tunnel. One finding below, but > maybe a non-issue. Sorry, I haven't had a chance to look at this at all, as the next kernel merge window is getting closer and I still have tons of things to review. What you describe above seems to indicate that it is the FIQ handling that breaks something. Just to understand what you're observing: - does CPU0 always lock-up? - if not, can you find out if it locks up on the "out" path or not? I vaguely remember seeing issues in the "wait" loop below, but my memory is very fuzzy... Any chance you could instrument this? >> +.globl psci_fiq_enter >> +psci_fiq_enter: >> + push {r0-r12} >> + >> + @ Switch to secure >> + mrc p15, 0, r7, c1, c1, 0 >> + bic r8, r7, #1 >> + mcr p15, 0, r8, c1, c1, 0 >> + isb >> + >> + movw r8, #(GICC_BASE & 0xffff) >> + movt r8, #(GICC_BASE >> 16) >> + ldr r9, [r8, #GICC_IAR] >> + movw r10, #0x3ff >> + movt r10, #0 >> + cmp r9, r10 >> + beq out >> + movw r10, #0x3fe >> + cmp r9, r10 >> + beq out >> + str r9, [r8, #GICC_EOIR] >> + dsb >> + >> + @ Compute CPU number >> + lsr r9, r9, #10 >> + and r9, r9, #0xf >> + >> + movw r8, #(SUN7I_CPUCFG_BASE & 0xffff) >> + movt r8, #(SUN7I_CPUCFG_BASE >> 16) >> + >> + @ Wait for the core to enter WFI >> + lsl r11, r9, #6 @ x64 >> + add r11, r11, r8 >> + >> +1: ldr r10, [r11, #0x48] >> + tst r10, #(1 << 2) >> + bne 2f >> + timer_wait r10, ONE_MS >> + b 1b >> + >> + @ Reset CPU >> +2: mov r10, #0 >> + str r10, [r11, #0x40] >> + >> + @ Lock CPU >> + mov r10, #1 >> + lsl r9, r10, r9 @ r9 is now CPU mask >> + ldr r10, [r8, #0x1e4] >> + bic r10, r10, r9 >> + str r10, [r8, #0x1e4] >> + >> + @ Set power gating >> + ldr r10, [r8, #0x1b4] >> + orr r10, r10, #1 >> + str r10, [r8, #0x1b4] >> + timer_wait r10, ONE_MS >> + >> + @ Activate power clamp >> + mov r10, #1 >> +1: str r10, [r8, #0x1b0] >> + lsl r10, r10, #1 >> + orr r10, r10, #1 >> + tst r10, #0x100 >> + beq 1b >> + >> + @ Restore security level >> +out: mcr p15, 0, r7, c1, c1, 0 > > There is no isb here - not required? It has no impact on the stability > issue, though. The following instructions contain an exception return (movs pc, lr), which acts implicitly as an isb. Thanks, M. -- Jazz is not dead. It just smells funny...