Searching for tester of Linux Kernel drivers

[joerg.krause]

Hi Stefan,

1. Yes, I do!
2. I prefer comments on github, it's more public.
3. I can try. However, I do not have an i.MX23 board to test with.

Any help and feedback is welcome!

Best regards
Jörg

[swahren]

Sounds great. In case of i.MX23 i think you only need to add the SRAM node to the devicetree.

[swahren]

Based on Jörg's patches i tried to make the code work with i.MX23 and i.MX28:

https://github.com/lategoodbye/linux-mxs-power/commits/rebase-4.5

Unfortunately my Olinuxino Maxi freezes after switching cpu clock source from PLL to XTAL :-(

Strangly the code work's with my i.MX28 board.

Regards
Stefan

Edit:

Here some consumption values of my i.MX28 board:

State ON: 0.988 W
State Idle: 0.5 W (echo mem > /sys/power/state BEFORE standby support)
State standby: 0.141 W (echo mem > /sys/power/state AFTER standby support)

[joerg.krause]

Hi Stefan,

I've tested your updated branch. Unfortunately, my i.MX28 board freezes, too. Measurements show that the device consumes more power compared to my branch (~20mA more) after issuing "standby". Furthermore, the device cannot be waken up.

I will try to compare the changes you made with my branch to investigate the issue.

[joerg.krause]

I was able to fix my issue by reverting commit https://github.com/lategoodbye/linux-mxs-power/commit/321656a5a9b6476f2837d0c71848e78f504ff91e.

Note that I do not use the PSWITCH pin on my board.

[swahren]

Hi Jörg,

thanks for testing, but i need more specific information:

Could you please describe the "freeze" exactly. Is really a freeze or doesn't it resume?

Do you use "no_console_suspend"?

How do you reproduce the issue (suspend and resume action) and your observation?

What issue does the revert fix ("freeze" or power consumption or both)?

[joerg.krause]

Hi Stefan,

sorry for the delay - I was quite busy.

Actually, it does not resume.

Yes, I use "no_console_suspend".

I am using a GPIO as suspend- and wakeup-source. Pulling the GPIO to low emits "echo standby > /sys/power/state" and the CPU goes into standby mode. After releasing the GPIO to high the CPU wakes up and resumes operation. In this case I measure ~15 mA current consumption in standby mode.

Without the reverted patch the device goes into the suspend state (at least mxs_suspend_in_ocram_fn is called). In this case, current consumption is about ~26 mA in standby mode. Releasing the GPIO does not wake up the CPU.

Note that PSWITCH is connected to VDDXTAL, but without a switch.

Best regards
Jörg

[swahren]

Hi Jörg,

thanks for pointing out. I reverted the commit.

Regards
Stefan

[joerg.krause]

Any idea why does it fails in my case?

[joerg.krause]

I did a fresh clone of the Linux repository and cherry-picked most of the commits from lategoodbye/rebase-4.5 https://github.com/lategoodbye/linux-mxs-power/tree/rebase-4.5 on top of the latest version tag v4.7-rc7: https://github.com/joerg-krause/linux/commits/mxs-power-v4.7-rc7.

Note that I dropped some patches from lategoodbye/rebase-4.5, e.g. adding the variants for the Duckbill boards, as I did not need them.

[swahren]

Any idea why does it fails in my case?

I tested with a Duckbill (i.MX28 platform with PSWITCH connected to VDDA) and had the same results as yours.

So it seems the ENIRQ_PSWITCH must be handled by platform PM code instead of pswitch driver. I'm still working on it.

Edit: Commited 2 fixes ...

[joerg.krause]

Hi Stefan,

I had some time to test the latest commits of your branch. I am using a sleep/wake-up gpio-key to suspend/resume the cpu. This is the corresponding dts snippet:

Code Select Expand


[..]
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpio_keys>;

sleep {
label = "Wakeup";
gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
linux,code = <KEY_SLEEP>;
wakeup-source;
};
};

[..]

pinctrl_gpio_keys: pinctrl-gpio-keys@0 {
reg = <0>;
fsl,pinmux-ids = <
MX28_PAD_LCD_VSYNC__GPIO_1_28 /* KEY_SLEEP */
>;
fsl,drive-strength = <MXS_DRIVE_4mA>;
fsl,voltage = <MXS_VOLTAGE_HIGH>;
fsl,pull-up = <MXS_PULL_DISABLE>;
};
[..]


A key event listener executes

Code Select Expand

/usr/sbin/pm-suspend when KEY_SLEEP was emitted. The cpu wakes up if I release the gpio. However, a kernel warning is printed:

Code Select Expand

[   48.365030] PM: Syncing filesystems ... done.
[   48.392543] Freezing user space processes ... (elapsed 0.011 seconds) done.
[   48.412799] Freezing remaining freezable tasks ... (elapsed 0.004 seconds) done.
[   48.459679] PM: suspend of devices complete after 26.615 msecs
[   48.474752] PM: late suspend of devices complete after 9.115 msecs
[   48.490430] PM: noirq suspend of devices complete after 9.210 msecs
[   48.512271] PM: noirq resume of devices complete after 12.327 msecs
[   48.529728] PM: early resume of devices complete after 6.975 msecs
[   48.538648] ------------[ cut here ]------------
[   48.543395] WARNING: CPU: 0 PID: 392 at kernel/irq/manage.c:605 irq_set_irq_wake+0xac/0xf4()
[   48.551874] Unbalanced IRQ 60 wake disable
[   48.556000] Modules linked in: [last unloaded: brcmutil]
[   48.561405] CPU: 0 PID: 392 Comm: pm-suspend Not tainted 4.5.0-LINTECH #1
[   48.568224] Hardware name: Freescale MXS (Device Tree)
[   48.573462] [<c000f070>] (unwind_backtrace) from [<c000d2f0>] (show_stack+0x10/0x14)
[   48.581290] [<c000d2f0>] (show_stack) from [<c0017964>] (warn_slowpath_common+0x80/0xa8)
[   48.589449] [<c0017964>] (warn_slowpath_common) from [<c00179b8>] (warn_slowpath_fmt+0x2c/0x3c)
[   48.598216] [<c00179b8>] (warn_slowpath_fmt) from [<c004ef74>] (irq_set_irq_wake+0xac/0xf4)
[   48.606649] [<c004ef74>] (irq_set_irq_wake) from [<c01bca40>] (mxs_gpio_set_wake_irq+0x1c/0x24)
[   48.615429] [<c01bca40>] (mxs_gpio_set_wake_irq) from [<c004ef90>] (irq_set_irq_wake+0xc8/0xf4)
[   48.624205] [<c004ef90>] (irq_set_irq_wake) from [<c023a27c>] (gpio_keys_resume+0x88/0xb4)
[   48.632538] [<c023a27c>] (gpio_keys_resume) from [<c01f84e4>] (dpm_run_callback+0x28/0xa0)
[   48.640858] [<c01f84e4>] (dpm_run_callback) from [<c01f893c>] (device_resume+0xc0/0x198)
[   48.649004] [<c01f893c>] (device_resume) from [<c01f97ac>] (dpm_resume+0x104/0x1e4)
[   48.656717] [<c01f97ac>] (dpm_resume) from [<c01f9a28>] (dpm_resume_end+0xc/0x18)
[   48.664262] [<c01f9a28>] (dpm_resume_end) from [<c004ac14>] (suspend_devices_and_enter+0xd4/0x420)
[   48.673281] [<c004ac14>] (suspend_devices_and_enter) from [<c004b0a0>] (pm_suspend+0x140/0x210)
[   48.682039] [<c004b0a0>] (pm_suspend) from [<c0049e08>] (state_store+0x9c/0xb8)
[   48.689413] [<c0049e08>] (state_store) from [<c011eda4>] (kernfs_fop_write+0x130/0x184)
[   48.697494] [<c011eda4>] (kernfs_fop_write) from [<c00c2dc8>] (__vfs_write+0x1c/0xd0)
[   48.705395] [<c00c2dc8>] (__vfs_write) from [<c00c3a80>] (vfs_write+0xa8/0x178)
[   48.712767] [<c00c3a80>] (vfs_write) from [<c00c44d0>] (SyS_write+0x3c/0x74)
[   48.719869] [<c00c44d0>] (SyS_write) from [<c000a140>] (ret_fast_syscall+0x0/0x1c)
[   48.727479] ---[ end trace dbbbb797e7693392 ]---


Did I missed something?

[joerg.krause]

Hi Stefan,

I applied the patches from your rebase-4.5 branch on top of a clean 4.7 linux branch: https://github.com/joerg-krause/linux/commits/mxs-power-v4.7.

After this, I compared the patches with my previous branch https://github.com/joerg-krause/linux-mxs-power/tree/standby and I figured out that your branch misses some commits from my standby branch (now applied to the 4.7 Kernel branch, too):

• https://github.com/joerg-krause/linux/commit/82540cbdea97512504120bfe0e472712920025b6
• https://github.com/joerg-krause/linux/commit/dacdd8ed192da6b22e49ff90ef43035b921f86b5

Using those commits makes the Kernel warning disappear.

[swahren]

Sorry for this inconvenience, but the two patches doesn't seem to be the right way. Since everything works before except this warning we should set IRQCHIP_SKIP_SET_WAKE instead of these two patches ( like here http://lxr.free-electrons.com/source/kernel/irq/dummychip.c )?

[joerg.krause]

I must confess I didn't take much effort to understand the warning and the two patches. If you think setting IRQCHIP_SKIP_SET_WAKE is a better solution I am absolutely fine with it. Will you add a patch to your repo?