[U-Boot] [PATCH v2 0/9] sunxi: sun5/7i: add the psci suspend function

[Hans de Goede]

Hi Antoine,

On 06-10-16 16:33, Antoine Tenart wrote:
> Hi all,
>
> This series adds an implementation of the psci suspend function for both
> sun5i and sun7i. This was tested on Nextthing's CHIP and on a A20, using
> cpuidle in Linux. My tests showed a power consumption reduced by a factor
> 2 on the CHIP when the system was idle. It went from ~1W without cpuidle
> enabled to ~0.45W.
>
> The idea of this suspend function is to put the dram into self-refresh,
> cut off some plls and to switch cpuclk to a source with a lower
> frequency. Please note the sun7i implementation lacks some parts as
> putting the ram into self-refresh and coming back from this state seems
> a bit tricky. I made some tests but did not managed yet to have a stable
> solution.
>
> As the sun5i does not have a GIC, I needed to remove some code from the
> generic psci code. To do this I added an ARM_GIC Kconfig option which
> needs to be selected by each SoC having a GIC. I already added the
> relevant lines for SoCs using the PSCI ARMv7 code. As this Kconfig
> option is currently only used in the psci code, it should be safe to add
> it even if all the SoCs having a GIC do not select it, as long as they
> don't have psci functions.
>
> Finally the series has a patch to add defines used by the psci code and
> another patch to let sun5i SoCs boot the kernel in non-secure mode so
> that it can call psci functions.

While doing my laps in the swimming pool this morning I was thinking about
this patch set and I still have some questions.

Since this hooks into cpuidle in Linux, the kernel will call this as soon
as the system is idle, right?

But what happens then if some peripherals are still doing DMA? Have you
tried this on a CHIP with a LCD (or composite video out) attached ?

I would expect things to break when the system goes idle without the
screen being blanked, since the dram is then in self-refresh and
the display engine can no longer dma data from the framebuffer to
display.

Another example would be:

1) Something does a large(ish) mmc block write
2) mmc controller start-s dma sending data to the sdcard
3) sdcard blocks because it needs to do internal housekeeping
4) cpu goes idle -> dram goes into self refresh
5) sdcard is ready mmc-controller tries to dma data to write
to card, but dram is in self-refresh.

So unless I'm mistaken putting the dram in self-refresh when we still
have peripherals running and potentially doing dma, is a bad idea.

Regards,

Hans