Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland <swetland@google.com>]

On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<pavel@ucw.cz> wrote:
> On Wed 2009-06-10 14:55:52, Brian Swetland wrote:
>> 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?

Yes -- what I meant is more "does it belong under arch/arm/mach-msm/"
(given that it's very specific to that architecture and unlikely to
ever be useful elsewhere) or "does it belong somewhere else" (because
it's a pretty big pile of code compared to other stuff like
gpio/interrupt/etc stuff that tends to live under arch/arm/mach-*/).

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

Interesting -- reading up more on staging now.  I know that Greg KH
has been pulling some of the "generic" android drivers into staging
(Thanks, Greg!), but hadn't really looked at the rationale behind
staging in general.

Sounds like packing up the serial, sdio, nand, framebuffer, etc
drivers for submission into staging might make sense.  We can do the
obvious stuff like make sure they're checkpatch clean and reasonably
tidy first.

In order to actually have the peripherals work, though, we'd need to
add to board-*.c, devices.c, etc so that the platform devices are
defined so the platform drivers (which almost all of these are) are
actually probed.

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

The lowest layer IPC (proc_comm) is used for clock/power control and
is already in mainline, and that gets the clk_* framework functional
and allows most of the peripheral drivers to work, thankfully.  Things
like the serial driver, framebuffer, sdio, nand controller, etc all
should be happy without additional core architecture support.

Thanks,

Brian