Re: power states transitions
On Wed, Nov 25, 2015 at 8:50 PM, Tony Lindgren <t...@atomide.com> wrote:
> * Ran Shalit <ransha...@gmail.com> [151122 07:59]:
>> Hello,
>>
>> I have stranhe behaviour in which even when there is no activity in
>> serial port, the retention counter is keep incremented all these time,
>> as if the cpu gets in and out of retention periodically.
>> I would expect the cpu to get into retention mode, when there is no
>> activity and stay in that state.
>> What can cause such behaviour ? Is it because some background process ?
>
> Sounds like your device is hitting deper idle states during idle. If
> you want to disable that, set the UART autosuspend_delay_ms to -1:
>
> #/bin/bash
> uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
> for uart in $uarts; do
> echo -1 > $uart/autosuspend_delay_ms 2>&1
> done
>
> The above will keep the UARTs active blocking any deeper idle
> states. I believe the value has to be -1 instead of 0 to disable
> autoidle.. but please verify yourself.
>
>> My original problem is that the ethernet performance is very low with
>> small windows. I thought that I can control this value by changing
>> sleep_latency parameter in
>> the following array. Yet, it did not help me. I don't know why.
>
> Maybe test if the above script helps with the Ethernet too. If the
> Ethernet controller is on GPMC, it's not blocking deeper idle states
> automatically in hardware. Adding DMA support to the Ethernet driver
> would be a good way to block deeper idle states automatically by
> the Ethernet hardware.
>
Hi Tony,
We actually want the deeper state, but not in the price of performance...
So I thought of these possibilities:
1. configure the sleep state to check activity for a longer time than
micro seconds (several seconds). If there is non activity in that long
period, only than will move to retention. I am not sure if there is
such configuration parameter . Maybe one of the following parameters
can be configured for this option ?
46 struct cpuidle_params {
47 u32 exit_latency; /* exit_latency = sleep + wake-up
latencies */
48 u32 target_residency;
49 u8 valid; /* validates the C-state */
50 };
2. Another option can be to write a kernel module which check if there
is ethernet activity for X seconds, if there is none - it will enable
power management , otherwise - it will disable the power management.
These maybe can solve the ethernet issue, but I still not sure why
there is constantly incrementation in the retention state, as if it
enter and leave the state all periodically. Is it becuase some
task/thread/process in the system (I guess it can be a kernel process
actually) ?
Regards,
Ran
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
power states transitions
Hello,
I have stranhe behaviour in which even when there is no activity in
serial port, the retention counter is keep incremented all these time,
as if the cpu gets in and out of retention periodically.
I would expect the cpu to get into retention mode, when there is no
activity and stay in that state.
What can cause such behaviour ? Is it because some background process ?
These are the processes I see using ps command :
~ # ps
PID USER VSZ STAT COMMAND
1 root 2088 Sinit
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [kworker/0:0]
5 root 0 SW [kworker/u:0]
6 root 0 SW< [khelper]
7 root 0 SW [irq/72-serial i]
8 root 0 SW [irq/73-serial i]
9 root 0 SW [irq/74-serial i]
10 root 0 SW [sync_supers]
11 root 0 SW [bdi-default]
12 root 0 SW< [kblockd]
13 root 0 SW [khubd]
14 root 0 SW [kseriod]
15 root 0 SW< [twl4030-irqchip]
16 root 0 SW [twl4030-irq]
17 root 0 SW [irq/378-twl4030]
18 root 0 SW [kworker/u:1]
19 root 0 SW< [musb-hdrc.0]
20 root 0 SW< [kconservative]
21 root 0 SW [kswapd0]
22 root 0 SW< [aio]
23 root 0 SW< [crypto]
29 root 0 SW [mtdblock0]
30 root 0 SW [mtdblock1]
31 root 0 SW [mtdblock2]
32 root 0 SW [mtdblock3]
33 root 0 SW [mtdblock4]
34 root 0 SW [mtdblock5]
35 root 0 SW [mtdblock6]
36 root 0 SW [mtdblock7]
37 root 0 SW [mtdblock8]
38 root 0 SW [mtdblock9]
41 root 0 SW [kworker/0:1]
42 root 0 SW< [kondemand]
43 root 0 SWN [jffs2_gcd_mtd5]
46 root 0 SWN [jffs2_gcd_mtd6]
47 root 0 SWN [jffs2_gcd_mtd8]
48 root 0 SWN [jffs2_gcd_mtd7]
71 root 2364 S/usr/sbin/inetd
74 root 2092 S-/bin/sh
93 root 2092 Rps
~ #
My original problem is that the ethernet performance is very low with
small windows. I thought that I can control this value by changing
sleep_latency parameter in
the following array. Yet, it did not help me. I don't know why.
static struct cpuidle_params cpuidle_params_table[] = {
/* C1 */
{0, 2, 2, 5},<-- changed valid to 0 (I am interested in
getting into deepest state)
/* C2 */
{0, 10, 10, 30}, <-- changed valid to 0 (I am interested in
getting into deepest state)
/* C3 */
{0, 50 , 50, 300}, <-- changed valid to 0 (I am interested in
getting into deepest state)
/* C4 */
{1, 150 , 1800, 4000}, <-- changed sleep_latency to 150
}
Best Regards,
Ran
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ALSA DMA ping-pong
Hello, I hope someone can help me understand the concept of ping-pong dma with ALSA. I am using davinci soc: /sound/soc/davinci/davinci_pcm.c But I am not sure if it using ping-pong dma or not. In the header of "davinci_pcm_enqueue_dma" function it states "Not used with ping/pong", but inside I see that it use period parameter in order to set the offset inside the dma buffer which is used. So, does it mean that ping-pong is used or not ? /* * Not used with ping/pong */ static void davinci_pcm_enqueue_dma(struct snd_pcm_substream *substream) . period_size = snd_pcm_lib_period_bytes(substream); dma_offset = prtd->period * period_size; dma_pos = runtime->dma_addr + dma_offset; acnt = prtd->params->acnt; edma_set_src(link, src, INCR, W8BIT); edma_set_dest(link, dst, INCR, W8BIT); .. } Regards, Ran -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle results in ethernet degredation ?
On Tue, Aug 4, 2015 at 11:09 AM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [150803 07:03]: I am using GPMC with smsc911x controller. If I understand you correctly, I can overcome this, but asking the hardware not get into inactive state. Correct. Probably the automatic way to block deeper idle states here with GPMC would be to implement DMA transfers for smsc911x. Then the hardware would not enter deeper idle states when a DMA transfer is in progress. Of course there may be still other tuning needed too. Hi Tony, but why does it happen in small packet test and not in big packets ? as to your suggestion above, Can you please give a hint as to how to add DMA usage into ethernet ? Regards, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle results in ethernet degredation ?
On Mon, Aug 3, 2015 at 4:21 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [150801 11:34]: Hi , I've accidently omitted linux-omap in last message, so please here it is again: I think that if someone here understand cpuidle it may lead me to a solution... 1. I'm using TI's kernel 2.6.37 http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/ Hmm that's not the TI kernel, that's where we keep the omap patches heading to the mainline kernel tree :) 2. I think it is related to the menu governer who decides on c-state change. But I'm not sure what and how I need to change so that the ethernet test for small windows will have same performance as without PM. 3. I see that the performace as tested with iperf has the same performace results with large packets but with small packets (smaller then 2000 bytes) there is high degredation (only if cpuidle is used) I also see that the counter for C3(core inactive - not retention yet) state is icremented with the small packet test. Does anyone have any idea why the small packet test results in entering (and exit ) several times the core inactive state? Why does not it happen with big packet test? And what can I do to overcome this degredation? 4. Can anyone try to run iperf with small packet (2000 bytes or below) for checking ethernet bandwidth? And then compare this with results in kernel without power management support? If you don't have anything blocking deeper idle states from the Ethernet controller then the hardware can start entering deeper idle states. I can see this happening when transferring data with DMA over Ethernet especially if you have an external Ethernet controller connected to GPMC. If you cannot rely on the hardware IDLEST bits to keep the system from entering deeper idle states, then you have to use the runtime PM API to do it somehow. Regards, Tony Hi, I am using GPMC with smsc911x controller. If I understand you correctly, I can overcome this, but asking the hardware not get into inactive state. I actully need that the code won't get into inactive state (I don't think that anyelse is inactive, except the core - this is C3 state). The problem with this approach is that I'm not sure I can determine when to decide turn cpuidle off and when to decide turn cpuidle on. I thought that if there is a way to ask the governer (in tickless kernel, it is menu governer), to wait for a longer time, before deciding to get into sleep. I think that if it waits longer time, it will see that there are tasks to do (small packets in iperf test), and will not enter sleep state. Is that possible ? Is there any parameter in governer which control this ? Thank you, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle results in ethernet degredation ?
Hi , I've accidently omitted linux-omap in last message, so please here it is again: I think that if someone here understand cpuidle it may lead me to a solution... 1. I'm using TI's kernel 2.6.37 http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/ 2. I think it is related to the menu governer who decides on c-state change. But I'm not sure what and how I need to change so that the ethernet test for small windows will have same performance as without PM. 3. I see that the performace as tested with iperf has the same performace results with large packets but with small packets (smaller then 2000 bytes) there is high degredation (only if cpuidle is used) I also see that the counter for C3(core inactive - not retention yet) state is icremented with the small packet test. Does anyone have any idea why the small packet test results in entering (and exit ) several times the core inactive state? Why does not it happen with big packet test? And what can I do to overcome this degredation? 4. Can anyone try to run iperf with small packet (2000 bytes or below) for checking ethernet bandwidth? And then compare this with results in kernel without power management support? Regards, Ran On Fri, Jul 31, 2015 at 7:40 PM, Robert Nelson robertcnel...@gmail.com wrote: On Fri, Jul 31, 2015 at 11:29 AM, Ran Shalit ransha...@gmail.com wrote: On Thu, Jul 30, 2015 at 9:49 PM, Ran Shalit ransha...@gmail.com wrote: Hello, I hope some will have some idea: I am using iperf to check bandwidth and I see that with small tcp windows in the test there is always high degredation in performance compared to version without cpuidle. I've noticed that C3 state (core inactive) is entered several times during the test, which might explaing this degredation. With bug tcp windows it works well (why ?) I would like to ask if there is any idea what I can do to overcome this issue so that there will be no degredation in performance? Thank you, Ran Does anyone have any idea ? Which kernel? Mainline or if ti's which branch? Regards, -- Robert Nelson https://rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle results in ethernet degredation ?
On Thu, Jul 30, 2015 at 9:49 PM, Ran Shalit ransha...@gmail.com wrote: Hello, I hope some will have some idea: I am using iperf to check bandwidth and I see that with small tcp windows in the test there is always high degredation in performance compared to version without cpuidle. I've noticed that C3 state (core inactive) is entered several times during the test, which might explaing this degredation. With bug tcp windows it works well (why ?) I would like to ask if there is any idea what I can do to overcome this issue so that there will be no degredation in performance? Thank you, Ran Does anyone have any idea ? Regards, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cpuidle results in ethernet degredation ?
Hello, I hope some will have some idea: I am using iperf to check bandwidth and I see that with small tcp windows in the test there is always high degredation in performance compared to version without cpuidle. I've noticed that C3 state (core inactive) is entered several times during the test, which might explaing this degredation. With bug tcp windows it works well (why ?) I would like to ask if there is any idea what I can do to overcome this issue so that there will be no degredation in performance? Thank you, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit ransha...@gmail.com wrote: We currently are missing dm8148 support from mainline, dm8168 does have basic support now. Adding dm8148 will hopefully happen too with time permitting :) Hi Tony, What is exactly the voltage driver capability ? Does it mean that it does not support AVS (feature for power saving) ? Regards, Ran Hi Tony, Is it AVS or voltage scaling (used with cpufreq) ? Thank you, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
no opp match error
Hello, I get in boot of board the following error: omap_target: cpu0: no opp match for freq 90. I see that the failure is in function cpufreq-opp_find_freq_exact(). Does is mean that cpufreq fails and do nothing ? How can I fix this error ? Regards, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
We currently are missing dm8148 support from mainline, dm8168 does have basic support now. Adding dm8148 will hopefully happen too with time permitting :) Hi Tony, What is exactly the voltage driver capability ? Does it mean that it does not support AVS (feature for power saving) ? Regards, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap voltage management
Hello, I am using DM8148 and I get error message in boot that voltage management driver is not added. Is it supported in DM8148. If not - why ? Thank you, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap voltage driver errors
Hello, I receive the following errors in boot: omap_voltage_early_init: voltage driver support not added regulator: core version 0.5 regulator: dummy: NET: Registered protocol family 16 omap_voltage_domain_lookup: Voltage driver init not yet happened.Faulting! omap_voltage_add_dev: VDD specified does not exist! . It seems that omap_voltage_early_init should be called somehow, but I don't see it being called anywhere in kernel. Is anyone familiar with this ? Regards, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ethernet WOL (wake on lan)
Hello, I would please like to ask how I should use therenet WOL (wake on lan) ? I am using device smsc911x, and I can see in code that there is reference to WOL. But I don't understand how this should function. Should I call smsc911x_suspend() smsc911x_resume() or does it automatically suspend/resume ? Generally speaking I rather is to stop/start automatically. Thanks, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reboot command fails with low frequency
I added power support to kernel menuconfig, such as cpuidle, and it seems to work fine. I also validated in counter that cpu gets into retention. We observer that with highest available frequency (60) reboot command is OK, but when frequency is changed to lower value, the reboot command fails. Has anyone observed such behaviour ? Regards, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reboot command fails with low frequency
We observer that with highest available frequency (60) reboot command is OK, but when frequency is changed to lower value, the reboot command fails. Has anyone observed such behaviour ? I remember some commit for this problem. What version of the linux are you running? I use Linux version 2.6.37 #36 PREEMPT Thu Mar 5 10:56:04 IST 2015 armv7l GNU/Linux Do you know how I can find this fix ? Thanks! Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reboot command fails with low frequency
On Thu, Mar 5, 2015 at 12:58 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Hi
You should find the twl4030 power script and you should have something like
this
static struct twl4030_ins wrst_seq[] __initdata = {
{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wrst_script __initdata = {
.script = wrst_seq,
.size = ARRAY_SIZE(wrst_seq),
.flags = TWL4030_WRST_SCRIPT,
};
static struct twl4030_script *omap3_power_scripts[] __initdata = {
wrst_script,
};
If I remember it was solved by some change here. In my old kernel I
have this commit
Fix the reboot at lower frequency
Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com
diff --git a/arch/arm/mach-omap2/board-panther.c
b/arch/arm/mach-omap2/board-panther.c
index ad2adf3..c71fdd9 100644
--- a/arch/arm/mach-omap2/board-panther.c
+++ b/arch/arm/mach-omap2/board-panther.c
@@ -368,7 +368,7 @@ static int __init panther_i2c_init(void)
{
omap3_pmic_get_config(panther_twldata,
TWL_COMMON_PDATA_MADC |
- TWL_COMMON_PDATA_AUDIO,
+ TWL_COMMON_PDATA_AUDIO | TWL_COMMON_PDATA_POWER,
TWL_COMMON_REGULATOR_VDAC);
omap3_pmic_init(twl4030, panther_twldata);
But this apply on an old device with a newer kernel and I don't
remember now the reason ;) Sorry.
Is this an android device? (2.6.37??? is really old)
I have something quite different in my code:
static int __init twl4030_config_warmreset_sequence(u8 address)
{
int err;
u8 rd_data;
/* Set WARM RESET SEQ address for P1 */
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, address,
R_SEQ_ADD_WARM);
if (err)
goto out;
/* P1/P2/P3 enable WARMRESET */
err = twl_i2c_read_u8(TWL4030_MODULE_PM_MASTER, rd_data,
R_P1_SW_EVENTS);
if (err)
goto out;
rd_data |= ENABLE_WARMRESET;
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, rd_data,
R_P1_SW_EVENTS);
if (err)
goto out;
err = twl_i2c_read_u8(TWL4030_MODULE_PM_MASTER, rd_data,
R_P2_SW_EVENTS);
if (err)
goto out;
rd_data |= ENABLE_WARMRESET;
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, rd_data,
R_P2_SW_EVENTS);
if (err)
goto out;
err = twl_i2c_read_u8(TWL4030_MODULE_PM_MASTER, rd_data,
R_P3_SW_EVENTS);
if (err)
goto out;
rd_data |= ENABLE_WARMRESET;
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, rd_data,
R_P3_SW_EVENTS);
out:
if (err)
pr_err(TWL4030 warmreset seq config error\n);
return err;
}
And the board is TI's board_omap3evm.c.
Ran
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reboot command fails with low frequency
I think I can also do some workaround if I set the frequency to the highest level just before doing reset. The thing is that I mustn't use sysfs in my system. Is there some way to set frequency without using sysfs ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
reboot command - fail with power save support
Hello, I added power support to kernel menuconfig, such as cpuidle, and it seems to work fine. I also validated in counter that cpu gets into retention. The strange thing is that reboot now doesn't work and more: it starts printing garbage, but does not continue with reboot. Is there any idea ? Thank you, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
suspend ethernet only , with WOL (wake on lan)
Hello, I am using OMAP3530 with SMSC911X phy. I see in smsc911 driver that it contain WOL (wake on lan) feature here: http://lxr.free-electrons.com/source/drivers/net/ethernet/smsc/smsc911x.c 1. Is it that to enable WOL I just need ethtool (without configuring anything in kernel) ? https://wiki.archlinux.org/index.php/Wake-on-LAN 2. Is there a way to suspend ethernet only (without the full system suspend), so that it will then WOL (wake on lan) ? Thank you, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fail to enter retention
Hi Tony, When I try to do suspend from userspace, I get better results and it seems that all domain been put to RET or OFF but on checking power state time it still shows 0. Do you know why ? usbhost_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:5,INA:4,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 neon_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm-per_pwrdm (11) usbhost_clkdm-usbhost_pwrdm (3) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (2) core_l4_clkdm-core_pwrdm (12) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) Thank you, Ran On Mon, Nov 17, 2014 at 11:09 PM, Ran Shalit ransha...@gmail.com wrote: Hi Tony, Just printing the registers out in the idle loop most likely will give you the info you need. Probably a dumb question... But if I try to print them won't it automatically wakes up the serial (by the way should the serial wakeup be configured to RX pin only ?) Another thing I don't understand... Can it be that there is some ongoing kernel process that also prevent me for entering retention ? I think maybe I should try first to suspend (instead of trying to enter retention in idle) , maybe it might bring better result ? Thanks very much, Ran On Mon, Nov 17, 2014 at 10:38 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [141117 11:48]: You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. I'll check the registers value, should I then try to modify this registers in order to get into retention ? No, those are read-only status registers. You need idle the drivers that show as blocking in those registers. I will still have to disable serial right ? Maybe some kernel process which run in background prevents retention ? Yes otherwise the UART bits will show as blocking in those registers. Is there some simple way to debug this or do I need to modify these registers ? Just printing them out in the idle loop most likely will give you the info you need. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fail to enter retention
Hi, In coninuity to my previous message, thse is the log for time in state 0-state 6: 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state0/time 761849079 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state1/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state2/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state3/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state5/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state6/time 0 Regards, Ran On Tue, Nov 18, 2014 at 10:21 AM, Ran Shalit ransha...@gmail.com wrote: Hi Tony, When I try to do suspend from userspace, I get better results and it seems that all domain been put to RET or OFF but on checking power state time it still shows 0. Do you know why ? usbhost_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:5,INA:4,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 neon_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm-per_pwrdm (11) usbhost_clkdm-usbhost_pwrdm (3) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (2) core_l4_clkdm-core_pwrdm (12) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) Thank you, Ran On Mon, Nov 17, 2014 at 11:09 PM, Ran Shalit ransha...@gmail.com wrote: Hi Tony, Just printing the registers out in the idle loop most likely will give you the info you need. Probably a dumb question... But if I try to print them won't it automatically wakes up the serial (by the way should the serial wakeup be configured to RX pin only ?) Another thing I don't understand... Can it be that there is some ongoing kernel process that also prevent me for entering retention ? I think maybe I should try first to suspend (instead of trying to enter retention in idle) , maybe it might bring better result ? Thanks very much, Ran On Mon, Nov 17, 2014 at 10:38 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [141117 11:48]: You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. I'll check the registers value, should I then try to modify this registers in order to get into retention ? No, those are read-only status registers. You need idle the drivers that show as blocking in those registers. I will still have to disable serial right ? Maybe some kernel process which run in background prevents retention ? Yes otherwise the UART bits will show as blocking in those registers. Is there some simple way to debug this or do I need to modify these registers ? Just printing them out in the idle loop most likely will give you the info you need. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fail to enter retention
Hi Tony, I eventually managed to enter retention :)) I did the following changes: 1. added CONFIG_SUSPEND (though I do not use suspend/resume but only cpuidle, it seems to have some effect, I think without it the wakeup in console did not function correctly. 2. enabled sleep for all uart not just the console uart (as I did at first) 3. uart rx was configured as wakeup source Than I can see that cpu0/state4/time is incremented. As I understand state4 is retention in OMAP3530. The only bit strange thing is that I still see picture in screen. I wander how omap can enter retention can be while screen is on. Thanks very much for your assistance, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fail to enter retention
Hi Tony, Thanks very much for suggestions, I am able to wakeup the uart (though it takes about 10 seconds till it wakeup). Anyway, after wakeup when I try to see the state I get: ~ # cat /dbg/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:3,INA:4,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 neon_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm-per_pwrdm (11) usbhost_clkdm-usbhost_pwrdm (3) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (2) core_l4_clkdm-core_pwrdm (12) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state0/time 811807044 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state2/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state3/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state5/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state6/time 0 Do you have any suggestion, how I can understnad why it did not get into retention and how to continue from this point ? Thanks very much, Ran On Mon, Nov 17, 2014 at 6:22 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [141116 12:13]: Hello, I'm using OMAP3530 with custom board. I have enabled all power mode features as described in PSP wiki, but it still fails to enter any state different from state0. Works for me with pretty much all omap3 boards I have here with mainline kernel since v3.17 using omap2plus_defconfig. And the following script to idle uarts and enable off-idle (or retention). USB needs to be disconnected and EHCI probably still cannot be enabled. The next thing was trying to get the uart to sleep (though there might be also problems with other domains ?) . On trying to enable uart as wakeup source I get the following: echo enabled /sys/devices/platform/omap/omap_uart.2/power/wakeup cat /sys/devices/platform/omap/omap_uart.2/power/wakeup # disabled (?) echo 1 /sys/devices/platform/omap/omap_uart.2/sleep_timeout ~ # [ 85.006622] omap_device: omap_uart.2: new worst case deactivate latency 0: 61035 [ 85.559844] omap_device: omap_uart.2: new worst case activate latency 0: 61035 [ 982.415161] omap_device: omap_uart.2: new worst case deactivate latency 0: 91552 console hangs here Sounds like you need to enable the wake-up interrupt for the UART. See the interrupts-extended entry for many omap3-*.dts files: interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX; If you get it working, care to update the instructions in the wiki too? Regards, Tony 8 -- #!/bin/bash uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms 21 done uarts=$(find /sys/class/tty/ttyO*/power/ -type d 2/dev/null) for uart in $uarts; do echo enabled $uart/wakeup 21 echo auto $uart/control 21 done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Smartreflex - validation failed
Hello, Does anyone knows how to validate smartreflex operation? I am setting new fequency but I than see that the voltage in all points is still the same as following: It seems that smartreflex is not enabled in default, so I enable smartreflext as following: ~ # echo 1 /dbg/voltage/vdd_core/smartreflex/autocomp ~ # echo 1 /dbg/voltage/vdd_mpu/smartreflex/autocomp I than change the frequency but I always see the same voltage as following: ~ # echo 55 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed ~ # cat /dbg/voltage/vdd_core/smartreflex/autocomp 1 ~ # cat /sys/class/regulator/regulator.1/microvolts 180 ~ # cat /sys/class/regulator/regulator.2/microvolts 185 ~ # cat /sys/class/regulator/regulator.3/microvolts 180 ~ # cat /sys/class/regulator/regulator.4/microvolts 280 ~ # cat /sys/class/regulator/regulator.5/microvolts 180 ~ # cat /sys/class/regulator/regulator.6/microvolts 180 ~ # cat /sys/class/regulator/regulator.7/microvolts 280 ~ # cat /sys/class/regulator/regulator.1/microvolts 180 ~ # cat /sys/class/regulator/regulator.2/microvolts 185 ~ # cat /sys/class/regulator/regulator.3/microvolts 180 ~ # cat /sys/class/regulator/regulator.4/microvolts 280 ~ # cat /sys/class/regulator/regulator.5/microvolts 180 ~ # cat /sys/class/regulator/regulator.6/microvolts 180 ~ # cat /sys/class/regulator/regulator.7/microvolts 280 ~ # ~ # echo 50 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed ~ # cat /dbg/voltage/vdd_core/smartreflex/autocomp 1 ~ # cat /sys/class/regulator/regulator.1/microvolts 180 ~ # cat /sys/class/regulator/regulator.2/microvolts 185 ~ # cat /sys/class/regulator/regulator.3/microvolts 180 ~ # cat /sys/class/regulator/regulator.4/microvolts 280 ~ # cat /sys/class/regulator/regulator.5/microvolts 180 ~ # cat /sys/class/regulator/regulator.6/microvolts 180 ~ # cat /sys/class/regulator/regulator.7/microvolts 280 ~ # cat /sys/class/regulator/regulator.1/microvolts 180 ~ # cat /sys/class/regulator/regulator.2/microvolts 185 ~ # cat /sys/class/regulator/regulator.3/microvolts 180 ~ # cat /sys/class/regulator/regulator.4/microvolts 280 ~ # cat /sys/class/regulator/regulator.5/microvolts 180 ~ # cat /sys/class/regulator/regulator.6/microvolts 180 ~ # cat /sys/class/regulator/regulator.7/microvolts 280 ~ # Thanks for any suggestions, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fail to enter retention
You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. I'll check the registers value, should I then try to modify this registers in order to get into retention ? I will still have to disable serial right ? Maybe some kernel process which run in background prevents retention ? Is there some simple way to debug this or do I need to modify these registers ? Thank you very much, Ran On Mon, Nov 17, 2014 at 8:09 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [141117 09:14]: Hi Tony, Thanks very much for suggestions, I am able to wakeup the uart (though it takes about 10 seconds till it wakeup). The wake-up should happen within few hundred milliseconds at most. Sounds like you're waking on some timer event instead. Do you have any suggestion, how I can understnad why it did not get into retention and how to continue from this point ? You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fail to enter retention
Hi Tony, Just printing the registers out in the idle loop most likely will give you the info you need. Probably a dumb question... But if I try to print them won't it automatically wakes up the serial (by the way should the serial wakeup be configured to RX pin only ?) Another thing I don't understand... Can it be that there is some ongoing kernel process that also prevent me for entering retention ? I think maybe I should try first to suspend (instead of trying to enter retention in idle) , maybe it might bring better result ? Thanks very much, Ran On Mon, Nov 17, 2014 at 10:38 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [141117 11:48]: You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. I'll check the registers value, should I then try to modify this registers in order to get into retention ? No, those are read-only status registers. You need idle the drivers that show as blocking in those registers. I will still have to disable serial right ? Maybe some kernel process which run in background prevents retention ? Yes otherwise the UART bits will show as blocking in those registers. Is there some simple way to debug this or do I need to modify these registers ? Just printing them out in the idle loop most likely will give you the info you need. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fail to enter retention
Hello, I'm using OMAP3530 with custom board. I have enabled all power mode features as described in PSP wiki, but it still fails to enter any state different from state0. ~ # cat /dbg/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:3,INA:4,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 neon_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm-per_pwrdm (11) usbhost_clkdm-usbhost_pwrdm (3) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (2) core_l4_clkdm-core_pwrdm (12) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) The next thing was trying to get the uart to sleep (though there might be also problems with other domains ?) . On trying to enable uart as wakeup source I get the following: echo enabled /sys/devices/platform/omap/omap_uart.2/power/wakeup cat /sys/devices/platform/omap/omap_uart.2/power/wakeup # disabled (?) echo 1 /sys/devices/platform/omap/omap_uart.2/sleep_timeout ~ # [ 85.006622] omap_device: omap_uart.2: new worst case deactivate latency 0: 61035 [ 85.559844] omap_device: omap_uart.2: new worst case activate latency 0: 61035 [ 982.415161] omap_device: omap_uart.2: new worst case deactivate latency 0: 91552 console hangs here Thanks for any suggestions, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
understanding cpuidle
Hello,
I try to understand the cpuidle main concept but have some
difficulties. I could not find any documentation to explain the
cpuidle.
what does it mean that it enters idle when no thread to run ?if I
have only one process which does only
while(1)
{
printf(C);
mdelay(1000);
}
Can I expect it to enter idle for 1 second and then print C and get
again to idle ?
Thanks
Ran
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nand gpmc - overriden values in kernel
Hello, In omap2_nand_gpmc_retime() the kernel override the gpmc cs configuration with other values. It resulted in failure of nand detection in some boards. Is there any reason for the override of gpmc cs values ? Thanks, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cpuidle vs suspend/resume
Hello, I am trying to understand the relation between HW PWM, and the linux mechanism (cpuidle and suspend/resume). If you are familiar with the relations between the 2 I wil appreciate your comments. For example, are the wakeup source relevant for changing the cpu state or do they trigger change only if suspend/resume mechanism is used ? Is the c-state (which is changed by the cpuidle mechanism) relevant for the state of the cpu only (without the peripheral devices) ? Thanks, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cpuidle and SW sleep
Hello, Is there anyone who can please explain the relation between SW sleep (such as udelay), to change of C-state as done by cpuidle ? How is wakeup done ? As far as I understand udelay is sw delay not HW. Thanks for you comments, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SRAM - power management
Hello, What happens to SRAM when omap gets into retention ? Does it need a speciasl treatment ? Thanks, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cpuidle - minimum time for sleep
Hello, Does anybody know what is the minimum expected time for sleep period with the cpuidle ? I intend t use the menu governer, and I try to estimate the sleep time. Thanks, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ideas about idle loop and power management
Hello, I have a system which is required to have 2 modes operation: 1. idle - in which devices in Soc and on board should be off. 2. active mode Moving from idle to active on interrupt, and moving from active to idle when there is inactivity. After reading and re-reading about PM various mechanism, I got to conculsion that the best and easiest way to achive this on omap (omap3530) will be as following: 1. use cpuidle 2. find the exact place in cpuidle mechanism where we enter idle loop, and where we exit idle loop. 3. on entering idle loop: turn off various devices on board, and devices power domain 4. on exit idle loop: power again the devices. I think that working such way on low machine registers will be easiest and best instead of trying to do it using PM mechanism, which is quite difficult to understand and do and also, I'm not sure even possible using the existing mechanism. I would appreciate your feedback. Regards, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ideas about idle loop and power management
On Tue, Sep 23, 2014 at 11:37 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [140923 12:24]: Hello, I have a system which is required to have 2 modes operation: 1. idle - in which devices in Soc and on board should be off. 2. active mode Hmm we do this already with the mainline kernel since v3.16-rc6 for device tree based systems too. Some devices will still block deeper idle states idle like EHCI. I suggest you give v3.17-rc6 a try on a beagleboard xm (rev c preferrably)using omap2plus_defconfig. Or omap 37xx evm. Or on n900. Or overo, but that's still pending a .dts fix. Moving from idle to active on interrupt, and moving from active to idle when there is inactivity. After reading and re-reading about PM various mechanism, I got to conculsion that the best and easiest way to achive this on omap (omap3530) will be as following: 1. use cpuidle 2. find the exact place in cpuidle mechanism where we enter idle loop, and where we exit idle loop. 3. on entering idle loop: turn off various devices on board, and devices power domain The devices are autoidle where possible with runtime PM. And then the hardware enters deeper idle states when drivers are not blocking. Sounds like you just need to give it a try. I'm using the following test script. You may need to also blank the LCD. Hi Tony, I actually want something different than runtime PM. I want that the whenever system enters idle loop it will force suspend of the devices, and not that each device will decide on its own. Aside from that, from delving into code it seems that tailoring new device runtime suspend/resume by building registration of runtime_pm callbacks is much more complex than simply disabling power domain of all relevant devices whenever entering idle mode. Thanks, Ran -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
