linux-toradex.git/arch/arm/mach-rockchip, branch v4.3

ARM: rockchip: pm: Fix PTR_ERR() argument

2015-08-24T10:39:14+00:00

PTR_ERR should access the value just tested by IS_ERR.

The semantic patch that makes this change is available
in scripts/coccinelle/tests/odd_ptr_err.cocci.

Signed-off-by: Fabio Estevam 
Reviewed-by: Matthias Brugger 
Signed-off-by: Heiko Stuebner

ARM: rockchip: enable PMU_GPIOINT_WAKEUP_EN when entering shallow suspend

2015-08-06T11:05:14+00:00

PMU_GPIOINT_WAKEUP_EN seems needed when entering the shallow suspend
(with logic staying on) but does not seem to be needed for the deep
suspend for unknown reasons.
Testing revealed that this setting really is necessary to reliably
resume the veyron devices from suspend.

Reported-by: Chris Zhong 
Signed-off-by: Heiko Stuebner 
Reviewed-by: Chris Zhong 
Tested-by: Chris Zhong 
Reviewed-by: Douglas Anderson

ARM: rockchip: set correct stabilization thresholds in suspend

2015-08-06T11:05:12+00:00

Currently the stabilization thresholds for the oscillator and external pmu
are statically set to 30ms based on a 32kHz clock rate. This leaves out the
case when we don't switch to the 32kHz clock when only entering the shallow
suspend mode where the logic keeps running.

So, set the correct threshold after we have determined if we switch to the
32kHz clock or stay with the 24MHz one. Also set the oscillator-
stabilization to 0 if it is kept running during suspend, as it of course
does not need to stabilize then.

Reported-by: Chris Zhong 
Signed-off-by: Heiko Stuebner 
Reviewed-by: Chris Zhong 
Tested-by: Chris Zhong 
Reviewed-by: Douglas Anderson

ARM: rockchip: rename osc_switch_to_32k variable

2015-08-06T11:05:09+00:00

The variable name is misleading, as the deep suspend mode always switches
the main supplying clock to the 32kHz source. Additionally the main
oscillator remains running in some cases, which this var indicates.

So rename it to osc_disable to clarity.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Chris Zhong 
Tested-by: Chris Zhong 
Reviewed-by: Douglas Anderson

ARM: rockchip: fix broken build

2015-07-06T09:46:08+00:00

The following was seen in branch[0] build.

arch/arm/mach-rockchip/platsmp.c:154:23: error:
    'rockchip_secondary_startup' undeclared (first use in this function)

branch[0]:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.3-armsoc/soc

The broken build is caused by the commit fe4407c0dc58
("ARM: rockchip: fix the CPU soft reset").

Signed-off-by: Caesar Wang 

The breakage was a result of it being wrongly merged in my branch with
the cache invalidation rework from Russell 02b4e2756e01c
("ARM: v7 setup function should invalidate L1 cache").

Signed-off-by: Heiko Stuebner

ARM: rockchip: remove some useless macro in pm.h

2015-07-05T22:47:00+00:00

These are actually not used in the pm code, as we moved suspend handling
to the clock driver, remove them here.

Signed-off-by: Chris Zhong 
Reviewed-by: Douglas Anderson 
Signed-off-by: Heiko Stuebner

ARM: rockchip: add support holding 24Mhz osc during suspend

2015-07-05T22:47:00+00:00

If we want to wake up system via usb, the 24Mhz osc could not be
disabled during suspend, read the usb phy SIDDQ bit to decide whether
to switch to 32khz clock-in.

Signed-off-by: Chris Zhong 
Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 
Signed-off-by: Heiko Stuebner

ARM: rockchip: fix the SMP code style

2015-07-05T22:46:59+00:00

Use the below scripts to check:
scripts/checkpatch.pl -f --subject arch/arm/mach-rockchip/platsmp.c

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
Reviewed-by: Kever Yang 
Signed-off-by: Heiko Stuebner

ARM: rockchip: ensure CPU to enter WFI/WFE state

2015-07-05T22:46:59+00:00

The patch can ensure that v7_exit_coherency_flush() in rockchip_cpu_die()
executed in time.
The mdelay(1) has enough time to fix the problem of CPU offlining.
That's a workaround way in rockchip hotplug code,
At least, we haven't a better way to solve it. Who know,
that maybe fixed by chip (hardware) in the future.

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
Reviewed-by: Kever Yang 
Signed-off-by: Heiko Stuebner

ARM: rockchip: fix the CPU soft reset

2015-07-05T22:46:59+00:00

We need different orderings when turning a core on and turning a core
off.  In one case we need to assert reset before turning power off.
In ther other case we need to turn power on and the deassert reset.

In general, the correct flow is:

CPU off:
    reset_control_assert
    regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), BIT(pd))
    wait_for_power_domain_to_turn_off
CPU on:
    regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), 0)
    wait_for_power_domain_to_turn_on
    reset_control_deassert

This is needed for stressing CPU up/down, as per:
    cd /sys/devices/system/cpu/
    for i in $(seq 10000); do
        echo "================= $i ============"
        for j in $(seq 100); do
            while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "000"" ]]
                echo 0 > cpu1/online
                echo 0 > cpu2/online
                echo 0 > cpu3/online
            done
            while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "111" ]]; do
                echo 1 > cpu1/online
                echo 1 > cpu2/online
                echo 1 > cpu3/online
            done
        done
    done

The following is reproducable log:
    [34466.186812] PM: noirq suspend of devices complete after 0.669 msecs
    [34466.186824] Disabling non-boot CPUs ...
    [34466.187509] CPU1: shutdown
    [34466.188672] CPU2: shutdown
    [34473.736627] Kernel panic - not syncing:Watchdog detected hard LOCKUP on cpu 0
    .......
or others similar log:
    .......
    [ 4072.454453] CPU1: shutdown
    [ 4072.504436] CPU2: shutdown
    [ 4072.554426] CPU3: shutdown
    [ 4072.577827] CPU1: Booted secondary processor
    [ 4072.582611] CPU2: Booted secondary processor
    

    Tested by cpu up/down scripts, the results told us need delay more time
before write the sram. The wait time is affected by many aspects
(e.g: cpu frequency, bootrom frequency, sram frequency, bus speed, ...).

    Although the cpus other than cpu0 will write the sram, the speedy is
no the same as cpu0, if the cpu0 early wake up, perhaps the other cpus
can't startup. As we know, the cpu0 can wake up when the cpu1/2/3 write
the 'sram+4/8' and send the sev.
    Anyway.....
    At the moment, 1ms delay will be happy work for cpu up/down scripts test.

Signed-off-by: Caesar Wang 
Reviewed-by: Doug Anderson 
Reviewed-by: Kever Yang 
Fixes: 3ee851e212d0 ("ARM: rockchip: add basic smp support for rk3288")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Stuebner