See, NOW it makes sense...

I thought we had actually explained a number of situations where wakelocks provide value beyond existing solutions -- I'll have to dig through the linux-pm threads and try to extract some stuff from there. One thing we're looking to do is put together a clean writeup of the "why" behind all this as a basis for discussion.

I don't see how retention from idle (which we do as well) fully solves the problem -- since you can easily have situations, in an environment where you can't control every process/thread (300+ threads in a typical android system at boot -- yeah, kinda crazy, but it is what it is). Going to suspend means we don't need to worry about non-optimal software with polling/periodic behaviors causing the CPU to wake up more often than ideal. Also, you still have situations in which you *can't* go to full retention in idle because of a driver being busy (which is what idlelocks -- just another class of wakelock) are about.

I think it would be extremely valuable to get some folks together somewhere and try to hash some of this out. In general we are not opposed to slightly different ways of doing things as long as we accomplish what we need to accomplish power-wise. I mean, Arve's already respun the wakelock API (now suspend_blocker, no?) several times in response to various feedback.

I'd love to engage in a forum where the goal is to solve common problems rather than assign blame -- Greg's blogpost implying that he's giving a CELF keynote about how we suck does not create much enthusiasm on our side for attending, for example.

We know that some people would have been happier if we worked out a design for all of this before 1.0 shipped, but that didn't happen, and arguing about how practical it would have been or not doesn't really gain anybody anything. Figuring out how to collaborate on things so that future issues get sorted out earlier and more smoothly seems entirely worthwhile though.

So when/where is the next time/place that we could meet up with the other interest parties on the linux-pm front and talk about these things?

What I *did* say was that if you move away from the Qualcomm-based platform, you are going to be investing a *lot* more into the driver and architecture bring-up. But that could very well be a way of differentiating yourself in the market. It's a cost/benefit analysis and it appears that ebook reader makers have decided that over the long run they will make more money than it cost to port Android to a new architecture.

But the fact that almost all the phones running Android are doing so on Qualcomm 7k or 8k chipsets shows that most *phone* companies appear to be maximizing their investment by leveraging the work that Google has already done. Phone product cycles are also a lot faster than ebook reader product cycles, and phones have a lot more hardware in them (which requires more/different drivers) than ebook readers.

And just because Qualcomm comes out with a new platform doesn't mean your investment is worthless. Often new iterations of a chipset will contain only tweaks of the older hardware; they rarely rearchitect the entire system because that simply trashes all the money you've invested in the software so far. Which isn't smart.

For example, Android on the MSM8k can use mostly the same radio drivers (qmi), shared memory drivers (smd), network device (rmnet), etc that the MSM7k used. The GPU probably required a significantly modified driver, but at least you didn't have to rewrite *all* the drivers just to move from MSM7K -> MSM8K.