Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

On Fri, Jun 12, 2009 at 8:05 AM, Pavel Machek<pavel@xxxxxx> wrote:
>> On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<pavel@xxxxxx> wrote:
>> > 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-*/).
>
> If it is driver for baseband, then it could live outside mach-msm,
> right?

Some of the higher level bits, probably.  The lower level bits are
essential for operation.  These are SoCs with integrated baseband and
the baseband is the "master" (boots first, owns key resources like
clocks/vregs, etc).

>> 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.
>
> staging is for GPLed code that needs to be cleaned up, first. Horrible
> stuff like drivers for windows in windows coding style go there.

Ahhh.  Our stuff hopefully is not quite that ugly.

>> 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.
>
> Actually, I believe it would be better to submit them first and
> checkpatch later. I quickly went through the patches (122KLoC)... and
> most are pretty much okay, but some have issues bigger than coding
> style (like wrong userland interfaces).

We've been trying to stay as style clean as possible, though not
everything's perfect.  What are some of the specific userland
interfaces you're worried about?

> What is htc_pwrsink infrastructure? Some kind of power accounting
> infrastructure for better battery estimates?

Yup.  It's an HTC specific thing -- some of their devices don't have a
battery gauge IC and estimate current drain based on hints provided to
the baseband from the apps processor.  I'm not particularly thrilled
with the interface, but without it the battery level estimation is
flakier.

> I see stuff like jpeg and mp3 coprocessors. That's oncrpc?

That's done by one of the DSPs (the other one is dedicated to the
baseband for network stuff).  oncrpc is used to talk to some
management services on the baseband to request dsp module loading,
setup audio hardware, etc.  a direct shared memory mailbox interface
is used to communicate withe the DSP once things are up and going.
The qdsp5 code deals with this.

>> > 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.
>
> Good, with framebuffer+nand we have "usable" machine, right?

That should get you something that can boot to a fb console from
onboard flash.  The serial driver for debugging and sdio for more
storage (if you want to fire up debian or something) would probably be
nice to have.

> Can someone apply this?

Sure.  Applied to android-msm-2.6.29 tree.

Thanks,

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/