lkml.org 
[lkml]   [2009]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: HTC Dream aka. t-mobile g1 support
On Thu 2009-06-11 01:48:57, Brian Swetland wrote:
> 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-*/).

If it is driver for baseband, then it could live outside mach-msm,
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.
>
> 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.

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

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

Well, applying smaller patch is better than applying big patch...

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

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

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

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

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

Can someone apply this?

---

Improve documentation, add machine description to Kconfig, remove
misleading comment.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/Documentation/android.txt b/Documentation/android.txt
index 72a62af..15922d6 100644
--- a/Documentation/android.txt
+++ b/Documentation/android.txt
@@ -14,6 +14,12 @@ CONTENTS:
1.3 Recommended enabled config options
2. Contact

+0. Getting sources:
+-----------------
+
+git clone --reference /path/to/linux-git/for/speedup/ git://android.git.kernel.org/kernel/msm.git
+git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29
+

1. Android
==========
@@ -26,6 +32,7 @@ To see a working defconfig look at msm_defconfig or goldfish_defconfig
which can be found at http://android.git.kernel.org in kernel/common.git
and kernel/msm.git

+msm_defconfig should work on qualcomm reference design, HTC Magic and G1/ADP1.

1.1 Required enabled config options
-----------------------------------
@@ -114,6 +121,22 @@ SERIAL_CORE
SERIAL_CORE_CONSOLE


+Board code names
+----------------
+
+board-halibut is a qualcomm reference design. board-sapphire is HTC
+Magic. board-trout is HTC Dream/G1/ADP1.
+
+Booting your kernel
+-------------------
+
+hold down camera and red button to boot into rainbow screen. Then
+
+./fastboot boot linux-msm/arch/arm/boot/zImage ramdisk.img
+
+Machine will freeze at rainbow screen for a while, be
+patient. ramdisk.img is required.
+
2. Contact
==========
website: http://android.git.kernel.org
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 310caeb..478d20a 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -62,7 +62,9 @@ config MACH_HALIBUT
config MACH_TROUT
depends on ARCH_MSM
default y
- bool "Trout"
+ bool "Trout (HTC Dream, T-Mobile G1, Google ADP1)"
+ help
+ Select this to support HTC Dream, T-Mobile G1, Google ADP1.

config MACH_SAPPHIRE
depends on ARCH_MSM
diff --git a/include/linux/usb/mass_storage_function.h b/include/linux/usb/mass_storage_function.h
index 75ebce0..73cf1d4 100644
--- a/include/linux/usb/mass_storage_function.h
+++ b/include/linux/usb/mass_storage_function.h
@@ -1,5 +1,4 @@
/*
- * Switch class driver
*
* Copyright (C) 2008 Google, Inc.
* Author: Mike Lockwood <lockwood@android.com>

--
(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/

\
 
 \ /
  Last update: 2009-06-12 17:07    [W:0.217 / U:1.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site