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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
