Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: Mike Yang <reimu@sudomaker.com>
Cc: linux-mips@vger.kernel.org,
	Zhou Yanjie <zhouyanjie@wanyeetech.com>,
	aidanmacdonald.0x0@gmail.com
Subject: Re: RFC: Proper suspend-to-ram implementation of Ingenic SoCs
Date: Wed, 13 Jul 2022 21:57:04 +0100	[thread overview]
Message-ID: <4V8ZER.Y1888BONB1P@crapouillou.net> (raw)
In-Reply-To: <6e1d1815-31d5-da55-f601-cce788a836c7@sudomaker.com>



Le jeu., juil. 14 2022 at 03:44:34 +0800, Mike Yang 
<reimu@sudomaker.com> a écrit :
> Hi Paul,
> 
> On 7/14/22 00:08, Paul Cercueil wrote:
>>  Hi Mike,
>>  [...]
>> 
>>>  If I comment the "wait" instruction, it will exit the suspend 
>>> process immediately. And yes, I don't think it suspended properly.
>> 
>>  Ok. I was suggesting to try that since it would show if the crash 
>> happens when a particular device gets suspended.
>> 
>>  Are you certain that your wakeup IRQ is unmasked?
> 
> I'm not sure. Which register should I check?

Check the IMCR0 / IMCR1 registers. Everything should be masked except 
your wakeup source. If your wakeup source is a GPIO, also check that 
the mask register that corresponds to your GPIO.

>> 
>>  [...]
>> 
>>>>>>   I'm afraid the above didn't work for me. Have you tested 
>>>>>> suspend-to-ram in person on a X series SoC?
>>>> 
>>>>   I didn't test on X-series, I mostly work with JZ. But that part 
>>>> of the design didn't change since the JZ4740.
>>>> 
>>>>   Cheers,
>>>>   -Paul
>>>> 
>>>> 
>>> 
>>> 
>>>  To be honest, I never owned a board with a JZ series SoC. And 
>>> sorry for assuming the suspend-to-ram is unusable on all Ingenic 
>>> SoCs. IIRC, all the JZ series SoCs have external DRAM, while the X 
>>> series SoCs have internal DRAM. Also Ingenic advertised the power 
>>> saving features of the X series SoCs heavily. Things might be 
>>> different since it may involve additional power management.
>> 
>>  Even if the 3.x method you were describing works, the currently 
>> upstream method should work as well, and if it doesn't, we probably 
>> should try to figure why.
>> 
>>  I remember doing some tests on the JZ4770 some years ago, and I 
>> would get a power consumption of 7mA when suspended - that's for the 
>> whole board, measured at the 3.7V battery, so about 0.026 W. The 
>> only things powered ON then are the RAM chips and the SoC's RTC 
>> module.
>> 
>>>  At the time of writing the last sentence of the email, Dr. Zhou 
>>> just pointed out that it may has something to do with the secure 
>>> boot feature introduced in the X series SoC, although the feature 
>>> is not enabled. I already mailed my X1000E & X1501 boards to Dr. 
>>> Zhou for further tests. You may want to get a X1000(E) board (e.g. 
>>> halley2) and test this by yourself.
>> 
>>  I do have a Cu1000-Neo board, but I have never used it, I wouldn't 
>> know how to test this.
>> 
>>  Cheers,
>>  -Paul
>> 
>> 
> 
> Earlier today, Dr. Zhou and I talked to a senior engineer from 
> Ingenic. He said an extra piece of code is necessary for the X 
> series, and more CPM registers (other than LPM) are needed to be 
> configured. The X series can't reconfigure the DRAM to exit 
> self-refresh mode by themselves. He also said, if we really don't 
> want to put the code inside the kernel, it's possible to store the 
> $pc somewhere in the RAM and modify UBoot SPL to do additional checks 
> (e.g. P0 powerup flag) and jump back to the $pc after reconfiguring 
> DRAM. I'm not sure if this will work, since the core will boot 
> straight from the BROM, and the SFC and/or MSC peripherals will be 
> reconfigured before it can load SPL again into the SRAM. It may cause 
> confusion to the kernel SFC/MSC drivers. From his words, we can have 
> another method: incorporate the code inside UBoot and write it to the 
> SRAM prior to booting the kernel. What's your opinion?

The X1000 has more CPM registers and do support turning the CPU 
completely off, which is new compared to the JZ4780, so that part is 
true. However, the regular method to enter SLEEP mode is still 
described in the X1000, X1830 and X2000 programming manuals, and it's 
the exact same method described in the JZ4780 and even in the JZ4740 
programming manuals. So allow me to doubt.

Knowing that Ingenic's 3.x kernel implements the "complete shutdown" 
sleep mode, I would think that this is why your senior engineer said 
that an extra piece of code is necessary - because that's how they 
implemented it. But that does not mean that it is required, and nothing 
in any of the X-series programming manuals suggests that it is required.

Cheers,
-Paul



  reply	other threads:[~2022-07-13 20:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12 19:19 RFC: Proper suspend-to-ram implementation of Ingenic SoCs Mike Yang
2022-07-12 20:28 ` Paul Cercueil
2022-07-12 20:51   ` Mike Yang
2022-07-12 22:20     ` Paul Cercueil
2022-07-13 11:31       ` Mike Yang
2022-07-13 16:08         ` Paul Cercueil
2022-07-13 16:13           ` Zhou Yanjie
2022-07-13 16:16             ` Paul Cercueil
2022-07-13 18:22               ` Zhou Yanjie
2022-07-13 19:44           ` Mike Yang
2022-07-13 20:57             ` Paul Cercueil [this message]
2022-07-14  4:14               ` Zhou Yanjie
2022-07-14  9:18                 ` Paul Cercueil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4V8ZER.Y1888BONB1P@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=aidanmacdonald.0x0@gmail.com \
    --cc=linux-mips@vger.kernel.org \
    --cc=reimu@sudomaker.com \
    --cc=zhouyanjie@wanyeetech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox