Searching for tester of Linux Kernel drivers

Started by swahren, November 21, 2014, 07:49:39 PM

Previous topic - Next topic

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

#47
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


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


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

#55
Quote from: joerg.krause on July 18, 2016, 01:39:58 PM
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:


[..]
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 /usr/sbin/pm-suspend when KEY_SLEEP was emitted. The cpu wakes up if I release the gpio. However, a kernel warning is printed:

[   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):

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?