Messages in this thread | | | Date | Thu, 11 Jun 2009 10:25:33 +0200 | From | Pavel Machek <> | Subject | Re: HTC Dream aka. t-mobile g1 support |
| |
On Wed 2009-06-10 14:55:52, Brian Swetland wrote: > On Wed, Jun 10, 2009 at 2:37 PM, Pavel Machek<pavel@ucw.cz> wrote: > >> I'd love to find an effective way to get more of the msm support > >> cleaned up (as necessary) and into the mainline. We're bringing our > >> work forward and rebasing to keep tracking the latest released kernel, > >> and working on getting core bits we need that other stuff depends on > >> in -- look at the thread on linux-pm where the wakelock/suspendblocker > >> framework has been reviewed, revised, resent repeatedly, etc. > > > > I guess wakelocks should be removed from first version of drivers for merge. > > It'd be nice to get that sorted out first, but it does seem like it's > going to take a while to get there, so yeah, guess we'd have to go a > step at a time.
Merging drivers is (/should be) easy. Merging core features take a while.
> >> The msm7k unfortunately requires a lot of infrastructure to work given > >> that the baseband (a black box to us) controls much of the world. > >> Last time around when I tried submitting some of the core ipc support > >> to talk to it on the lakml, there seemed to be uncertainty about who > >> even would review that. > > > > Try again, then :-). [Merging to drivers/staging is _very_ easy, and > > even that is good first step.] > > Is there something equivalent for arch code? The bulk of our msm7k > support is under arch/arm/mach-msm/... though if there are sane places > to split out bigger chunks like the qdsp5/qdsp6 support, etc, we're > open to suggestion.
drivers/staging already contains stuff such a filesystems. Putting arch-specific drivers there should be okay.
> I'm not sure the smd (shared memory driver / virtual serial channels) > that everything else depends on makes sense outside of mach-msm, given > it's all very specific to the baseband and firmware that runs on it.
Well, it is still a driver for your baseband chip, right?
...drivers/staging is _not_ final place for your code. When the code is good enough, it should move. But it is place where stuff like TI wifi driver would be acceptable.
> Basically there's a stack: > > smsm -- "shared memory state machine" (used for power collapse coordination) > smd -- "shared memory driver" (virtual serial channels, 8k bidirectional fifos) > rpcrouter/oncrpc -- rpc transport layer used for audio, audio routing, etc > > These are linux implementations of protocols the baseband speaks. > > Other stuff then stacks on smd (rmnet -- virtual ethernet, at control > channels, etc) and oncrpc (dsp control, rtc, gps, some media control).
Is it all neccessary for boot? Getting it booting with display should be the first goal... GPS/RTC/... can come later.
> > Actually, mailing patches so that people do not have to do git pull + > > diff is very good zeroth step :-). > > We've tried to do both in the past -- setup a patchset that's pullable > for those who want to pull and get send-email 'em out to the list.
Yeah, you need to repeat it like each two weeks to get attention.
> >> We have full support for MSM7201A, including fully functional power > >> management, working on a number of commercially shipping devices that > >> we'd absolutely love to get into mainline. Rebasing and bringing this > >> stuff forward all the time is a lot of work and certainly not the > >> optimal way to do it. Getting it in a couple pieces at a time is slow > >> going, but it seemed to cause frustration with just the small number > >> of things we were looking for review/approval for... > > > > I have some experience with patch merging, lets see if I can > > help... It would be good to merge it upstream before the hw is > > obsolete... > > Conveniently a lot of the peripherals are used in later generation 7k > and 8k SoCs, so this stuff should actually be useful for new hardware > for a while. 7201A based products are still shipping new this year > (HTC Magic, for example).
Good.
> I think we're probably due for another round of flattening and > cleaning up against 2.6.30 or 31 and seeing what survives review and > what we can do to get the mainline msm code closer to fully > functional.
Yes, please. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |