Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Hi, ext Arve Hjønnevåg wrote: It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle. Sorry if i'm asking something that was already said, but the thread is quite complex and i am not sure i have been able to grasp all of it. So, regardless of the SW implementation: -1) are you focusing on "good" HW or do you want to address all at the same time? -2) would you be ok with addressing "bad" HW as a special case, which requires workarounds and shouldn't dictate the overall design? -3) do you agree with the assumption that new HW is expected to get reasonably better and therefore workarounds at point 2) will progressively be confined to devices less and less common? -4) going to the definition of "good" and "bad" (maybe this should have come earlier in the list), can we define "good" HW as HW where: * suspend state and lowest achievable runtime idle state are basically equivalent from both power consumption and latency pov * the HW itself is properly able to track wakeup sources while it is in its deepest power state (as example OMAP3 has few independent wake-capable pads and a "wake ring" where one only gets the information that at least one of the pads belonging to such ring has received a wakeup) * wakeup sources can be dynamically masked at HW level, so that if a peripheral is not interesting, it doesn't wakeup the system (for example the camera button when the camera cover is closed) -5) HW that is not capable of properly generating asynchronous signal is most likely the cause for extra timers in kernel and it should be considered "bad" - in any other case having recurring in-kernel timers should be treated as bugs, if their existence is not tied to some meaningful work thanks, igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Felipe Contreras wrote: I think this information can be obtained dynamically while the application is running, yes, that was the idea and perhaps the limits can be stored. It would be pretty difficult for the applications to give this kind of information because there are so many variables. For example, an media player can tell you: this clip has 24 fps, but if the user is moving the time slider, the fps would increase and drop very rapidly, and how much depends at least on the container format and type of seek. I doubt that belongs to typical QoS. Maybe the target could be to be able to decode a sequence of i-frames? A game or a telephony app could tell you "I need real-time priority" but so much as giving the details of latency and bandwidth? I find that very unlikely. from my gaming days the games were still evaluated in fps ... maybe i made the wrong assumption? A telephony app should still be able to tell if it's dropping audio frames. In all cases there should be some device independent limit - like: what is the sort of degradation that is considered acceptable by the typical user? Tuning might be offered, but at least this should set some sane set of defaults. igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Alan Cox wrote: Be that as it may the question of how you manage a naughty app is a good one. Historically we've managed them for network abuse, memory abuse, cpu use abuse, access rights, but not yet power. Whether that looks like setrlimit(pid, LIMIT_CHARGE, 150mWH); or setrlimit(pid, LIMIT_POWER, 150mW); or something else is the question. Either way, this will require a detailed model of the system in terms of latency, throughput, current consumption and heat generation. Which can be provided only by the HW manufacturer. But, should such model be available (and we have some form of it for the OMAP3 in N900), then it can be abstracted through generic interfaces, which accept constraints and produce the selected target state (typically a vector of states for each sub component). igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext ty...@mit.edu wrote: Linus will disagree with you there. Linus *has* merged code on the basis that it is shipping in distributions, regardless of the fact that some developers objected to it. Sometimes "perfect" should not be the enemy of "good enough" shipping code. "good enough" is very subjective, in this case If everyone agrees we're making progress, and we can let this 100+ mail thread keep going. I have seen very good proposals for saner solutions. Is that progress? igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Brian Swetland wrote: How is it flawed? Serious question. I would avoid repeating all the good arguments given so far, but to make it short: * I believe runtime PM is a much better starting point (at least for the type of HW targeted at mobile devices) because it mimics an always-on system toward userspace, which requires less disruption in the way apps are designed * QoS is closer to the apps pov: fps if it is a media player or a game, transfer speed if it is a file manager, bandwidth if it is a network app, etc The app is required to express its opinion by using a format that it understands better and is less system dependent. Actually the kernel should only be concerned with 2 parameters at most for any given operation: latency and bandwidth/throughput * Some form of resource management is needed as trust mechanism to discriminate "trusted" vs untrusted apps that can give reliable info (but in your case you should give trust to whom prevents the suspend) * Most of this could be done in userspace with the kernel merely providing the means to enforce the decisions taken by the userspace manager. * The kernel wouldn't even have to try to outsmart the "evil application writer" igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Brian Swetland wrote: At a certain point, if one side of the argument is using "N900 / OMAP3 works just fine as is" (which has certainly been the case stated by a number of folks throughout these discussions), I think it's a little unrealistic to express shock that somebody argues the opposing point. The problem lies in the definition of the goal and means to achieve it. We do rely on repositories to discriminate on the quality of applications. As I stated some are accessible and run by our community. So, in this scenario, it works well enough. I've personally avoided commenting on specific power management issues or properties of competitive platforms because it can easily be viewed as rather rude or unprofessional. (though in theory we all could benefit from any improvements to the kernel regarding power management, no?). What I consider plain wrong i to claim that since there are this many units out, some code should be merged. A company needs to cut corners sometimes when making a product but this should not affect upstream code. I am quite willing to state that on both MSM and OMAP based Android platforms, we've found that the suspend blocker model allows us to obtain a lower average power draw than if we don't use it -- Mike Chan provided some numbers earlier in another thread in the trivial device idle case, the win is of course much larger in the case of several poorly behaved apps being active. That's very good. But if it is done in a conceptually flawed way, some better solution should be considered for upstream merge. [snip] A reality of a mass market device with a completely open and unrestricted application development and distribution ecosystem is that there will be plenty of non-optimal apps available to users (Sturgeon's Law applies everywhere, after all). Worse yet, many of these non-optimal apps may be beloved by users for various reasons. I think there's value in trying to do the best you can power-wise even in the face of such horrible foes as the dreaded Bouncing Cows App that Matthew is fond of citing as an example. Sure. I simply disagree on the methods proposed (suspend_blockers) and some of the rationale used for promoting them (volume of otherwise unsupported units). igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Theodore Tso wrote: Well, yes, if the company strategy is to have a walled garden ala the Apple iPhone App store, life is much simpler. No, the strategy is to try to merge commercial and community needs. We do support signed repositories. The community has control on the public one. Members are encouraged to help by alpha/beta testing apps that are under development. They even organize testing marathons. But if the requirements mean that apps don't need preapproval, the requirements on the platform get harder. That's a wrong way to put it. By installing something on your phone you _do_ approve it. I think the take-home here is we have a requirement that the platform behave well even without someone screening the applications for the "default SW repository". What it meant is totally different. Regardless how much effort you put into twisting it. It means that different repositories provide different level of trust. As Debian user, I don't blame anybody other than myself is something I've pulled from unstable or experimental breaks my system. Debian by default doesn't ship with either unstable or experimental enabled. And using suspend blockers doesn't really solve the problem of who to trust to take the block and who not. Or we'll have to have suspend-blockers-blockers and so on ... Like it or not, QoS and resource management - in some form - are needed to allow trusted application to provide valuable feedback, while filtering requests from untrusted applications. You might want to add dynamic profiling and try to use some heuristic to have the system doing runtime evaluation of good vs bad applications, but still some discrimination mechanism will be required. igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Theodore Tso wrote: I've seen very hard to debug situations with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !...@#@! much while the screen was turned off. And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication. If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier. Those apps were from an experimental repository, which is not enabled by default in stock SW. Of course tools can be improved, but if someone decides to run sw which is clearly under heavy development, i see little point in complaining that it might not work as expected. igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Matthew Garrett wrote: On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote: The other vendors appear to be managing nicely without magic blockers. I conjecture therefore there are other solutions. Actually, no. A badly behaved application will kill the N900's battery life. Nobody else has "managed nicely" - they've just made life harder for application developers and users, which may have something to do with the relative levels of market adoption of Maemo and Android. I'm not aware of any form of resource management framework in MeeGo either, so as far as I know it'll have exactly the same problem. It's true that a braindead app can kill the battery. However we provide a version of powertop that is tailored to the N900, there is a nokia energy profiler meant to give graphical representation of the battery current, there is htop available and you can even get the processor activity visualized on the leftmost and rightmost keyboard backlight LEDS, when in RD mode and with screen blanked. I would advice you to not start debating on company strategies, this is not the right place. Otherwise I'll have to ask what's the expected threshold of devices sold with broken sw design to get automatic admission into the mainline kernel source tree. But this is not the direction we want to take. Notice also that we _do_ have a store and official repository where apps are monitored for sanity, also with feedback from users and their help to promote new apps to trusted state. Former Maemo 6, now MeeGo do introduce resource management from security POV, but that will also have the side effect of discriminating between signers. igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Florian Mickler wrote: Converting a driver to using any constraint-API would require analysing what makes a driver refuse suspending in the old suspend handler and then specify any "no suspend" (or whatever) constraint before those conditions arise and clearing of the constraints when it is no longer critical. (Much work.) That's not really true. Nothing prevents using from the beginning a sane approach where drivers are required to specify constraints. The way it has been done for the N900 was to let driver developers specify _very_ conservative constraints, during the conversion phase. Then each driver has been optimized. If you have as requirement for driver developers that their driver must be working properly when compiled as module, it is possible to test the system with a minimalistic kernel which enters the lowest power state as soon as possible, plus only those modules that are being optimized. This allows also to identify parasitic drivers, which fail to apply the proper constraint and instead rely on some other driver to keep the system alive. igor -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Florian Mickler wrote: Converting a driver to using any constraint-API would require analysing what makes a driver refuse suspending in the old suspend handler and then specify any "no suspend" (or whatever) constraint before those conditions arise and clearing of the constraints when it is no longer critical. (Much work.) That's not really true. Nothing prevents using from the beginning a sane approach where drivers are required to specify constraints. The way it has been done for the N900 was to let driver developers specify _very_ conservative constraints, during the conversion phase. Then each driver has been optimized. If you have as requirement for driver developers that their driver must be working properly when compiled as module, it is possible to test the system with a minimalistic kernel which enters the lowest power state as soon as possible, plus only those modules that are being optimized. This allows also to identify parasitic drivers, which fail to apply the proper constraint and instead rely on some other driver to keep the system alive. igor -- 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: controlling CPU speed on N800/N810
Hi, On Sat, 2009-04-04 at 09:58 +0200, ext Kalle Valo wrote: > Is it possible to change CPU speed in latest linux-omap kernels? afaik, no, but that makes your job easier, the ARM clock should be 330MHz - at least that's what TI supports and recommends when also the DSP is in use -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- 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: Beagle PM hangs
On Sat, 2009-01-31 at 00:21 +0100, ext Kevin Hilman wrote: > CPUfreq policy is just as easily set in the kernel at init time. Then > the default would be set right, and the rootfs would be left to change > it if desired. But in general the situation is more complex and knowledge about the packaging and its thermal model is needed. Note that with packaging i refer to both the omap package (does it use stacked memory or not, is it a memory combo, etc) and the _device_ package. Not getting errors is not a good indication that the system is really operating in a safe mode; the device might be stable all the time but its life be more than halved. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- 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: Nokia Internet Tablets
On Mon, 2008-12-22 at 14:27 +0200, ext Felipe Balbi wrote: > On Mon, Dec 22, 2008 at 04:34:22AM -0600, ext Otto Solares wrote: > > -I don't plan to suspend but just sleep while idling, is this a good > > approach to power management (pm)? > > That's broken afaict. The feature might be broken, but the approach is correct. > > -I read about the pm branch, where can I pull it? > > from linux-omap git. > > git pull \ > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git pm > > should do it but afaik it still doesn't survive the wfi > > -Are the CONFIG_REGULATOR and CONFIG_POWER_SUPPLY APIs of any use for > > the Internet Tablets? > > hmm... it could be used for charging but it won't work unless you get > documentation of the charging chips used on n8x0. Also, you'd need to > change BME I suppose, which you can't :-s I think there was the intention to provide BME still i nbinary form but make it available to the community and have somebody from nokia to recompile it when needed. Far from optimal but at least something. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- 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: Bug in linux omap clock framework?
Hi Paul, On Tue, 2008-12-09 at 16:14 -0700, ext Paul Walmsley wrote: > Hi Tomi, > > On Tue, 9 Dec 2008, Tomi Valkeinen wrote: > > > I don't know much about power and clock domains, but I believe I found > > the reason and fix for this. At least this should point to the right > > direction. > > > > It looks to me that when I do clk_enable() to a clock which is inside a > > turned off powerdomain, clk_enable() function will return before the > > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the > > powerdomain is still in transition state. > > > > The following change waits until the powerdomain has finished the > > transition. At least it fixed the problem for me, and other things seem > > to be still working =). > > Nice work - this makes sense. Tested your patch here also. Just a thought: wouldn't this feature be required in basically every similar case? And if yes, wouldn't it be better to embed it into clk_enable() so that the driver code doesn't have to address it explicitly and can be more easily shared across different OMAP architectures? -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] OMAP: PM: enable UART clock disabling when idle
On Sat, 2008-11-29 at 21:35 -0600, ext Woodruff, Richard wrote: > > From: Igor Stoppa [mailto:[EMAIL PROTECTED] > > Sent: Saturday, November 29, 2008 10:07 AM > > > On Sat, 2008-11-29 at 07:55 -0600, ext Woodruff, Richard wrote: > > > > > Not unless you use some kind of flow control or protocol retransmits. > > > > What about bitbanging the entire first character? > > Huh? > > Typically for development you are just hooked to your PC. It doesn't do > anything special. but for some reason there seemed to be people who did now want to loose the first character, so i was wondering if the entire first character could be bitbanged in gpio mode and put into the sw buffer for the serial port, which would be reinserted into the foodchain after the completion of the first character. Of course in the case of human input it would probably mean that all the characters could be bitbanged, if the timeout for entering low power states is short enough, but wouldn't that be very close to reality where, like in the internet tablets, the serial port is disabled in production mode? What we usually see is that during development as soon as we enable production mode (iow no active serial port, not even with timeout) those drivers which were relying on it to provide some sort of wakeup, fail. Just a thought. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] OMAP: PM: enable UART clock disabling when idle
On Sat, 2008-11-29 at 07:55 -0600, ext Woodruff, Richard wrote: > Not unless you use some kind of flow control or protocol retransmits. What about bitbanging the entire first character? -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
On Tue, 2008-10-14 at 13:59 -0700, ext Tony Lindgren wrote: > And that we can use same naming in the driver no matter which omap :) Wasn't that one of the main features of the clock FW, when it was designed? -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP support in mainline?
On Thu, 2008-09-18 at 08:36 -0500, ext Woodruff, Richard wrote: > Where do you think the lineage of the hardware and software is? Do you > believe it just jumped into being in open source? All hardware and software > is full of deliberate design and hacks. Its true cooperate design constraints > are driven by the bottom line and for some in open source it is not. Getting the HW to work somewhere is not good enough. It must be supported in mainline, the more code you generate out of mainline, the less likely anybody can get it to work after a while and it slows down everybody. > It would be nice if whatever code was on the main branch was not so > frequently broken. That's why having more people working on the same code and doing review would help. > Maybe those who are interested in it should work on a branch in the tree and > periodically merge back at stable points. Maybe finally merged drivers at > kernel.org will server that purpose and the local tree's can be all > development. > > Where we need something working for a customer 'today' we export a tree to do > this. ...many strong statements in open source might be grouped as religious, > lobbyist, or novice. We all use some mix of these in work. What's your mix > on this issue? I'm no open source zealot, I'm being just very selfish and I think my life would be much simpler if there were less trees. Notice that Kevin Hilman has just created a pm branch from linux-omap, but that is named actually pm-0 and it means that it will be rebased and it is expected to disappear and dissolve into the main. That doesn't really apply to your omapzoom tree. Notice also that most of the patches not ready for being merged in pm-0, which justify its existence, are coming from omapzoom. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP support in mainline?
On Thu, 2008-09-18 at 17:21 +0530, ext Pandita, Vikram wrote: > > And, no, I'm not going to try omapzoom stuff, I want it working on the > > canonical linux-omap kernel, not some corporate version with god knows > > how many hacks. > > Your wish. > I thought debugging and fixing the issue was more important than the source > of the fix !!! YES! You have precisely exposed the problem with TI. It could not have been formulated in a better way. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pin mux utility?
Hi, On Fri, 2008-08-29 at 10:17 -0700, ext David Brownell wrote: > On Friday 29 August 2008, Steve Sakoman wrote: > > Is anyone aware of a utility to report the state of pin mux settings? > > > > I'd like to verify that u-boot is setting things up properly. > > CONFIG_OMAP_MUX_WARNINGS helps for some definitions of "properly": > when Linux needs one setting, but the boot loader leaves a different > one, you get a warning. That's usually interpreted as u-boot doing > it wrong, except on devboards where the boot loader can't actually > know about all external hardware that might be hooked up (and how) I'm probably a bit off topic, but since Tony started promoting the concept of multi-arch binary, well, i see it as a huge limitation the fact that the bootloader is expected to the right thing. When thinking about our Nokia HW vs the TI SDP, even the bootloader is different (yes, we should move to uboot and i couldn't be happier, but it's not gonna happen at the moment). In the multi arch case (but even single-arch, if we would like to support multiple boards with one single kernel binary) i see as a much more reasonable solution the case where the bootloader passes the board id to the kernel and the kernel loads the board-specific configuration in the form of a module. DVFS for example defeats the idea that the bootloader would be enough to setup properly the clock tree (of course it will do it, but only for 1 OP and the setting can get lost the first time another OP is selected). Imho the bootloader should just do what the name suggests: load the kernel and boot it. In as minimal configuration as possible. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux on OMAP 2420 in Nokia N95?
On Tue, 2008-08-26 at 12:42 +0300, ext Daniel Stone wrote: > The N95 will not run Linux: it runs Symbian, and flashing Linux on it > would be quite an impressive feat. That would probably capture, amongst others, the attention of the Nokia legal team, since the processor used is the High Security variant and succeding in flashing the image means that one has a valid signign key. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: cool gadget
On Sat, 2008-08-23 at 12:27 -0500, ext Woodruff, Richard wrote: > I did/do have http://www.datamath.org/Edu/Professor-76.htm however. Not as > neat but a keeper none the less. My latest TI-made "toy" has been this one: http://www.datamath.org/Graphing/TI-92-II.htm - actually i also grabbed the plus module - and the symbolic math was a real killer application the emulator runs a bit sluggishly on the n810, albeit the size is more compelling - i can only hope that on omap3 the speed will be comparable/faster than on the original. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cool gadget
On Fri, 2008-08-22 at 09:48 -0500, ext Woodruff, Richard wrote: > http://www.linuxdevices.com/news/NS8246055816.html Yes, cool, but this one http://www.speaknspell.co.uk/speaknspell.html wins hands down :-D -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getnstimeofday() and suspend
On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote: > Using them both would also generate more complexity. What would be the > benefit in using them both? The RTC should be used during suspend since it's supposed to keep track of time regardless of how long the duration of the suspension is. The 32kHz alone is not a good generic solution since it overflows after a couple of days. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: getnstimeofday() and suspend
On Fri, 2008-08-15 at 12:32 +0300, ext [EMAIL PROTECTED] wrote: > This behavior of the getnstimeofday() is breaking pm-debug and the > serial console wakeup hack if we use suspend. Enabling RTC module seems > to fix some of the issues in some cases, but we are going to lose timer > accuracy (RTC accuracy is only 1 second.) What about using the RTC for getting the base time and the 32kHz for the extended granularity? So one would use the RTC as ususal and then calculate the (less than 1s) offset. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap24xx is broken in current head
On Sun, 2008-08-10 at 14:37 +0200, ext Koen Kooi wrote: > "Broken as hell" if you want to do anything NEON related with it. yup Very unlucky but very true. > I > use 2007q3 with the -Os fix for compiling omap3 kernels Felipe: that's also what we should use internally, since it's the only one approved by our system performance team. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Implement powerdomain off on state counters
Hi Tony, On Tue, 2008-08-05 at 17:20 +0300, ext Tony Lindgren wrote: > * Peter 'p2' De Schrijver <[EMAIL PROTECTED]> [080724 16:00]: > > This patchset implement counters to count the number of off to on state > > transitions in a powerdomain. These counters will be made available to > > drivers in a later patchset to allow them to make a better informed > > decision wether to restore the hardware registers or not. > > > > Peter 'p2' De Schrijver (3): > > Power off on state counter debugging > > Power off on state counter infrastructure > > Add hooks for counting off on power transitions > > We should merge these into Paul's powerdomain patches against mainline > tree and post them again for more comments to LKML, linux-arm-kernel > and linux-pm. Dave Brownell commented already that this stuff, albeit apparently generic enough to be interesting to other archs, would probably be better off being merged in the omap tree, since in the end other SOCs tend to be far simpler than OMAP. Considering that we are not 100% sure about the usefulness of certain sw features - example: the granularity for the bandwidth requirements might be too fine - I'd rather avoid bringing in whishlists from other architectures, unless they are proven to be really needed. And AFAIK so far nobody has come forward with such claim. Can't we first get it working in a reliable way on OMAP? Whatever survives this process has probably better chances to result interesting to other people. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Added support for OMAP35x processor series
On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote: > This patch is needed to ensure that we can make decisions based on the > processor capabilities. > E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to disable/ > manage the clocks for > DSP on this processor. Same for SGX. Why can't the detection happen at runtime? > Enabling NEON is support iby default is just based on the number of requests > I have been getting > from various users. Huh? -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
On Sat, 2008-08-02 at 02:53 -0700, ext Emanoil Kotsev wrote: > I think I'll spend my time filing bugs instead of arguing with you, as it > leads to nothing obviously. > > Unfortunately I still don't have a solution - until bugs from 3rd party > vednors are solved you label the kernel as old ... but may be in future it > will change. If you want a viable solution that avoids you headaches with kernel version, put your efforts with your 3rd party vendor so that the driver gets properly integrated into mainline. Or just change the vendor if you can. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB driver issue
On Wed, 2008-07-30 at 21:56 +0530, ext Gadiyar, Anand wrote: > > Grr. Saying one needs to upgrade to the latest kernel before one can expect > > support is a bit like certain proprietary OS vendors - and even they do a > > better > > job than this. The difference is that an OS vendor usually sells also support. Even if it was confirmed that the bug exists in a "stable" version, the reporter would be asked anyway to verify that it is present in the latest code. Of course for TI the business is different, since TI does provide also support to customers, but that doesn't imply that others have to follow that model. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: FW: [PATCH 00/05] 34XX cpu idle patches - core off
Hi, On Mon, 2008-06-30 at 07:45 -0500, ext Woodruff, Richard wrote: > For things like bluetooth or other the protocol should re-transmit. That's avoided with an out of band irq. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/7] 34XX: PM: Workaround to build omap hsmmc as a module
Hi, On Wed, 2008-06-25 at 18:10 +0530, ext Gadiyar, Anand wrote: > My main bone of contention was the statement that there was no reason for > not building something as a module. There is a case for building drivers > into the kernel. Whether it is the best choice is something that depends > on what one is trying to achieve. As Felipe wrote, it is easy to reconfigure a module to be build in than it is to get a build in and have it to be compilable and usable as module. Developing a module gives you for free the builtin case. The other way is not always true. Your case of "let's veryfy all the modules at once by converting them to built-ins" is more the exception than the rule. > > And on top of that, having modules allows to makes it simpler to address > > in one go different boards and subarchitectures. > > I'm afraid I don't understand. How would having a driver as a module or > built-in make a difference when targetting different boards? I can do just one build and use the same binary to do the deployment to different boards. That's the direction the kernel is currently going to, with code that probes for OMAP version and uses the appropriate register addresses. The bootloader can pass the board type as option. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/7] 34XX: PM: Workaround to build omap hsmmc as a module
On Wed, 2008-06-25 at 07:03 -0500, ext Felipe Balbi wrote: > And like you said, if the defconfig is all modular (or all built-in) > the user/manufacturer/hacker can always change it later. Although > I defend that Reference Boards' defconfigs should be as modular > as possible. I totally agree: furthermore testing power features is damn easier if we can bisect the modules and zero on the offending driver. And on top of that, having modules allows to makes it simpler to address in one go different boards and subarchitectures. The SDP is to many of us just the mean to develop sw for the real HW. Modules don't harm SDP only users but help those involved in product creation. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: OMAP: remove unnecessary locking in clk_get_rate()
Hi, On Wed, 2008-06-04 at 17:11 -0700, ext Kevin Hilman wrote: > The same can happen even with the locking. If someone asks for the > rate, and then another thread changes the rate right after, the thread > who asked for the rate has an out-of-date value. I don't understand how this would materialize in practice: - if the rate is beign changed by 2 threads from the same driver, then the driver itself needs to take care of its internal state and coherency - if 2 different drivers are contending the same clock, then 2 children clocks should be created and the clock fw would take care of failing the request of the 2nd child, if it is incompatible with the rate set by the 1st one - if a dvfs change is responsible of changing the rate supplied to a driver which asked it with clk_get_rate(), the dvfs transition has no reason to happen in case it would violate the constraints set by clock users. Does this make sense? -- Cheers, Igor --- Igor Stoppa Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix n800 build - Remove kernel config conditional declaration of TSC2005 device config structures
Hi, On Sun, 2008-05-25 at 10:48 +0200, ext nick loeve wrote: > Hi, > > This patch is if i do not build with CONFIG_TOUCHSCREEN_TSC2005 enabled. > > I am trying to build a bare basics kernel for the n800, depending on what exactly is your goal, you might discover that it is not reachable: the bootloader does lots of initializations (lcd, usb, ...) that are reset by the respective drivers. In case you don't include those drivers, you can kiss goodbye to working power management. The only way would be to create a section in the board file which groups all the resets and executes them regardless of the respective driver being enabled. The bootrom also does initialize the UART. -- Cheers, Igor --- Igor Stoppa Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC/SD cards hotplug scenario
Hi, On Thu, 2008-05-22 at 21:01 +0100, ext Russell King - ARM Linux wrote: > Basically, what I'm trying to say is that ejecting any medium randomly > from the system is _always_ going to result in problems of some nature. > Some of which you can reduce the impact from, others are fairly terminal. > The only safe solution is the unmount, wait for data to be written, and > then eject the card. from this point of view it is a watered down version of "what happens when the power is removed abruptly", which unfortunately cannot really be avoided on battery powered devices with removable battery. If the system is supposed to survive such cases, then ext2 is probably not the best choice and a journaling fs (ext3 ?) should be considered. With MMC even the way the power fails (vcore fading away before/after vio) affects the possibility of the embedded uC b0rking. So it needs to be addressed also at board HW level. This of course cannot be really controlled when the MMC is removed from the slot, unless there is a sensor on the MMC lid. Sensor that could be used for an emergency, controlled powerdown, with no sync. But on the Tablets we instead show a warning and tell the user to be nice and close back the lid: UI designers prefer such approach. Just my 2 cents. -- Cheers, Igor --- Igor Stoppa Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] CBUS: Make retu watchdog behave like a standard Linux watchdog
Hi Tony, On Mon, 2008-05-12 at 17:35 -0700, ext Tony Lindgren wrote: > Make retu watchdog behave like a standard Linux watchdog. > > Let the kernel do the kicking until the watchdog device is opened. This is not always the desidered behavior: the powerdown wd is used to ensure that the whole sw stack is healty: doing the kicking in kernelspace for free introduces the case where userspace can get stuck and the device does not powerdown. Also the unconditional loading of the maximum value during probe is not aligned with the original reset logic, which was to have the powerdown wd to allow for 2 boot attempts: -cold boot -> load max value in retu wd (63s) -> load 30s in omap wd -try to kick both wds if fail, then omap reboots, but retu keeps counting down -warm boot -> let the retu wd untouched -> load 30s in omap wd -try to kick both wds if fail, retu powers down That was the original idea in 770 times and i still like it. To conclude, i'd see inkernel kicking more as a debugging feature while one is hacking at the kernel than a desirable quality of a stable kernel. -- Cheers, Igor --- Igor Stoppa Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
On Mon, 2008-04-28 at 01:32 +0300, ext Felipe Balbi wrote: > On Sun, Apr 27, 2008 at 12:43:19PM +0300, Kalle Valo wrote: > > "ext Felipe Balbi" <[EMAIL PROTECTED]> writes: > > > > > Current linux-omap's head has all the necessary pieces to get n810 > > > working. Touchscreen, keypad, ambient light sensor, led, usb, everything > > > is there. > > > > What about sound? > > I'm sure it'll come from alsa-devel soon. I also wonder if any kernel to userspace interface has changed since we released the FW: that could compromise the execution of system services. It would be probably good to check if any "obsolete interface" option has to be enabled when configuring the new kernel. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-omap vs N810
On Mon, 2008-04-28 at 00:01 +0200, ext [EMAIL PROTECTED] wrote: > Hello, > I'm having a major problem running linux-omap kernel on Nokia N810. > After correct build and flashing (tested by the use of self-built patched > Nokia kernel) the device seems to hang before framebuffer initialization, > then is rebooted by the watchdog. Manual FB update is disabled, I've > checked the configuration in many possible ways. > > I'd like to hear about possible causes of that. > > I do not have the serial console wired in (yet_, but would still like to > get debugging output. What would you recommend? Do you have it in RD mode with no-lifeguard-reboots (check flasher options)? If it's a reboot performed by the sw watchdog because some component is crashing too many times, you could get a bit further in the boot sequence, maybe to the point of ssh into the tablet. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
On Fri, 2008-04-25 at 21:52 +0300, ext Felipe Balbi wrote: > On Fri, Apr 25, 2008 at 09:31:42PM +0300, Igor Stoppa wrote: > > > You forget power management. It should partially be redone together with > > the omap3 work, but stuff like DVFS has a quite different implementation > > due to the different capabilities of the implementations. > > no comments. since you have a both TRMs, you can check it by yourself: DMA stalling is not available in 2420 > > > Maybe it's easier to get android's patches on top of current linux-omap > > > ? > > > > For any practical case where the device has to be used as mobile > > platform I think it's not an option to use the current l-o. > > For some experiments with android is good enough. maybe ... i'm not the one experimenting, i'm just saying that it's better to get a bunch of charged batteries, in case one wants to carry the tablet around. > > Hopefully it will be in the future. > > as soon as people start releasing code... in case you haven't noticed, there's some major rework ongoing for power management as i said, hopefully in the future also n810 will benefit from it -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
On Fri, 2008-04-25 at 21:36 +0300, ext Felipe Balbi wrote: > Current linux-omap's head has all the necessary pieces to get n810 > working. Somehow. > Touchscreen, keypad, ambient light sensor, led, usb, everything > is there. You forget power management. It should partially be redone together with the omap3 work, but stuff like DVFS has a quite different implementation due to the different capabilities of the implementations. > Maybe it's easier to get android's patches on top of current linux-omap > ? For any practical case where the device has to be used as mobile platform I think it's not an option to use the current l-o. Hopefully it will be in the future. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Updates on mcbsp driver
On Fri, 2008-04-25 at 00:10 +0300, ext Felipe Balbi wrote: > On Thu, Apr 24, 2008 at 11:54:20AM -0400, Eduardo Valentin wrote: > > From: Eduardo Valentin <[EMAIL PROTECTED]> > > > > This patch series updates mcbsp driver by transforming it into > > a platform driver. This is a very initial implementation. > > Basically it moves machine specific code to their correct place > > and creates the platform driver necessary structures. > > > > It must be working for previous boards. For omap34xx it should > > work for mcbsp 1 and 2. > > > > In order to do not break other places, I tryied to do not change > > previous API. But future improvements are needed. > > > > Clock definitions for mcbsp 1 and 2 were also modified to add > > correct support for omap34xx. > > > > Comments are wellcome. > > checkpatch doesn't complain, although i didn't really test it. However I'd prefer see this patchset being merged with [RFC/PATCH 1/1] McBSP support for 2430/34XX and only later considered for integration. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hi Paul, On Thu, 2008-04-17 at 14:47 -0600, ext Paul Walmsley wrote: > Hello Igor, > > On Thu, 17 Apr 2008, Igor Stoppa wrote: > > > On Thu, 2008-04-17 at 13:44 -0600, ext Paul Walmsley wrote: > > > > > True, but if we can do a debugfs implementation first, then that seems > > > like a good way to start, no? Userspace PM implementations are probably > > > some months in the future, and we can mandate that debugfs be mounted for > > > those. > > > > I can hardly see the benefit of a userspace implementation, considering > > the extra context switch required and the fact the in many cases clocks > > get enabled in response to irqs. > > I agree that we shouldn't try to move the clock framework to userspace. > > But, determining what OPP to switch to next, based on system load or other > requirements published by drivers or userspace processes; or determining > what power state to put powerdomains to -- it would be nice to experiment > with a userspace governor for those tasks. It would certainly make > development and testing easier. yes, it can be used to play with it in its infancy state, when one is still not looking for performance/stability stress testing. Afterward it simply doesn't fit the bill of leveraging the HW response time. Notice also that with QoS information coming from different sources, mostly low level ones, this will generate lots of cache trashing. > > > In terms of the clock tree, it would be good to allow userspace-driven > > > OPP > > > changes, analogous to CPUFreq's userspace governor. [ In general, I > > > agree > > > that userspace should not be changing driver clocks directly, just like > > > userspace should not be mucking around in /dev/mem directly :-) ] > > > > That also sounds akward at best: cpufreq (or similar) is much better > > suited for this sort of activity; userspace governor would be the > > userspace controller you refer to, but it is far from being optimal. > > > > Userspace should limit itself to changing policies. > > CPUFreq is good, but it does not manage non-CPU-frequency knobs very well, > and there are plenty of those on OMAP3. But CPUFreq can be expanded. Call it systemfreq or whatever can be more appealing from an advertising point of view. For omap HW anything different from ondemand doesn't make much sense. Maybe performance, would be another viable option, in certain cases. > Is there any reason why we should not allow the option of userspace OPP > selection/powerdomain control for OMAP? If people don't want to use it, > they don't have to :-) No, of course freedom is good. But it shouldn't be freedom of knowingly adopt suboptimal solutions just for the sake of diversity. An approach that doesn't involve requiring userspace components can be used also for more "embedded" systems where there might be no traditional userspace. A similar case would be in replacing CPUIdle with user space based decision, which is likely far from being optimal. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hi all, On Thu, 2008-04-17 at 13:44 -0600, ext Paul Walmsley wrote: > Hello Hiroshi, David, > > On Thu, 17 Apr 2008, David Brownell wrote: > > > On Thursday 17 April 2008, Hiroshi DOYU wrote: > > > > > And if there will be a little possibility that sysfs attribute can be > > > used by userland in the future, keeping sysfs instead of debugfs > > > doesn't seem not so illegal, does it? > > True, but if we can do a debugfs implementation first, then that seems > like a good way to start, no? Userspace PM implementations are probably > some months in the future, and we can mandate that debugfs be mounted for > those. I can hardly see the benefit of a userspace implementation, considering the extra context switch required and the fact the in many cases clocks get enabled in response to irqs. > > I happen to think that the clock tree is sensitive enough > > that it should not be managed from userspace in production > > systems. (Except possibly through driver-specific APIs which > > ensure the right rules are followed.) Too easy to break things > > otherwise. > > In terms of the clock tree, it would be good to allow userspace-driven OPP > changes, analogous to CPUFreq's userspace governor. [ In general, I agree > that userspace should not be changing driver clocks directly, just like > userspace should not be mucking around in /dev/mem directly :-) ] That also sounds akward at best: cpufreq (or similar) is much better suited for this sort of activity; userspace governor would be the userspace controller you refer to, but it is far from being optimal. Userspace should limit itself to changing policies. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power Management on OMAP2
Hi Suresh, On Fri, 2008-04-04 at 16:01 +0530, ext Suresh Rajashekara wrote: > Hi All, > > I was planning to start some work on the power management for > Mistral's OMAP2 EVM. > > Has anyone started working on this? Any idea what state the PM > support is in the current GIT tree? > > Thanks in advance, You could start checking the recent patches for omap3 since they are actually covering more than 3430 and can be leveraged for omap2 as well. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
