On Thu, May 13, 2010 at 03:45:03PM -0700, Greg KH wrote:
Ah, that's surprising - I had thought most of the issues there were due
to the substantial MSM architecture core code which most of the G1 stuff
depended on (things like the DSP interface and so on) and the general
need for staging-style updates which churned against the non-mainline
versions rather than the wakelocks. It's true that the wakelocks
weren't helping, though.
Most of the cases I've seen have been off-CPU drivers that were either
working to outdated APIs or having to jump through hoops because they
really wanted to use new kernel features rather than CPU things.
Not if it's genuinely G1 specific, although presumably most of that
driver is actually chip drivers for the various components of a camera
subsystem which may well appear in other systems (not that I have the
slightest bit of familiarity with how camera hardware is organised).
Well, like I've said I personally don't object to merging them now that
the audio use case has been sorted. I suggested this because it would
allow something to be put in place to facilitate driver merging which
would avoid the core and userspace issues that people are still raising
with the implementation and let people get on with at least the driver
side.
If wakelocks don't make the next merge window and there is a problem
with drivers then it'd be nice to get the stubs in so that the APIs are
present in subsystem trees for drivers to merge.
--
