Does Hikey960 support susped-to-mem with Linux 4.9 kernel?

Products Support HiKey 960
#1

Hi,

I am trying suspend-to-mem in Hikey960 with 4.9 kernel.
It is saying hisi_dwc3_prepare: host mode, should not go to sleep!

See full logs below.
{{{
/ # echo mem > /sys/power/state
[ 63.727263] [USB3][hisi_dwc3_prepare]hisi_dwc3_prepare: host mode, should not go to sleep!
[ 63.727283] device_prepare(): hisi_dwc3_prepare+0x0/0x160 returns -14
[ 63.727294] PM: Some devices failed to suspend, or early wake event detected
[ 63.727313] cpufreq: cpufreq_resume: Failed to start governor for policy: ffffffc0b0c02400
[ 63.727316] cpufreq: cpufreq_resume: Failed to start governor for policy: ffffffc0b0c02800
[ 63.729326] wl18xx_driver wl18xx.1.auto: firmware: ti-connectivity/wl18xx-conf.bin will not be loaded
[ 63.729333] wlcore: ERROR could not get configuration binary ti-connectivity/wl18xx-conf.bin: -11
}}}

To see what happens if I disable USB dirver, I unset CONFIG_USB_DWC3.
But while trying suspend-to-mem, boards hung after below command.
echo mem > /sys/power/state
No further messages in serial console and board rebooted after few seconds.

  • I am searching for a working scenario where susped-to-mem is found working on
    Hikey960 with Linux kernel.

  • Does anybody know, Hikey960 supports power management/suspend-to-mem
    with Liunx kernel?

If it supports, could you please tell me about the

  • Linux kernel version (giving git commit hash will also help)
  • dtb file name and
  • rootfs to be used.

Regards,
Sreenad.

#2

Hi,

The suspend-to-mem on Linux 4.9 kernel has hang issue: https://bugs.96boards.org/show_bug.cgi?id=611

#3

Hi,

Hang happens when it tries to access registers of the below devices

While suspending (hang)

  • ffd72000.i2c

  • ff3b5000.gpio

  • ff3b4000.gpio

While resuming (hang) (for resuming, I used SD card insert interrupt. RTC wakeup is not working)

  • e8a11000.gpio

  • ff3b4000.gpio

  • ff3b5000.gpio

There may be some prerequisites for accessing them.
Currently I am skipping those register access for the above devices for suspend/resume.

If anyone find a fix, please update it here.

Regards,
Sreenad.

#4

Thanks, @sreenad. Have updated the shared info in bug ticket.

#5

I have fixed the issues.
Now GPIOs can be suspended. And wakeup from RTC is working.

#6

This is Great!

You could directly to commit patch to gerrit: https://android-review.googlesource.com. I saw you are using github repositories, we have one official Linux kernel maintenance for Android Hikey960: kernel/hikey-linaro - Git at Google, branch: android-hikey-linaro-4.9. Suggest you could use this branch so can directly send patch onto it with gerrit.

Linaro John Stultz has some wiki pages for how to summit patches to gerrit: https://wiki.linaro.org/Process/PushingBitsToAndroid
https://wiki.linaro.org/Platform/Android/Upstreaming

Please note, gerrit is not public mailing list, so you need manually to add reviewers: John Stultz, Guodong Xu.

#7

Thanks Leo.

Basically, GPIO18 and GPIO19 are in UFS_PERI_SUBSYS area as said in SoC reference manual.

I have verified, those GPIO register become unaccessible after the UFS controller suspend callback is called.

So did a late suspend and early resume for UFS controller.

https://android-review.googlesource.com/c/kernel/hikey-linaro/+/689845

Regards,
Sreenad.

1 Like
Suspend - Resume in Hikey960 platform
#8

You are very welcome, @sreenad.

This issue has been pending for long time, so very appreciate your working to resolve partial suspend/resume issue and share the knowledge with us. :slight_smile:

Will follow up related testing for your patch on gerrit.

#9

Hi Leo,

This is how it is found out.

Created a ‘extern void __iomem *variable’ and assigned the problem causing chip->base to it. Tried readb() after every suspend callback is returned.
It hung after ufs contoller suspend.
Also printed the device linked list and checked the order in linked list for ufs controller and gpio18.
Also I got a supporting statement from SoC reference manual regarding the relation between UFS controller and gpio18 and gpio19.

Issue in ffd72000.i2c (or i2c1) was solved. That fix was given by synopsis for their drivers,
in 4.13 mainline kernel I guess. Kernel version and source location I forgot.

Anyways while working in this, I have also verified, i2c1 gives suspend issues during suspend-to-mem, because it was already suspend by runtime PM kworker and the driver was not tracking its current state. We can see suspend callback is called even before rootfs is mounted.

In my opinion, setting dev->power.is_suspended after suspend
and check this before going again for suspend is enough.
Do such a check in resume call back as well.

Anyways I have not found similar code in
kernel/hikey-linaro - Git at Google, branch: android-hikey-linaro-4.9
So I cannot submit my patch to the gerrit for i2c1 suspend fix.

#10

Hi Leo,

I am interested to look at AOSP hikey960 suspend-to-mem support.

I have followed Using Reference Boards  |  Android Open Source Project for hikey960
AOSP building from source.
But failed in repo sync due to proxy related issues.

So I am thinking about using a prebuilt AOSP image for hikey960 from
[https://www.96boards.org/documentation/consumer/hikey960/downloads/aosp.md.html]
and replace kernel and dtb images.

I came across the below script for boot.img creation,
[https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/gen_boot_dts_imgs-sample.sh]

But from where I can get a ramdisk.img for the above script to work?
[https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-build-from-source.md#build-procedure]
This above link says it is not available yet.

BTW, ramdisk is really necessary?

FYI: Till now I was working by chaging kernel and dtb in debian prebuilt images.
I even tried to boot using android-hikey-linaro-4.9 branch, but after debian rootfs is mounted not moving forward.
I think that kernel expects a andorid userspace. (Not sure)

Regards,
Sreenad.

#11

@sreenad,

Cool. Thanks a lot for your work!

Please send a Pull Request to [1] if you want to have this change only in Linaro builds. Otherwise if you want your changes to be in mainline, send the patches to relevant mailing list [2].

But before that, can you please share your changes with us?

Thanks,
Mani

[1] https://github.com/96boards-hikey/linux
[2] Submitting patches: the essential guide to getting your code into the kernel — The Linux Kernel documentation

#12

Dear Mani,

Currently I am trying to check my fix patch in [https://github.com/96boards-hikey/linux/tree/hikey960-v4.9]

But the below problem is a blocker for me now.
link to forum-> [No serial console on debug uart after rootfs is mounted]

If you have any idea, I can quickly test my fix patch on the above source tree
and update you the result.

Regards,
Sreenad.

#13

Hi, @leo-yan, @Mani,

I have booted with kernels from

Below is my observation:

  • In 4.15 kernel, hisilicon dwc3 usb drivers are not yet support.
    It also hang during suspend-to-mem. (I did not debug much in this kernel.)

  • In android-hikey-linaro-4.9, no serial console(via debug uart) after rootfs is mounted.
    ( How people in this community are getting serial console with android-hikey-linaro-4.9 branch from AOSP repo.) (Am I the only one facing this? :thinking:)

Let me again come to issues identified in suspend-resume support in 4.9 kernel (See this bug ticket also)

  1. GPIO18 and GPIO19 hang during suspend-to-mem. (fixed by patch)
  2. USB host prevents system from suspend during suspend prepare stage. (not yet fixed)

Now I am concentrating on USB host mode suspend.

In my understanding, it is a hisilicon specific implementation and not a hardware from
synopsis.

I would like to know from where I can get datasheet for that module.?

Any help will be greatly appreciated.

Thanks in Advance

Regards,
Sreenad Menon.

#14

Nobody else is having problems with the serial console for AOSP with kernel 4.9. That seems to be something uniquely yours.

A few days ago you said that you tried to and gave up on building AOSP from source. That could very easily be where your problem is coming from. I suggest that you get that working rather than trying to hack together pieces.

Also make sure that you are connecting to the correct serial port. There are TWO. Default serial console is to be found on UART1 at pins 11 (TX), 13 (RX) of LS connector. Use “screen /dev/ttyUSBx 115200” to connect to serial console from your workstation.