Messages in this thread Patch in this message | | | Date | Fri, 12 Jun 2009 17:05:04 +0200 | From | Pavel Machek <> | Subject | Re: 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/
| |