Crash in cpuidle lp2 suspend on Ouya

[Decatf]

I'm working on the Ouya Console using the current master (5.0-rc5) branch of this kernel. The device crashes in the cpuidle lp2 state.

I don't have a serial debugger set up. I am using the android ram console driver. It isn't very reliable way to get kernel logs. The ram console logs are usually corrupted for this crash.

I was able to resolve the crash by moving the call_firmware_op(prepare_idle, TF_PM_MODE_LP2) farther down the suspend path.

Decatf/linux@3fee4a5

[digetx]

Hello, @Decatf! That's an interesting observation. At quick glance your change matches more closely to what downstream kernel does, seems the exact match will be to invoke the firmware call after L2 cache disabling. I'll check how the change works on Nexus 7 and incorporate it into the patch if everything will be fine.

BTW, this is a good timing to fix the last firmware itches as I was going to send out the latest version of TF-support patches to upstream around Monday. Hopefully we'll manage to upstream them this time with some help from @thierryreding.

[Decatf]

I thought it made sense to run the cache operations just before disabling it. I've tested the firmware op after outer_disable() and it doesn't crash.

Rather than creating another github issue. There is an bug with the cpufreq patches. cpufreq can work on Ouya but it needs to skip the regulator enable. The Ouya regulators are on at boot and always on. The cpufreq patch always calls regulator enable during probe which makes the device lock up.

It works fine when regulator_is_enabled() is checked.
Decatf/linux@85a251d

[digetx]

Thanks for the testing! The TF firmware is quite finicky to HW state at the time of SMC invocation, it took me some time to figure out that it doesn't like when L2 is disabled with MMU off. Ideally firmware should be agnostic to the CPU state (especially if it's about security), but nothing is ideal in this world :)

Regulator enabling shall be a NO-OP if regulator is always-on because regulator core enables regulator at the registration time. It's either regulator-core or regulator's driver bug. You could try to add some debug messages to the core and drivers to narrow down the offending code.

[digetx]

@Decatf, the TF change you suggested works fine on Nexus7, the relevant patch was updated and pushed out already to grate's kernel. I'll send out patches to upstream ML shortly and will add you to the CC list, please try out the updated version of the patches and don't shy to reply with yours Tested-by if everything will work fine for the Ouya.

Also, I noticed that Nexus 7 now hangs quite easily on suspend and seems changing the CPU's suspend-freq to a 1GHz (in device tree) helps by raising the suspend-resume voltage. I'm not sure whether anything changed in kernel or I changed something in the cpufreq driver and forgot already... just keep that in mind if you'll experience some odd hangs on suspend.

[digetx]

@Decatf have you resolved the regulator's bug? I removed the regulators enabling and made some other minor changes to the driver, let me know if it works for you.

[digetx]

Turned out that the current kernel base has some bug in block subsystem and only works over NFS, I'll let you know once it is fixed.

[Decatf]

have you resolved the regulator's bug?

I think it might be stuck in a loop in the function regulator_balance_voltage. The regulator_enable function calls into this because the cpu/core is coupled. There is a loop that tries to find the best possible voltage.

https://github.com/grate-driver/linux/blob/bc6e8e4/drivers/regulator/core.c#L3606

The system locks up after that line. That was as far I have traced the bug. I have not tried to debug it much since.

[digetx]

Oh, that's not good. Although I'm planning to extend the regulators API with a custom voltage balancer for Tegra soonish, hence bypassing that code.

[Decatf]

I was wrong. It isn't the regulator framework. The minimum core voltage has to be 1.1v otherwise the device hangs. The regulator_balance_voltage function takes a few iterations until it tries a min voltage below that. The cpufreq driver works without any problems after fixing this.