Re: Internet Tablet Power Management presentation from linux-pm summit 2007
Igor Stoppa wrote: Hi, this is the presentation we gave last week in Ottawa at the pm summit. It is the first step in improving our communication process with the community and give a preview of what we are working on. http://maemo.org/midcom-permalink-0c828d202f2011dc9945e502835830f130f1 It contains a brief overview of what is already shipping in the 770 and the n800, but the main focus is about our work in progress. Comments and questions are welcomed. Thanks Igor, it is quite interesting. Maybe there is a bug on page 15 with DSP frequency for OP 0, shouldn't the 133 be 233 or 333 (unless you need to slow it down because of speeding up the arm core to meet some power requirement)? Does it mean the arm core in current N800 can run at 400Mhz? As for dynamic voltage and frequency scaling did I understood it correctly that even if lower voltage means considerable saving (even if task runs longer) it is almost not worth the hassle due to other issues (latency of voltage/frequency change, static power consumption of other parts, hard prediction of future)? Or how big savings do you expect overall from voltage/frequency scaling when the device is mostly idle (i.e being mostly waken up by inefficient system or apps waiting for something and not hogging the CPU). Or maybe the question is how efficient is the system currently, is there something like http://www.linuxpowertop.org/ for omap to see what can be improved or what cannot and could benefit from lower frequency/voltage? Do you plan to have user selectable power/speed profiles to let people choose whether they want slower system or shorter battery life? Or do you suppose there will be good enough cpufreq governor so it is not needed. Or do you consider some API so apps can suggest how fast system they want (i.e. media players, games, emulators vs book readers)? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
top_application?
Some applications seem to handle the top_application D-Bus method. I guess that this is maybe sent to the application when it's launched from the menu. And I guess that this maybe allows applications to be activated by D-Bus without showing their UI, so there UI can then be shown later when it's launched from the menu. But I can't find any real documentation for this D-Bus method. I'd rather not guess. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 10:08 +0200, ext Frantisek Dufka wrote: Thanks Igor, it is quite interesting. Maybe there is a bug on page 15 with DSP frequency for OP 0, shouldn't the 133 be 233 or 333 (unless you need to slow it down because of speeding up the arm core to meet some power requirement)? No, no bug unfortunately, simply TI doesn't support the combination with DSP @ 266 MHz (that would be the proper value). Of course ymmw and some chips probably can cope with it (actually there are also thermal issues so i bet that most OMAPs can do it at room temperature) but in order to provide a certain yield value, the constraints on the operating range are stricter. I certainly will run my tablet at higher speed and/or lower voltage; finland makes it unlikely to incur in heating problems ;-) Does it mean the arm core in current N800 can run at 400Mhz? Yes, the data is for stock N800 (we have this SpeedSorted OMAP2 that can run with ARM @ 400MHz). As for dynamic voltage and frequency scaling did I understood it correctly that even if lower voltage means considerable saving (even if task runs longer) it is almost not worth the hassle due to other issues (latency of voltage/frequency change, static power consumption of other parts, hard prediction of future)? It just means that the whole system must be considered, not only the processor. But we do have significant benefits at using the lower OP in many cases. It could be that there are benefits at using OP3 simply because of problems in the current implementation of the sw stack, so fixing them would make DVFS less attractive. But while we get all the issues fixed, DVFS seems to help, for example in reducing boot time and applications load time. Or how big savings do you expect overall from voltage/frequency scaling when the device is mostly idle (i.e being mostly waken up by inefficient system or apps waiting for something and not hogging the CPU). Or maybe the question is how efficient is the system currently, is there something like http://www.linuxpowertop.org/ for omap to see what can be improved or what cannot and could benefit from lower frequency/voltage? Yes, eventually our goal would also be to provide users with means to evaluate themselves 3rd party applications. I remember several times somebody complaining about battery life after installing some 3rd party application that had not gone through our validation process. Not that I'm really blaming the developers: one can do code review up to a certain point, but without proper tools it's hard to evaluate how pm friendly a caertain application is. Do you plan to have user selectable power/speed profiles to let people choose whether they want slower system or shorter battery life? My personal belief is that the user should not have to care about this: something is broken if the user has to be involved. The system should have all the info (and means) to run at good enough speed when needed. It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. Or do you suppose there will be good enough cpufreq governor so it is not needed. On demand should fit the bill, with some fixes. Conservative is useles sfor every practical application, in our case. Or do you consider some API so apps can suggest how fast system they want (i.e. media players, games, emulators vs book readers)? You mean QoS. Yes, that seems to be the general understanding. Intel too is going in that direction and they have very serious problems when comparing their hw against OMAP, which is designed from ground up to be pm friendly. OMAP2 has retention mode and the transition to/from retention is much faster than any OP change, so race-to-idle is more important on OMAP than on x86 devices. I would expect Intel to get QoS usable before us because of a more urgent need. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: top_application?
On 7/11/07, Murray Cumming [EMAIL PROTECTED] wrote: Some applications seem to handle the top_application D-Bus method. I guess that this is maybe sent to the application when it's launched from the menu. And I guess that this maybe allows applications to be activated by D-Bus without showing their UI, so there UI can then be shown later when it's launched from the menu. But I can't find any real documentation for this D-Bus method. I'd rather not guess. Hi, the top_application support resides in libosso (to be more specific, see libosso API documentation or libosso.h and osso-application-top.[c|h] from the sources) . It's supposed to be there for the purposes of bringing the target application to foreground and to allow the apps to notice/do something useful when that happens with the corresponding callbacks, but as it's deprecated, I think using it in new applications might now not be worth it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: top_application?
On Wed, 2007-07-11 at 13:53 +0300, Mika Yrjölä wrote: On 7/11/07, Murray Cumming [EMAIL PROTECTED] wrote: Some applications seem to handle the top_application D-Bus method. I guess that this is maybe sent to the application when it's launched from the menu. And I guess that this maybe allows applications to be activated by D-Bus without showing their UI, so there UI can then be shown later when it's launched from the menu. But I can't find any real documentation for this D-Bus method. I'd rather not guess. Hi, the top_application support resides in libosso (to be more specific, see libosso API documentation or libosso.h and osso-application-top.[c|h] from the sources) . Sorry I can't find anything in the documentation. Do you have a URL? It's supposed to be there for the purposes of bringing the target application to foreground and to allow the apps to notice/do something useful when that happens with the corresponding callbacks, but as it's deprecated, I think using it in new applications might now not be worth it. Is this replaced by anything in particular? Is there some recommended way to get the behaviour that I described? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: top_application?
On 7/11/07, Murray Cumming [EMAIL PROTECTED] wrote: On Wed, 2007-07-11 at 13:53 +0300, Mika Yrjölä wrote: On 7/11/07, Murray Cumming [EMAIL PROTECTED] wrote: Some applications seem to handle the top_application D-Bus method. I guess that this is maybe sent to the application when it's launched from the menu. And I guess that this maybe allows applications to be activated by D-Bus without showing their UI, so there UI can then be shown later when it's launched from the menu. But I can't find any real documentation for this D-Bus method. I'd rather not guess. Hi, the top_application support resides in libosso (to be more specific, see libosso API documentation or libosso.h and osso-application-top.[c|h] from the sources) . Sorry I can't find anything in the documentation. Do you have a URL? Sure, here goes: http://maemo.org/api_refs/3.0/libosso/group__Apps.html documents the libosso features that use the top_application method (however, it's true that the documentation doesn't mention that, probably because it's just an internal implementation detail). I don't know if there would be additional information in the rest of the libosso docs (other than the source :), as most of the other libosso doc links seem to be broken at the moment, though... Desktop appears indeed to currently send a top_application method call while it starts an application, at least according to a quick look to the source (osso_manager_launch function). It's supposed to be there for the purposes of bringing the target application to foreground and to allow the apps to notice/do something useful when that happens with the corresponding callbacks, but as it's deprecated, I think using it in new applications might now not be worth it. Is this replaced by anything in particular? Is there some recommended way to get the behaviour that I described? AFAIK the mechanism is in use for now, even though the deprecation notice implies that this might not be the case forever (the osso_rpc_* functions are suggested as an alternative). I don't have any immediate idea about how to do what you originally wished for, though (as the top_application would cause the application to become the active one). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: [snip lots of interesting stuff] It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
Igor Stoppa wrote: I certainly will run my tablet at higher speed and/or lower voltage; finland makes it unlikely to incur in heating problems ;-) CPU temperature sensor might be useful to guess the limit and cut the speed down in case one is not in Finland :-) Is there one? Does it mean the arm core in current N800 can run at 400Mhz? Yes, the data is for stock N800 (we have this SpeedSorted OMAP2 that can run with ARM @ 400MHz). Cool :-) Well, maybe 'Hot' actually :-) Do you plan to have user selectable power/speed profiles to let people choose whether they want slower system or shorter battery life? My personal belief is that the user should not have to care about this: something is broken if the user has to be involved. The system should have all the info (and means) to run at good enough speed when needed. Well, I'm not sure but maybe when being conservative with power saving and when some hints are applied (i.e some API) it could work. I'm mainly thinking about CPU spikes when applications are starting. I fear the system will not react quickly enough with 'overclocking' when application starts since otherwise the device does nothing before and after. But this specific problem could be solved with some hints done from application launcher or maybe kernel or libc (exec/fork call) itself. I'm not sure how linux currently does it on x86 (shame on me, using XP on laptop and linux only in vmware) but my experience with RMClock on XP (http://cpu.rightmark.org/products/rmclock.shtml) is that it is hard/impossible to tune it in such way that application startup is not slower and you still save some power. It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. Yes, this is old discussion. I still think proper suspend is useful. While current implementation is great and is mostly what users expect or can tolerate, sometimes you simply want to 'pause' or 'hibernate' the device no matter what, throw it in the bag and 8 hours (or 10 days) later resume exactly where you left off with minimum energy lost. Without stopping applications or thinking about anything. This is what proper suspend can give you. This is how notebooks and PDAs work. This is what would be sometimes useful even on internet tablets (no matter how 'always connected' they are supposed to be). But I agree current power management on Nokia tablets is great so this is not critical. Still I can't resist when this is brought up :-) I'm not saying this needs to be definitely implemented by freezing everything in user and/or kernel space. I'm saying that apart from current power saving when idle there should be easy way of telling the device to go to sleep completely (pausing audio, disconecting from network,...) Or do you consider some API so apps can suggest how fast system they want (i.e. media players, games, emulators vs book readers)? You mean QoS. Yes, that seems to be the general understanding. Yes that's it. Didn't know this term is used also in power management, though. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
Apart from shutting off the sound thing thsi looks like a N770 cover on mode. Is that about right? Even if it's not, it's one I would like to have as well - as a put away for a while mode, Andy On Wednesday, July 11, 2007, at 01:29PM, Andrew Flegg [EMAIL PROTECTED] wrote: On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: [snip lots of interesting stuff] It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: [snip lots of interesting stuff] It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. Why not just put it in offline mode and lock the screen and keys? That's what i do and it simply works. The only drawback is that with sane applications you would get only 12 days with a full battery. I do admit that in some extreme case it might not be enough, but on OMAP2 it doesn't justify the hassle. I'd rather spend time and resources in fixing kernel and applications to make sleep while idle as close as possible to suspend to ram. Plain suspend to ram (or disk), imho, sucks, because it produces a useless brick till it is forcibly resumed. I think it would be much better to simply let wakeup events happen, but make sure that only the _useful_ ones happen. The user should be able to configure wakeup sources, certainly, even up to the point of saying: wake up only for power button, but the system should manage itself automatically. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N800 - tell it not to reboot
Hi, I flashed a modified rootfs to my N800, but whatever changes I do to my rootfs, the N800 simply reboots 1-2 seconds after the UI showed up. I get as far as opening the app menu, but before I can hit xterm, it reboots :/ I enabled the RD mode and did the usual ./flasher-3.0 --set-rd-flags=no-omap-wd,no-retu-wd,no-lifeguard-reset as suggested on the forums. Still, it reboots, and I don't even have a chance to log in and see why. Did I forget something? Is there a way to tell the N800 to never reboot no matter what? Any other watchdogs/processes/whatever that I have to nuke? Thanks, Harald ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: On Wed, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. Why not just put it in offline mode and lock the screen and keys? That's what i do and it simply works. Well, that doesn't block sound so if the battery starts going down in the night, or similar, I could be awoken by a noise. It's also clumsy as the sequence is: 1) Press power button 2) Select offline mode 3) Press OK 4) Press power button 5) Press OK Unlocking is a simlar number. That's not exactly a simple sequence, as say the 770's cover was (as Andy Mulhearn points out). Now, if it was possible to hook into the power menu to define my own sequence of actions I could set up a turn off volume, go offline, lock screen keys function and map that to the top-most item. Is that possible? I've not seen any documentation on /etc/systemui/systemui.xml except for hacking it to re-enable soft-poweroff and reboot. The only drawback is that with sane applications you would get only 12 days with a full battery. As you point out elsewhere though, the only sane applications we can be sure of are the IT OS built-in ones, at the moment :-( I do admit that in some extreme case it might not be enough, but on OMAP2 it doesn't justify the hassle. As I said, when users say suspend they mean the kind of thing I describe above, what that maps to under the covers is not important. I'd rather spend time and resources in fixing kernel and applications to make sleep while idle as close as possible to suspend to ram. Agreed. But hopefully the system is open enough to allow third parties to hook into the infrastructure (e.g. power menu). Plain suspend to ram (or disk), imho, sucks, because it produces a useless brick till it is forcibly resumed. I think it would be much better to simply let wakeup events happen, but make sure that only the _useful_ ones happen. Absolutely. FSVO useful. The user should be able to configure wakeup sources, certainly, even up to the point of saying: wake up only for power button, but the system should manage itself automatically. Agreed, remember I'm talking about use-case for users, not if it's an *actual* system suspend under the covers. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On ons, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: [snip lots of interesting stuff] It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. So what you want is basically the Soft Poweroff option that's available to you with a simple: vim /etc/systemui/systemui.conf but with some minor tweaks? I guess that can be arranged =) Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, Jul 11, 2007 at 01:44:58PM +0100, Andrew Flegg wrote: On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: On Wed, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. Why not just put it in offline mode and lock the screen and keys? That's what i do and it simply works. Well, that doesn't block sound so if the battery starts going down in the night, or similar, I could be awoken by a noise. It's also clumsy as the sequence is: 1) Press power button 2) Select offline mode 3) Press OK 4) Press power button 5) Press OK Unlocking is a simlar number. That's not exactly a simple sequence, as say the 770's cover was (as Andy Mulhearn points out). Right. Palm had a simple sequence: 1) Press power button There's also the popular story about a guy at Palm whose job was to count the taps needed to do something. (If it takes more than three taps, the user interface needs to be fixed, or something like that.) As a user, I noticed that immediately when I exchanged my old Palm to a 770. (It's getting better in newer software versions: copy paste moved one level up in the virtual keyboard menu.) Marius Gedminas -- If con is the opposite of pro, then what is the opposite of progress? signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On 7/11/07, David Weinehall [EMAIL PROTECTED] wrote: On ons, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. So what you want is basically the Soft Poweroff option that's available [...] but with some minor tweaks? Yes, exactly :-) I guess that can be arranged =) Cool. Is it anything I could do straight off (I can also imagine a control panel applet to allow users to customise[1] this suspended state as Igor describes), or does it still dependent on some relatively closed/unhookable infrastructure? Cheers, Andrew [1] Sound on/off, network on/off being the obvious ones -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On ons, 2007-07-11 at 13:53 +0100, ext Andrew Flegg wrote: On 7/11/07, David Weinehall [EMAIL PROTECTED] wrote: On ons, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. So what you want is basically the Soft Poweroff option that's available [...] but with some minor tweaks? Yes, exactly :-) I guess that can be arranged =) Cool. Is it anything I could do straight off (I can also imagine a control panel applet to allow users to customise[1] this suspended state as Igor describes), or does it still dependent on some relatively closed/unhookable infrastructure? systemui.xml (sorry, not conf as I wrote in my previous e-mail) file supports callbacks, to get customised behaviour. [1] Sound on/off, network on/off being the obvious ones I can make that configurable through /etc/mce/mce.ini Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 16:01 +0300, David Weinehall wrote: On ons, 2007-07-11 at 13:53 +0100, ext Andrew Flegg wrote: On 7/11/07, David Weinehall [EMAIL PROTECTED] wrote: On ons, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. So what you want is basically the Soft Poweroff option that's available [...] but with some minor tweaks? Yes, exactly :-) I guess that can be arranged =) Cool. Is it anything I could do straight off (I can also imagine a control panel applet to allow users to customise[1] this suspended state as Igor describes), or does it still dependent on some relatively closed/unhookable infrastructure? systemui.xml (sorry, not conf as I wrote in my previous e-mail) file supports callbacks, to get customised behaviour. [1] Sound on/off, network on/off being the obvious ones I can make that configurable through /etc/mce/mce.ini Sorry to ruin the party, but as Mike Baker wrote some time ago (RFC: n800 suspend to ram) the suspend wouldn't be forever anyway: Mike's script or something similar should be used. So there _would_ be anyway some activity. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 11 Jul 2007 15:52:10 +0300 Marius Gedminas [EMAIL PROTECTED] wrote: On Wed, Jul 11, 2007 at 01:44:58PM +0100, Andrew Flegg wrote: On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: On Wed, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. Why not just put it in offline mode and lock the screen and keys? That's what i do and it simply works. Well, that doesn't block sound so if the battery starts going down in the night, or similar, I could be awoken by a noise. It's also clumsy as the sequence is: 1) Press power button 2) Select offline mode 3) Press OK 4) Press power button 5) Press OK Unlocking is a simlar number. That's not exactly a simple sequence, as say the 770's cover was (as Andy Mulhearn points out). Right. Palm had a simple sequence: 1) Press power button I could suggest using a double click on the power button First click opens the Device mode dialogue. Second click suspends the device. Apply a timeout after the dialogue appears, if the power button click happens after this, the dialogue just closes (to prevent accidental suspends) There's also the popular story about a guy at Palm whose job was to count the taps needed to do something. (If it takes more than three taps, the user interface needs to be fixed, or something like that.) As a user, I noticed that immediately when I exchanged my old Palm to a 770. (It's getting better in newer software versions: copy paste moved one level up in the virtual keyboard menu.) Marius Gedminas -- If con is the opposite of pro, then what is the opposite of progress? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On ons, 2007-07-11 at 16:14 +0300, Igor Stoppa wrote: On Wed, 2007-07-11 at 16:01 +0300, David Weinehall wrote: On ons, 2007-07-11 at 13:53 +0100, ext Andrew Flegg wrote: systemui.xml (sorry, not conf as I wrote in my previous e-mail) file supports callbacks, to get customised behaviour. [1] Sound on/off, network on/off being the obvious ones I can make that configurable through /etc/mce/mce.ini Sorry to ruin the party, but as Mike Baker wrote some time ago (RFC: n800 suspend to ram) the suspend wouldn't be forever anyway: Mike's script or something similar should be used. So there _would_ be anyway some activity. Uhm? What's that got to do with anything? The standard soft-off in mce only relies on the excellent dynamic sleep of the device (but with display turned off, power off behaviour of the power button, touchscreen/keypad lock enabled, etc). Of course, if anyone wants to use suspend too, that's their choice, but really, Soft Poweroff doesn't rely on it. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
* Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly a special softpoweroff mode combined with muted sound and offline mode sounds really useful to me. I could suggest using a double click on the power button First click opens the Device mode dialogue. Second click suspends the device. Apply a timeout after the dialogue appears, if the power button click happens after this, the dialogue just closes (to prevent accidental suspends) I think adding a PowerKeyDoubleAction and PowerKeyDoubleTimeout (or PowerKeyDoubleDelay) to mce.ini and making this all configurable would be the best approach. -- Kemal ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 14:29 +0200, ext Frantisek Dufka wrote: Igor Stoppa wrote: I certainly will run my tablet at higher speed and/or lower voltage; finland makes it unlikely to incur in heating problems ;-) CPU temperature sensor might be useful to guess the limit and cut the speed down in case one is not in Finland :-) Is there one? There is one between omap and the combo chip memory, but it is quite sucky. Not that we haven't thought about it. If there is some spare time (yeah, right) we could try to use it, but TI is unlikely to support it and therefore i'm quite confident it will ever ship (albeit it would be quite interesting since it would allow much more aggressive trimming down of the voltage). Well, I'm not sure but maybe when being conservative with power saving and when some hints are applied (i.e some API) it could work. I'm mainly thinking about CPU spikes when applications are starting. I fear the system will not react quickly enough with 'overclocking' when application starts since otherwise the device does nothing before and after. But this specific problem could be solved with some hints done from application launcher or maybe kernel or libc (exec/fork call) itself. Ondemand starts by cranking up to the max the frequency. It cannot be beaten. I'm not sure how linux currently does it on x86 (shame on me, using XP on laptop and linux only in vmware) but my experience with RMClock on XP (http://cpu.rightmark.org/products/rmclock.shtml) is that it is hard/impossible to tune it in such way that application startup is not slower and you still save some power. OMAP has retention so it's not that critical to fine tune. x86 otoh doesn't, afaik, so it would require more aggressive tuning [snip] You mean QoS. Yes, that seems to be the general understanding. Yes that's it. Didn't know this term is used also in power management, though. I use it :-P others are more shy about it, but when asked they admit that it is what they have on their mind. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On ons, 2007-07-11 at 15:16 +0200, ext Visti Andresen wrote: [snip] I could suggest using a double click on the power button First click opens the Device mode dialogue. Second click suspends the device. The idea is great, IMHO, but I doubt that Nokia's UI-team would agree; on a Nokia phone, pressing the power button when the device menu is open acts as cursor down. On our device it just ignores the press completely, which was an acceptable behaviour too. Adding a totally different behaviour would probably be regarded as too complicated for the user, or something =) [snip] Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On 7/11/07, Frantisek Dufka [EMAIL PROTECTED] wrote: Igor Stoppa wrote: I certainly will run my tablet at higher speed and/or lower voltage; finland makes it unlikely to incur in heating problems ;-) CPU temperature sensor might be useful to guess the limit and cut the speed down in case one is not in Finland :-) Is there one? I noticed something that looked like a pseudofile for a temperature sensor somewhere under the /sys awhile back, can't remember the exact path right now, though. Neither do I have any idea whether the values there are useful; they looked a bit like temperature in Centigrades * 1000 or something and did change, but that doesn't mean that they're accurate, change in linear fashion etc. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
Marius Gedminas schrieb: Palm had a simple sequence: 1) Press power button Something like that had been suggested through https://bugs.maemo.org/show_bug.cgi?id=1246 and was rejected as WONTFIX by the Nokia team. Regards, Hanno ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
ola https://bugs.maemo.org/show_bug.cgi?id=1246 for me this gives There is a problem with this website's security certificate. on windows vista []'s ian -- http://ianlawrence.info ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
David Weinehall wrote: On ons, 2007-07-11 at 15:16 +0200, ext Visti Andresen wrote: [snip] I could suggest using a double click on the power button First click opens the Device mode dialogue. Second click suspends the device. The idea is great, IMHO, but I doubt that Nokia's UI-team would agree; on a Nokia phone, pressing the power button when the device menu is open acts as cursor down. On our device it just ignores the press completely, which was an acceptable behaviour too. Adding a totally different behaviour would probably be regarded as too complicated for the user, or something =) [snip] Regards: David Sounds similar to RFE https://bugs.maemo.org/show_bug.cgi?id=943 Vote it up if there's to be any hope of a change of heart on Nokia's part! :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 16:26 +0300, ext David Weinehall wrote: On ons, 2007-07-11 at 15:16 +0200, ext Visti Andresen wrote: [snip] I could suggest using a double click on the power button First click opens the Device mode dialogue. Second click suspends the device. The idea is great, IMHO, but I doubt that Nokia's UI-team would agree; on a Nokia phone, pressing the power button when the device menu is open acts as cursor down. On our device it just ignores the press completely, which was an acceptable behaviour too. Adding a totally different behaviour would probably be regarded as too complicated for the user, or something =) We are doing open software, right? So let's provide a good mechanism that supports more advanced interactions and even if we have to officially ship with a lame set of choices for the average user, others can implement more advanced features. From the discussion so far, I'm getting the impression that what people are actually asking for is a way to create very customised extra profiles. Example: Create Night mode and associate it with the shortcut (double press on the power button): -disable chat/presence -leave only VOIP with a subset of users actually able to generate rings -kill all the led signalling - All these actions should be (are they already?) commands to be sent to the interested application/daemon through DBUS, so a simple script, paired with a command line dbus interface would be sufficient. It's just a matter of having available the list of commands/requests supported by every application over DBUS. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Java acceleration/Jazelle
Hi all, If this is all already known please let me know and I'll stop waffling, but some Googling couldn't find anything, so I'll present what I've found thus far. I had a look around for some more information and found the patent for Jazelle: US patent number 7089539. Google link here (with figures, which makes understanding it far easier): http://www.google.com/patents?id=iMt6EBAJdq=7089539 I've finally got round to reading all of the patent in question. I've changed my mind about exception handlers (see my previous posts with the same subject line). I believe that the processor internally handles any exception caused by an unrecognised Java bytecode, and (and this is where a bit of interpretation/reading between the lines comes in) automatically switches to ARM mode and jumps to an address specified in a pointer table provided by the application running the JVM (i.e. us). If you look at Fig.4 in the patent, for example, you can see a snippet of code. This is one of the chunks of code that would be jumped to (pointed to by the pointer table, which will be 256 pointers long, one for each bytecode) and implements the iadd bytecode. I've repeated the code fragment below with comments above each line: /* increment bytecode pointer (R14) and load value pointed to by R14 into R4. This is performed so that we have the bytecode value of the *next* bytecode (i.e. not the one that couldn't be handled) in R4. We move the Java 'program counter' register, R14, along by one before we do this (in fact it does R4=*(R14+1) then R14=R14+1, but same in the end). */ LDRB R4, [R14, #1]! /* decrement Rstack by 4, then pop first operand from stack into R1 This is part of handling the actual instruction, in this case an iadd, so we need to pop the values from the stack */ LDR R1,[Rstack, #-4]! /* decrement Rstack by 4, then pop first operand from stack into R0 As above */ LDR R0,[Rstack, #-4]! /* Get address of next code fragment for next bytecode load into R12 the value from Rexc + (R4 x 2^2). In this step we look into the pointer table (which contains pointers to ARM code fragments that handle each Java bytecode) and we load the address of the code fragment for the next Java instruction (not the one we're currently handling) which we loaded into R4 on the first line */ LDR R12,[Rexc, R4, LSL #2] /* R0 = R0 + R1 Here we simply perform the add operation that this code fragment is handling*/ ADD R0,R0,R1 /* Store R0 in Rstack and increment Rstack by 4 (pre or post? post probably) Here we save the results of the add operation that we're handling in this code snippet*/ STR R0,[Rstack],#4 /* Branch to Java This command takes as its operand the address of the ARM software snippet used to handled the bytecode. Not (it would appear) the address of the Java bytecode to execute. The address of the bytecode should be in R14. The Jazelle hardware decides whether Jazelle is present and enabled and chooses whether to jump to the bytecode and enter Java mode, or to stay in ARM mode and 'emulate' the instruction */ BXJ R12 Note that the actual implementation of the iadd instruction (popping twice, adding then pushing) is mixed in with the preparations to handle the next bytecode/re-enter Java mode. Afaiu, this is done to make the code more efficient and avoid stalls. So you can see that the code has already worked out where it needs to jump to in either Java or ARM 'emulation' mode (the latter is done to speed up processing should Jazelle be disabled or the bytecode be another one that's not handled by the hardware). One curious point about this code is that I was under the impression that the stack was held in registers [1], rather than at some address as is indicated by the pop instructions. It may be that the Jazelle hardware does in fact hold the top stack elements in registers and flushes them to memory when the unrecognised Java bytecode exception is caused. The question then is which register actually holds this memory address (ie. Rstack in the code above)? The same article says that R6 holds the stack pointer, so perhaps this is used...? The other register that needs to be determined is Rexc, which is the one that points to the base of the pointer table which contains the pointers to the ARM code snippets. But it looks like accesses to this table are only handled in the ARM snippets (which 'we' would provide), so it then becomes a question of which spare register can be used to store this address and won't be overwritten. There are of course a number of other patents that were from around the same time. Not sure whether any of the others will have any useful info in them. For that matter I wonder why ARM provided some of the register names/numbers, but not others? Time to brush up on my inline asm, and to dig out my Java 2 Virtual Machine book and make up some test (byte)codes... Simon
Re: Java acceleration/Jazelle
Hi Simon, nice research !!! This seams easier (and more os independent) than my thoughts with an interrupt in kernel mode. Although we can not say for sure, that Jazelle is implemented the way, the patent describes, this is a very good point to get a forthcome. Regards, Sebastian Simon Pickering schrieb: Hi all, If this is all already known please let me know and I'll stop waffling, but some Googling couldn't find anything, so I'll present what I've found thus far. I had a look around for some more information and found the patent for Jazelle: US patent number 7089539. Google link here (with figures, which makes understanding it far easier): http://www.google.com/patents?id=iMt6EBAJdq=7089539 I've finally got round to reading all of the patent in question. I've changed my mind about exception handlers (see my previous posts with the same subject line). I believe that the processor internally handles any exception caused by an unrecognised Java bytecode, and (and this is where a bit of interpretation/reading between the lines comes in) automatically switches to ARM mode and jumps to an address specified in a pointer table provided by the application running the JVM (i.e. us). If you look at Fig.4 in the patent, for example, you can see a snippet of code. This is one of the chunks of code that would be jumped to (pointed to by the pointer table, which will be 256 pointers long, one for each bytecode) and implements the iadd bytecode. I've repeated the code fragment below with comments above each line: /* increment bytecode pointer (R14) and load value pointed to by R14 into R4. This is performed so that we have the bytecode value of the *next* bytecode (i.e. not the one that couldn't be handled) in R4. We move the Java 'program counter' register, R14, along by one before we do this (in fact it does R4=*(R14+1) then R14=R14+1, but same in the end). */ LDRB R4, [R14, #1]! /* decrement Rstack by 4, then pop first operand from stack into R1 This is part of handling the actual instruction, in this case an iadd, so we need to pop the values from the stack */ LDR R1,[Rstack, #-4]! /* decrement Rstack by 4, then pop first operand from stack into R0 As above */ LDR R0,[Rstack, #-4]! /* Get address of next code fragment for next bytecode load into R12 the value from Rexc + (R4 x 2^2). In this step we look into the pointer table (which contains pointers to ARM code fragments that handle each Java bytecode) and we load the address of the code fragment for the next Java instruction (not the one we're currently handling) which we loaded into R4 on the first line */ LDR R12,[Rexc, R4, LSL #2] /* R0 = R0 + R1 Here we simply perform the add operation that this code fragment is handling*/ ADD R0,R0,R1 /* Store R0 in Rstack and increment Rstack by 4 (pre or post? post probably) Here we save the results of the add operation that we're handling in this code snippet*/ STR R0,[Rstack],#4 /* Branch to Java This command takes as its operand the address of the ARM software snippet used to handled the bytecode. Not (it would appear) the address of the Java bytecode to execute. The address of the bytecode should be in R14. The Jazelle hardware decides whether Jazelle is present and enabled and chooses whether to jump to the bytecode and enter Java mode, or to stay in ARM mode and 'emulate' the instruction */ BXJ R12 Note that the actual implementation of the iadd instruction (popping twice, adding then pushing) is mixed in with the preparations to handle the next bytecode/re-enter Java mode. Afaiu, this is done to make the code more efficient and avoid stalls. So you can see that the code has already worked out where it needs to jump to in either Java or ARM 'emulation' mode (the latter is done to speed up processing should Jazelle be disabled or the bytecode be another one that's not handled by the hardware). One curious point about this code is that I was under the impression that the stack was held in registers [1], rather than at some address as is indicated by the pop instructions. It may be that the Jazelle hardware does in fact hold the top stack elements in registers and flushes them to memory when the unrecognised Java bytecode exception is caused. The question then is which register actually holds this memory address (ie. Rstack in the code above)? The same article says that R6 holds the stack pointer, so perhaps this is used...? The other register that needs to be determined is Rexc, which is the one that points to the base of the pointer table which contains the pointers to the ARM code snippets. But it looks like accesses to this table are only handled in the ARM snippets (which 'we' would provide), so it then becomes a question of which spare register can be used to store this
