Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

On Wed, Jun 10, 2009 at 2:37 PM, Pavel Machek<pavel@xxxxxx> 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.

>> 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.

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.
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).

> 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.

>> 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).

Help is certainly appreciated.

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.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/