[U-Boot] sunxi: CPU disabling

[Marc Zyngier <marc.zyngier@arm.com>]

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...