Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek <pavel@ucw.cz>]

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