On 03/29/2016 08:18 PM, Michael Mrozek wrote: > Am Tue, 29 Mar 2016 18:35:20 -0500 hat Nishanth Menon <nm@xxxxxx> > geschrieben: > [...] >>>> Right now, I get about 6 - 7 hours of usage with a 6000mAh battery >>>> (and everything enabled), whereas I have about 8 hours with a >>>> 4400mAh battery (and also everything enabled) on the Pandora. >> Unfortunately OMAP5 or DRA7 SoCs are no longer focussed on hand held >> world. Sorry, TI exited mobile business some years back - OMAP5 was >> one of the causalities. > > Well, yes, I fully agree with the DRA7, but wasn't the OMAP5 originally > planned as mobile processor? I am sorry, I am not permitted to talk about TI SoC internal plans on a public forum. I suggest asking your TI representative about the same. > > When we started, the OMAP5430 was still announced, and AFAIR, it was > meant for mobile devices, wasn't it? > > Sadly it never was released, but the OMAP5432 shouldn't be THAT much > worse... For people who have worked with previous generation SoCs, there is a difference. >>>> In theory, the OMAP5 should use less power for the same tasks the >>>> DM3730 or OMAP4 can do, but use more power for more CPU usage >>>> (which sounds logical). >> Not really logical - comparing A15 vs A8 and completely different >> process corners behaviors are not comparable. > > Yes, I know - but still, the A15 (especially with 28nm) should use less > power for the same CPU power as an A8, shouldn't it? > > Unless something really power hungry is going on in there, but as it > was originally planned as mobile CPU... hmm. Not complete accurate here: a) there is always power hungry (and thermal generators) in an SoC, else we'd be talking microcontrollers ;) b) we are assuming the very first version of SoC works "as designed". it never does. then it becomes a matter of priority to fix things that is of interest to the current market target.. that is where things change. In case of OMAP5: Original architecture targets != what end result SoC that is in production. >>>> Right now, it seems the kernel is fixed to 1GHz and 1,5GHz (or >>>> 500Mhz and 1GHz on our kernel, as we changed the settings). >> I suggest to read the operating conditions Addendum (NDA) for OMAP5 to >> better understand what OPPs are actually "expected to be function" - >> going out side those discrete points are basically "You are on your >> own". > > Well, trying out lower voltages shouldn't damage the system, I guess, > it would probably simply crash. Not necessarily. again, doing something like a hackish project with a single board - sure you can push the limits and see how far you can go.. but the side effects of insufficient voltage can manifest itself in very very confusing ways (having seen people spend months debugging mobile device issues where voltage was not sufficient for a freq thanks to a s/w sequencing bugs).. anyways.. there is no way I will agree to patches that wont meet TI specs, at the end of the day. >>> Not sure what kind of numbers omap5 should be able to get, but my >>> guess is we should reasonably easily get to 500 mW with LCD blanked >>> and device idle as listed above. That's what omap4 pandaboard es >>> seems to measure at with current mainline kernel, so I don't see why >>> omap5 could not do the same. >> Lets get somethings out of the way here: OMAP5 is NOT OMAP4. Other >> than the technologies that are completely different, there has been >> quiet a bit of descopes on OMAP5 Vs previous generation SoCs. >> Further, a ton of effort in productizing OMAP3 and 4, which is >> completely missing in OMAP5. Almost most of power management as has >> been functional during OMAP3/4 has been descoped - making it more >> inline with DRA7 is the best hope of moving things forward on OMAP5. > > True, I know that the software is not as optimized as it was with older > systems. That's not something I am too afraid of (unless the software > cannot be optimized by others because internal knowledge is required) > > I would be more afraid if the hardware would be an issue here, but I > guess hardwarewise the possibilities to save power should be there (as > the OMAP5 was developed BEFORE the complete mobile department basically > was shut down) again, yes it was architected in a era when power was of significant concern and the major market that was targetted needed it. the point I hope I am conveying is that as time changed, what was architected is NOT the same SoC that is actually being produced. >> From TI's perspective, despite a few of us community involved folks, >> there is very less interest in investigating all the missing features >> on OMAP5 at this point in time. > > That's nothing new and nothing unexpected for us. > > I just wanted to find out what the general status is and what could be > done to improve it. > > That said, it might not even be as bad as I thought - I've been using > the current Pyra for over 8 hours without a charge now. I didn't do > anything demanding (typed some text, created the keyboard layout, > etc.), but it was with that unoptimized X server that constantly eats > 8% CPU power and with all other stuff (USB Ports, 4G Modem, etc.) still > enabled (interrupts also added up to about 8% more CPU power). > > So we had 16% constant CPU load, everything enabled (also the keyboard > LEDs) and the battery worked for over 8 hours. I don't know how long it > will still work, as it's not yet calibrated, but that doesn't sound too > bad. I dont even know what a pyra is.. but anyways.. I do have a wish list of things to do where I can take some help ofcourse.. I am hoping that we can fix DVFS first -> ABB and AVS class 0, class1.5, class 2 for various TI SoCs will benefit everyone - But, this involves a lot of OPP framework and common work that needs to be done. cpuidle attempt to put CPUx into CSWR ended into a pure debacle with dynamic dependency breakage all over.. we were told to not do that and there was no interest in debugging issues related to that.. so (as upstream today does), it is enabled as part of suspend path.. Suspend path: core INA is descoped as well -> core can only stay in ON state.. long story, but it is a culmination of a bunch of bugs -> i am waiting on documentation update before I post patches descoping those as well :( Then we go into runtime pm optimization -> there again (with few exceptions) we might be able to get some optimizations done. >>> I've added linux-omap, Tero and Nishanth to Cc as they may be able >>> to provide some more info. >> I suggest using e2e.ti.com for further understanding of capabilities >> that can be enabled on OMAP5 - mostly getting to understand what TI is >> willing to support. I try my best to keep OMAP5 at least on par with >> DRA7 where possible - but that is not really in interest to many folks >> though. > > Thanks, every little bit of help really is appreciated! I am open to knowing what we would like to enable given the details that the hardware documentation provides. > Once the system is released, I'd gladly pay someone who would work on > that - but persons capable of doing that are hard to find, and the > question is: Is everything that's needed for an improvement available > in the hardware documentation? I hope so. I have'nt been paying too close an attention to OMAP5 documentation in recent years. but where we run into issues, using e2e.ti.com might provide answers. > BTW: How similar is the DRA7 to the OMAP5? > I know it SOUNDS very similar on the paper, but is the hardware similar > as well? After falling in to that trap of assuming DRA7 and OMAP5 are related two years back, I have come to the conclusion after some interesting experience that it really is not - I will stop there :). No matter how much I like the idea, having known the realities, I just hope that folks dont have too high hopes there. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
