* HTC Dream aka. t-mobile g1 support
@ 2009-06-10 10:31 Pavel Machek
2009-06-10 11:13 ` Ian Molton
` (2 more replies)
0 siblings, 3 replies; 167+ messages in thread
From: Pavel Machek @ 2009-06-10 10:31 UTC (permalink / raw)
To: kernel list, linux-arm-kernel, ibm, swetland, san, rlove
Hi!
Is there patch for Dream support for 2.6.30 somewhere? The best I
could find is linux-msm tree, which is ... quite a big diff against
2.6.24:
Is all of it neccessary for dream or are parts such as board-halibut
parts of some other support? Do I have wrong tree entirely?
Pavel
arch/arm/Kconfig | 15
arch/arm/Makefile | 1
arch/arm/configs/msm_defconfig | 1129 +++++++++++++++++++
arch/arm/mach-msm/Kconfig | 238 ++++
arch/arm/mach-msm/Makefile | 21
arch/arm/mach-msm/Makefile.boot | 3
arch/arm/mach-msm/adsp.c | 870 ++++++++++++++
arch/arm/mach-msm/adsp.h | 246 ++++
arch/arm/mach-msm/adsp_6210.c | 282 ++++
arch/arm/mach-msm/adsp_6220.c | 282 ++++
arch/arm/mach-msm/adsp_driver.c | 495 ++++++++
arch/arm/mach-msm/board-halibut-keypad.c | 180 +++
arch/arm/mach-msm/board-halibut.c | 358 ++++++
arch/arm/mach-msm/clock-7x00a.c | 127 ++
arch/arm/mach-msm/clock.c | 573 +++++++++
arch/arm/mach-msm/clock.h | 120 ++
arch/arm/mach-msm/common.c | 227 +++
arch/arm/mach-msm/dma.c | 246 ++++
arch/arm/mach-msm/fiq_glue.S | 64 +
arch/arm/mach-msm/generic_gpio.c | 274 ++++
arch/arm/mach-msm/gpio.c | 527 ++++++++
arch/arm/mach-msm/gpio_chip.h | 38
arch/arm/mach-msm/gpio_hw.h | 100 +
arch/arm/mach-msm/hw3d.c | 186 +++
arch/arm/mach-msm/idle.S | 89 +
arch/arm/mach-msm/io.c | 90 +
arch/arm/mach-msm/irq.c | 514 ++++++++
arch/arm/mach-msm/nand_partitions.c | 87 +
arch/arm/mach-msm/perf.c | 184 +++
arch/arm/mach-msm/pm.c | 520 ++++++++
arch/arm/mach-msm/pm.h | 31
arch/arm/mach-msm/proc_comm.h | 106 +
arch/arm/mach-msm/rpc_server_dog_keepalive.c | 62 +
arch/arm/mach-msm/rpc_server_time_remote.c | 75 +
arch/arm/mach-msm/smd.c | 1326 ++++++++++++++++++++++
arch/arm/mach-msm/smd_private.h | 159 ++
arch/arm/mach-msm/smd_qmi.c | 865 ++++++++++++++
arch/arm/mach-msm/smd_rpcrouter.c | 1165 +++++++++++++++++++
arch/arm/mach-msm/smd_rpcrouter.h | 190 +++
arch/arm/mach-msm/smd_rpcrouter_device.c | 339 +++++
arch/arm/mach-msm/smd_rpcrouter_servers.c | 214 +++
arch/arm/mach-msm/smd_tty.c | 202 +++
arch/arm/mach-msm/timer.c | 431 +++++++
arch/arm/mach-msm/vreg.c | 143 ++
arch/arm/mm/Kconfig | 3
arch/arm/mm/proc-v6.S | 27
arch/arm/tools/mach-types | 220 +++
drivers/Makefile | 2
drivers/android/Kconfig | 9
drivers/android/Makefile | 1
drivers/android/pmem.c | 1314 ++++++++++++++++++++++
drivers/char/Kconfig | 4
drivers/char/Makefile | 1
drivers/char/dcc_tty.c | 331 +++++
drivers/i2c/busses/Kconfig | 7
drivers/i2c/busses/Makefile | 1
drivers/i2c/busses/i2c-msm.c | 514 ++++++++
drivers/input/misc/Kconfig | 5
drivers/input/misc/Makefile | 1
drivers/input/misc/gpio_axis.c | 190 +++
drivers/input/misc/gpio_event.c | 224 +++
drivers/input/misc/gpio_input.c | 303 +++++
drivers/input/misc/gpio_matrix.c | 397 ++++++
drivers/input/misc/gpio_output.c | 76 +
drivers/input/touchscreen/Kconfig | 6
drivers/input/touchscreen/Makefile | 1
drivers/input/touchscreen/synaptics_i2c_rmi.c | 565 +++++++++
drivers/misc/Kconfig | 7
drivers/misc/Makefile | 1
drivers/misc/kernel_debugger.c | 80 +
drivers/mmc/card/block.c | 216 +++
drivers/mmc/card/queue.c | 6
drivers/mmc/core/Kconfig | 7
drivers/mmc/core/core.c | 16
drivers/mmc/core/sd.c | 38
drivers/mmc/core/sdio.c | 68 -
drivers/mmc/host/Kconfig | 5
drivers/mmc/host/Makefile | 1
drivers/mmc/host/msm_sdcc.c | 1341 ++++++++++++++++++++++
drivers/mmc/host/msm_sdcc.h | 253 ++++
drivers/mtd/devices/Kconfig | 7
drivers/mtd/devices/Makefile | 1
drivers/mtd/devices/msm_nand.c | 1272 +++++++++++++++++++++
drivers/mtd/devices/msm_nand.h | 74 +
drivers/net/Kconfig | 6
drivers/net/Makefile | 2
drivers/net/msm_rmnet.c | 203 +++
drivers/net/smc91x.h | 14
drivers/rtc/Kconfig | 6
drivers/rtc/Makefile | 1
drivers/rtc/rtc-msm7x00a.c | 251 ++++
drivers/serial/Kconfig | 14
drivers/serial/Makefile | 2
drivers/serial/msm_serial.c | 760 ++++++++++++
drivers/serial/msm_serial.h | 119 ++
drivers/serial/msm_serial_debugger.c | 359 ++++++
drivers/usb/Kconfig | 2
drivers/usb/function/Kconfig | 49
drivers/usb/function/Makefile | 9
drivers/usb/function/adb.c | 463 +++++++
drivers/usb/function/diag.c | 263 ++++
drivers/usb/function/ether.c | 327 +++++
drivers/usb/function/loopback.c | 128 ++
drivers/usb/function/msm_hsusb.c | 1528 ++++++++++++++++++++++++++
drivers/usb/function/msm_hsusb_hw.h | 157 ++
drivers/usb/function/null.c | 118 ++
drivers/usb/function/ums.c | 469 +++++++
drivers/usb/function/usb_function.h | 117 +
drivers/usb/function/zero.c | 120 ++
drivers/video/Kconfig | 9
drivers/video/Makefile | 1
drivers/video/msm/Makefile | 18
drivers/video/msm/mddi.c | 872 ++++++++++++++
drivers/video/msm/mddi_client_dummy.c | 57
drivers/video/msm/mddi_client_toshiba.c | 183 +++
drivers/video/msm/mddi_hw.h | 303 +++++
drivers/video/msm/mdp.c | 302 +++++
drivers/video/msm/mdp_csc_table.h | 582 +++++++++
drivers/video/msm/mdp_hw.h | 598 ++++++++++
drivers/video/msm/mdp_ppp.c | 825 ++++++++++++++
drivers/video/msm/mdp_scale_tables.c | 634 ++++++++++
drivers/video/msm/mdp_scale_tables.h | 37
drivers/video/msm/msm_fb.c | 560 +++++++++
drivers/video/msm/msm_fb.txt | 53
include/asm-arm/arch-msm/board.h | 87 +
include/asm-arm/arch-msm/clock.h | 35
include/asm-arm/arch-msm/debug-macro.S | 46
include/asm-arm/arch-msm/dma.h | 165 ++
include/asm-arm/arch-msm/entry-macro.S | 38
include/asm-arm/arch-msm/fiq.h | 32
include/asm-arm/arch-msm/gpio.h | 48
include/asm-arm/arch-msm/hardware.h | 18
include/asm-arm/arch-msm/io.h | 33
include/asm-arm/arch-msm/irqs.h | 89 +
include/asm-arm/arch-msm/memory.h | 27
include/asm-arm/arch-msm/msm_adsp.h | 48
include/asm-arm/arch-msm/msm_fb.h | 65 +
include/asm-arm/arch-msm/msm_iomap.h | 140 ++
include/asm-arm/arch-msm/msm_rpcrouter.h | 145 ++
include/asm-arm/arch-msm/msm_smd.h | 107 +
include/asm-arm/arch-msm/rpc_clkctl.h | 36
include/asm-arm/arch-msm/rpc_pm.h | 100 +
include/asm-arm/arch-msm/system.h | 26
include/asm-arm/arch-msm/timex.h | 20
include/asm-arm/arch-msm/uncompress.h | 44
include/asm-arm/arch-msm/vmalloc.h | 22
include/asm-arm/arch-msm/vreg.h | 29
include/asm-arm/mach/mmc.h | 12
include/linux/android_pmem.h | 64 +
include/linux/gpio_event.h | 143 ++
include/linux/kernel_debugger.h | 41
include/linux/mmc/core.h | 8
include/linux/mmc/host.h | 17
include/linux/mmc/sdio_func.h | 7
include/linux/msm_adsp.h | 74 +
include/linux/msm_mdp.h | 84 +
include/linux/msm_perf.h | 89 +
include/linux/msm_rpcrouter.h | 44
include/linux/serial_core.h | 3
include/linux/synaptics_i2c_rmi.h | 42
160 files changed, 33494 insertions(+), 44 deletions(-)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 10:31 HTC Dream aka. t-mobile g1 support Pavel Machek @ 2009-06-10 11:13 ` Ian Molton 2009-06-10 11:49 ` Pavel Machek 2009-06-10 17:43 ` Brian Swetland 2009-06-10 19:48 ` Russell King - ARM Linux 2 siblings, 1 reply; 167+ messages in thread From: Ian Molton @ 2009-06-10 11:13 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, linux-arm-kernel, ibm, swetland, san, rlove Pavel Machek wrote: > Hi! > > Is there patch for Dream support for 2.6.30 somewhere? The best I > could find is linux-msm tree, which is ... quite a big diff against > 2.6.24 You could look at JesusFreaks blog if you havent already. Keep me updated on this as I have a Dream and will definately be wanting to 'roll my own' (debian userspace on SD, chroot android) -Ian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 11:13 ` Ian Molton @ 2009-06-10 11:49 ` Pavel Machek 2009-06-10 12:04 ` Ian Molton 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-10 11:49 UTC (permalink / raw) To: Ian Molton; +Cc: kernel list, linux-arm-kernel, ibm, swetland, san, rlove On Wed 2009-06-10 12:13:10, Ian Molton wrote: > Pavel Machek wrote: >> Hi! >> >> Is there patch for Dream support for 2.6.30 somewhere? The best I >> could find is linux-msm tree, which is ... quite a big diff against >> 2.6.24 > > You could look at JesusFreaks blog if you havent already. I know about his blog, but can't see any patches. Should I look harder? (Any urls?) > Keep me updated on this as I have a Dream and will definately be wanting > to 'roll my own' (debian userspace on SD, chroot android) If you get that to work, do tell me. I'd like to run debian on root, too. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 11:49 ` Pavel Machek @ 2009-06-10 12:04 ` Ian Molton 0 siblings, 0 replies; 167+ messages in thread From: Ian Molton @ 2009-06-10 12:04 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, linux-arm-kernel, ibm, swetland, san, rlove Pavel Machek wrote: > On Wed 2009-06-10 12:13:10, Ian Molton wrote: > I know about his blog, but can't see any patches. Should I look > harder? (Any urls?) I think I have the 2.6.27 (IIRC) sources from JF. I got them from his blog - they were buried inside an archive. JF is on #android on freenode (or was recently) Imm running a JF kernel on mine right now - seems to have full sensor support. Everything works. >> Keep me updated on this as I have a Dream and will definately be wanting >> to 'roll my own' (debian userspace on SD, chroot android) > > If you get that to work, do tell me. I'd like to run debian on root, > too. Will do :) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 10:31 HTC Dream aka. t-mobile g1 support Pavel Machek 2009-06-10 11:13 ` Ian Molton @ 2009-06-10 17:43 ` Brian Swetland 2009-06-10 19:47 ` Bob Copeland ` (2 more replies) 2009-06-10 19:48 ` Russell King - ARM Linux 2 siblings, 3 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-10 17:43 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, linux-arm-kernel, ibm, san, rlove On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<pavel@ucw.cz> wrote: > Hi! > > Is there patch for Dream support for 2.6.30 somewhere? The best I > could find is linux-msm tree, which is ... quite a big diff against > 2.6.24: Our current working tree (for the donut branch) is against 2.6.29: http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29 The cupcake/1.5 system update (latest production kernel) was against 2.6.27: http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.27 > Is all of it neccessary for dream or are parts such as board-halibut > parts of some other support? Do I have wrong tree entirely? Most of it is necessary. board-halibut is a qualcomm reference design. board-sapphire is HTC Magic. board-trout is G1/ADP1. arch/arm/config/msm_defconfig is how we configure the kernel we ship which supports all three. The ti wifi driver is enormous and in its own repository: http://android.git.kernel.org/?p=platform/system/wlan/ti.git;a=shortlog;h=refs/heads/cupcake Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 17:43 ` Brian Swetland @ 2009-06-10 19:47 ` Bob Copeland 2009-06-11 7:24 ` Kalle Valo 2009-06-10 19:58 ` Gary Thomas 2009-06-11 8:10 ` Pavel Machek 2 siblings, 1 reply; 167+ messages in thread From: Bob Copeland @ 2009-06-10 19:47 UTC (permalink / raw) To: Brian Swetland Cc: Pavel Machek, kernel list, linux-arm-kernel, ibm, san, rlove, Kalle Valo On Wed, Jun 10, 2009 at 1:43 PM, Brian Swetland<swetland@google.com> wrote: > The ti wifi driver is enormous and in its own repository: > http://android.git.kernel.org/?p=platform/system/wlan/ti.git;a=shortlog;h=refs/heads/cupcake For wifi, there's a patch to add sdio support to the soon-to-be-upstream wl12xx. It works, but that's about all for now. Patch is at http://bobcopeland.com/android_wifi.html, though the linux-wireless list is the official location for any future discussion / updates. -- Bob Copeland %% www.bobcopeland.com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 19:47 ` Bob Copeland @ 2009-06-11 7:24 ` Kalle Valo 0 siblings, 0 replies; 167+ messages in thread From: Kalle Valo @ 2009-06-11 7:24 UTC (permalink / raw) To: Bob Copeland Cc: Brian Swetland, Pavel Machek, kernel list, linux-arm-kernel, ibm, san, rlove Bob Copeland <me@bobcopeland.com> writes: > On Wed, Jun 10, 2009 at 1:43 PM, Brian Swetland<swetland@google.com> wrote: >> The ti wifi driver is enormous and in its own repository: >> http://android.git.kernel.org/?p=platform/system/wlan/ti.git;a=shortlog;h=refs/heads/cupcake > > For wifi, there's a patch to add sdio support to the soon-to-be-upstream > wl12xx. It works, but that's about all for now. Patch is at > http://bobcopeland.com/android_wifi.html, though the linux-wireless list > is the official location for any future discussion / updates. wl12xx is in net-next-2.6 tree currently and it should go to 2.6.31: http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=tree;f=drivers/net/wireless/wl12xx;h=06a34fea0223c161c7b21a6bc226b5882dcd39c8;hb=HEAD -- Kalle Valo ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 17:43 ` Brian Swetland 2009-06-10 19:47 ` Bob Copeland @ 2009-06-10 19:58 ` Gary Thomas 2009-06-10 20:09 ` Brian Swetland 2009-06-11 8:10 ` Pavel Machek 2 siblings, 1 reply; 167+ messages in thread From: Gary Thomas @ 2009-06-10 19:58 UTC (permalink / raw) To: Brian Swetland Cc: Pavel Machek, kernel list, linux-arm-kernel, ibm, san, rlove Brian Swetland wrote: > On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<pavel@ucw.cz> wrote: >> Hi! >> >> Is there patch for Dream support for 2.6.30 somewhere? The best I >> could find is linux-msm tree, which is ... quite a big diff against >> 2.6.24: > > Our current working tree (for the donut branch) is against 2.6.29: > http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29 How do I turn this URL into a 'repo init' command? The boilerplate on the web view just doesn't explain it to me. Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 19:58 ` Gary Thomas @ 2009-06-10 20:09 ` Brian Swetland 0 siblings, 0 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-10 20:09 UTC (permalink / raw) To: Gary Thomas; +Cc: Pavel Machek, kernel list, linux-arm-kernel, san, rlove On Wed, Jun 10, 2009 at 12:58 PM, Gary Thomas<gary@mlbassoc.com> wrote: > Brian Swetland wrote: >> On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<pavel@ucw.cz> wrote: >>> Hi! >>> >>> Is there patch for Dream support for 2.6.30 somewhere? The best I >>> could find is linux-msm tree, which is ... quite a big diff against >>> 2.6.24: >> >> Our current working tree (for the donut branch) is against 2.6.29: >> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29 > > How do I turn this URL into a 'repo init' command? The boilerplate on > the web view just doesn't explain it to me. Not sure on the repo details, but if you want to check the kernel code out using git, you can: % git clone git://android.git.kernel.org/kernel/msm.git % cd msm % git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29 Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 17:43 ` Brian Swetland 2009-06-10 19:47 ` Bob Copeland 2009-06-10 19:58 ` Gary Thomas @ 2009-06-11 8:10 ` Pavel Machek 2009-06-11 8:27 ` Brian Swetland 2009-06-11 14:33 ` Alex Riesen 2 siblings, 2 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-11 8:10 UTC (permalink / raw) To: Brian Swetland; +Cc: kernel list, linux-arm-kernel, ibm, san, rlove On Wed 2009-06-10 10:43:53, Brian Swetland wrote: > On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<pavel@ucw.cz> wrote: > > Hi! > > > > Is there patch for Dream support for 2.6.30 somewhere? The best I > > could find is linux-msm tree, which is ... quite a big diff against > > 2.6.24: > > Our current working tree (for the donut branch) is against 2.6.29: > http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29 > Strange, I attempted downloading this overnight (285MB!) by git clone --template=/data/l/clean-cg/ git://android.git.kernel.org/kernel/msm.git ....and got 2.6.27 sources. Aha, git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29 Helped. Thanks! > The cupcake/1.5 system update (latest production kernel) was against 2.6.27: > http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.27 > > > Is all of it neccessary for dream or are parts such as board-halibut > > parts of some other support? Do I have wrong tree entirely? > > Most of it is necessary. board-halibut is a qualcomm reference > design. board-sapphire is HTC Magic. board-trout is G1/ADP1. > arch/arm/config/msm_defconfig is how we configure the kernel we ship > which supports all three. Ok, could we get the boards renamed? g1 is known as dream, having trout+dream+g1+adp1 names for same piece of hardware is unnice. Hmm, perhaps this would be useful to apply? --- Inform people about board codenames, and add how-to download latest sources. Signed-off-by: Pavel Machek <pavel@ucw.cz> diff --git a/Documentation/android.txt b/Documentation/android.txt index 72a62af..a2ad1dc 100644 --- a/Documentation/android.txt +++ b/Documentation/android.txt @@ -14,6 +14,13 @@ CONTENTS: 1.3 Recommended enabled config options 2. Contact +0. Getting sources: +----------------- + +git clone --template=/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 + +(280MB+ download!) 1. Android ========== @@ -26,6 +33,8 @@ 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 ----------------------------------- @@ -113,6 +122,14 @@ LOG_BUF_SHIFT=17 SERIAL_CORE SERIAL_CORE_CONSOLE +1.4 Board code names + +board-halibut is a qualcomm reference design. board-sapphire is HTC +Magic. board-trout is G1/ADP1. + + + + 2. Contact ========== -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply related [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 8:10 ` Pavel Machek @ 2009-06-11 8:27 ` Brian Swetland 2009-06-11 11:09 ` Pavel Machek 2009-06-11 14:33 ` Alex Riesen 1 sibling, 1 reply; 167+ messages in thread From: Brian Swetland @ 2009-06-11 8:27 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, linux-arm-kernel, ibm, san, rlove On Thu, Jun 11, 2009 at 1:10 AM, Pavel Machek<pavel@ucw.cz> wrote: > On Wed 2009-06-10 10:43:53, Brian Swetland wrote: >> >> Our current working tree (for the donut branch) is against 2.6.29: >> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29 > > Strange, I attempted downloading this overnight (285MB!) Hm. I think if you add this as a remote to an existing repository containing the kernel (these trees are based on v2.6.27 and v2.6.29 respectively) it should only pull the deltas (which aren't that enormous). >> The cupcake/1.5 system update (latest production kernel) was against 2.6.27: >> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.27 >> >> > Is all of it neccessary for dream or are parts such as board-halibut >> > parts of some other support? Do I have wrong tree entirely? >> >> Most of it is necessary. board-halibut is a qualcomm reference >> design. board-sapphire is HTC Magic. board-trout is G1/ADP1. >> arch/arm/config/msm_defconfig is how we configure the kernel we ship >> which supports all three. > > Ok, could we get the boards renamed? g1 is known as dream, having > trout+dream+g1+adp1 names for same piece of hardware is unnice. It's hard to have a single name since carriers tend to use different names in different markets. We often start work on kernel support long before a product is announced, so we've been using the fish names to allow us to register board names with the ARM machine registry early on and not use bogus internal-only machine IDs. > Hmm, perhaps this would be useful to apply? I didn't realize we had an android.txt already under Documentation. Expanding it with more details sounds good to me. halibut - Qualcomm SURF 7201A trout - HTC Dream, Android ADP1, T-Mobile G1 sapphire - HTC Sapphire, HTC Magic There may be some other names used by other carriers or in other regions. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 8:27 ` Brian Swetland @ 2009-06-11 11:09 ` Pavel Machek 2009-06-11 11:24 ` Brian Swetland 2009-06-11 12:45 ` Bob Copeland 0 siblings, 2 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-11 11:09 UTC (permalink / raw) To: Brian Swetland; +Cc: kernel list, linux-arm-kernel, ibm, san, rlove On Thu 2009-06-11 01:27:43, Brian Swetland wrote: > On Thu, Jun 11, 2009 at 1:10 AM, Pavel Machek<pavel@ucw.cz> wrote: > > On Wed 2009-06-10 10:43:53, Brian Swetland wrote: > >> > >> Our current working tree (for the donut branch) is against 2.6.29: > >> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29 > > > > Strange, I attempted downloading this overnight (285MB!) > > Hm. I think if you add this as a remote to an existing repository > containing the kernel (these trees are based on v2.6.27 and v2.6.29 > respectively) it should only pull the deltas (which aren't that > enormous). I tried pulling deltas (by specifying --template=...), that was 285MB. Maybe I screwed something up. Anyway, now I have a tree, and yes it compiles. (After some "interesting" questions; perhaps defconfig should be updated?) Unfortunately, upon fastboot boot uImage, it hangs with black screen and backlight on. I _think_ I got config right, most "interesting" question was AMSS modem firmware version 1. 6.2.10 (MSM_AMSS_VERSION_6210) 2. 6.2.20 (MSM_AMSS_VERSION_6220) > 3. 6.2.20 + New ADSP (MSM_AMSS_VERSION_6225) 4. 6.3.50 (MSM_AMSS_VERSION_6350) (NEW) ...and I just selected "3" being default. No help available :-(. I have cupcake installed, and I believe I installed radio update required for cupcake. Can someone help? (And write Kconfig help text? :-). > > Ok, could we get the boards renamed? g1 is known as dream, having > > trout+dream+g1+adp1 names for same piece of hardware is unnice. > > It's hard to have a single name since carriers tend to use different > names in different markets. We often start work on kernel support > long before a product is announced, so we've been using the fish names > to allow us to register board names with the ARM machine registry > early on and not use bogus internal-only machine IDs. I know naming stuff is hard. But dream/g1/adp1 are both recognized by outside people. I don't think "trout" has similar level of recognition. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:09 ` Pavel Machek @ 2009-06-11 11:24 ` Brian Swetland 2009-06-11 11:48 ` Pavel Machek 2009-06-13 0:41 ` Tim Bird 2009-06-11 12:45 ` Bob Copeland 1 sibling, 2 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-11 11:24 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, linux-arm-kernel, ibm, san, rlove On Thu, Jun 11, 2009 at 4:09 AM, Pavel Machek<pavel@ucw.cz> wrote: > > Anyway, now I have a tree, and yes it compiles. (After some > "interesting" questions; perhaps defconfig should be updated?) > > Unfortunately, upon fastboot boot uImage, it hangs with black screen > and backlight on. You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img Extracting the ramdisk.img from the boot.img in the boot partition on an existing device is a pain. If you happen to have a cupcake userspace built from source that ramdisk.img should be suitable. If not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just init, init.rc, and adb, but it is necessary to boot. > I _think_ I got config right, most "interesting" > question was > > AMSS modem firmware version > 1. 6.2.10 (MSM_AMSS_VERSION_6210) > 2. 6.2.20 (MSM_AMSS_VERSION_6220) >> 3. 6.2.20 + New ADSP (MSM_AMSS_VERSION_6225) > 4. 6.3.50 (MSM_AMSS_VERSION_6350) (NEW) > > ...and I just selected "3" being default. No help available :-(. I > have cupcake installed, and I believe I installed radio update > required for cupcake. Can someone help? (And write Kconfig help text? > :-). This is correct. The shipping dream/sapphire devices are using AMSS 6.2.20+patches, which is option 3. I'll look over the Kconfig text and see what we can do here. The problem is that the baseband firmware (AMSS) changes some of the rpc interfaces incompatibly between versions, and different generations of the same hardware could be shipping with somewhat different baseband firmware. 6210 and 6220 are completely obsolete (never used in anything in production) and we should drop them to avoid confusion. >> > Ok, could we get the boards renamed? g1 is known as dream, having >> > trout+dream+g1+adp1 names for same piece of hardware is unnice. >> >> It's hard to have a single name since carriers tend to use different >> names in different markets. We often start work on kernel support >> long before a product is announced, so we've been using the fish names >> to allow us to register board names with the ARM machine registry >> early on and not use bogus internal-only machine IDs. > > I know naming stuff is hard. But dream/g1/adp1 are both recognized by > outside people. I don't think "trout" has similar level of > recognition. Would better descriptions in Kconfig help here? That's a lot easier and less disruptive than renaming the machine types (and the userspace android world, for good or ill uses the machine name to identify the hardware version for some hardware specific configuration stuff at runtime). Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:24 ` Brian Swetland @ 2009-06-11 11:48 ` Pavel Machek 2009-06-11 11:53 ` Brian Swetland 2009-06-13 0:41 ` Tim Bird 1 sibling, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-11 11:48 UTC (permalink / raw) To: Brian Swetland; +Cc: kernel list, linux-arm-kernel, ibm, san, rlove On Thu 2009-06-11 04:24:03, Brian Swetland wrote: > On Thu, Jun 11, 2009 at 4:09 AM, Pavel Machek<pavel@ucw.cz> wrote: > > > > Anyway, now I have a tree, and yes it compiles. (After some > > "interesting" questions; perhaps defconfig should be updated?) > > > > Unfortunately, upon fastboot boot uImage, it hangs with black screen > > and backlight on. > > You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img Aha, fastboot implies that ramdisk is optional.. apparently it is not. > Extracting the ramdisk.img from the boot.img in the boot partition on > an existing device is a pain. If you happen to have a cupcake > userspace built from source that ramdisk.img should be suitable. If > not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just > init, init.rc, and adb, but it is necessary to boot. I tried using ramdisk.img from sdk: root@amd:/data/l/android# ./fastboot boot /data/l/linux-msm/arch/arm/boot/uImage /data/l/android/sdk/platforms/android-1.5/images/ramdisk.img creating boot image... creating boot image - 1884160 bytes downloading 'boot.img'... OKAY booting... OKAY root@amd:/data/l/android# ls -al /data/l/android/sdk/platforms/android-1.5/images/ramdisk.img -rw-rw-rw- 1 pavel pavel 145785 May 15 03:13 /data/l/android/sdk/platforms/android-1.5/images/ramdisk.img ...no luck :-(. > > I _think_ I got config right, most "interesting" > > question was > > > > AMSS modem firmware version > > 1. 6.2.10 (MSM_AMSS_VERSION_6210) > > 2. 6.2.20 (MSM_AMSS_VERSION_6220) > >> 3. 6.2.20 + New ADSP (MSM_AMSS_VERSION_6225) > > 4. 6.3.50 (MSM_AMSS_VERSION_6350) (NEW) > > > > ...and I just selected "3" being default. No help available :-(. I > > have cupcake installed, and I believe I installed radio update > > required for cupcake. Can someone help? (And write Kconfig help text? > > :-). > > This is correct. The shipping dream/sapphire devices are using AMSS > 6.2.20+patches, which is option 3. > > I'll look over the Kconfig text and see what we can do here. The > problem is that the baseband firmware (AMSS) changes some of the rpc > interfaces incompatibly between versions, and different generations of > the same hardware could be shipping with somewhat different baseband > firmware. 6210 and 6220 are completely obsolete (never used in > anything in production) and we should drop them to avoid confusion. Or at least add (obsolete) to kconfig help or something. > >> > Ok, could we get the boards renamed? g1 is known as dream, having > >> > trout+dream+g1+adp1 names for same piece of hardware is unnice. > >> > >> It's hard to have a single name since carriers tend to use different > >> names in different markets. We often start work on kernel support > >> long before a product is announced, so we've been using the fish names > >> to allow us to register board names with the ARM machine registry > >> early on and not use bogus internal-only machine IDs. > > > > I know naming stuff is hard. But dream/g1/adp1 are both recognized by > > outside people. I don't think "trout" has similar level of > > recognition. > > Would better descriptions in Kconfig help here? That's a lot easier > and less disruptive than renaming the machine types (and the userspace > android world, for good or ill uses the machine name to identify the > hardware version for some hardware specific configuration stuff at > runtime). Better Kconfig description would certainly be nice. Renaming board-trout* to board-dream* would be also nice (and should be doable without any intrusive changes...?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:48 ` Pavel Machek @ 2009-06-11 11:53 ` Brian Swetland 2009-06-11 14:57 ` Pavel Machek 2009-06-11 14:58 ` Pavel Machek 0 siblings, 2 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-11 11:53 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 4:48 AM, Pavel Machek<pavel@ucw.cz> wrote: >> >> You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img > > Aha, fastboot implies that ramdisk is optional.. apparently it is not. Well, it *is* optional -- but the kernel as we build it needs an initrd to do much that's visible. Could probably enable fb console and provide a commandline that points console there (-c "kernel commandline" argument to fastboot). >> Extracting the ramdisk.img from the boot.img in the boot partition on >> an existing device is a pain. If you happen to have a cupcake >> userspace built from source that ramdisk.img should be suitable. If >> not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just >> init, init.rc, and adb, but it is necessary to boot. > > I tried using ramdisk.img from sdk: > > root@amd:/data/l/android# ./fastboot boot > /data/l/linux-msm/arch/arm/boot/uImage > /data/l/android/sdk/platforms/android-1.5/images/ramdisk.img > > ...no luck :-(. Is a uImage compatible with zImage (if the bootloader copies it to 0x10008000 and jumps there will it start?) > Better Kconfig description would certainly be nice. Renaming > board-trout* to board-dream* would be also nice (and should be doable > without any intrusive changes...?) Ah, I see. Yes, renaming the files would be easy to do and that's totally reasonable. I thought you wanted the machine type name changed. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:53 ` Brian Swetland @ 2009-06-11 14:57 ` Pavel Machek 2009-06-11 14:58 ` Pavel Machek 1 sibling, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-11 14:57 UTC (permalink / raw) To: Brian Swetland; +Cc: kernel list, linux-arm-kernel, san, rlove On Thu 2009-06-11 04:53:10, Brian Swetland wrote: > On Thu, Jun 11, 2009 at 4:48 AM, Pavel Machek<pavel@ucw.cz> wrote: > >> > >> You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img > > > > Aha, fastboot implies that ramdisk is optional.. apparently it is not. > > Well, it *is* optional -- but the kernel as we build it needs an > initrd to do much that's visible. Could probably enable fb console > and provide a commandline that points console there (-c "kernel > commandline" argument to fastboot). Ok... but still no success. For some reason it seems to work better if I use uImage (at least I get blank screen) than zImage (fastboot just hangs). > >> Extracting the ramdisk.img from the boot.img in the boot partition on > >> an existing device is a pain. If you happen to have a cupcake > >> userspace built from source that ramdisk.img should be suitable. If > >> not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just > >> init, init.rc, and adb, but it is necessary to boot. > > > > I tried using ramdisk.img from sdk: > > > > root@amd:/data/l/android# ./fastboot boot > > /data/l/linux-msm/arch/arm/boot/uImage > > /data/l/android/sdk/platforms/android-1.5/images/ramdisk.img > > > > ...no luck :-(. > > Is a uImage compatible with zImage (if the bootloader copies it to > 0x10008000 and jumps there will it start?) No idea :-(. (And thanks for ramdisk.img; it is different from what I have, but results seem same). > > Better Kconfig description would certainly be nice. Renaming > > board-trout* to board-dream* would be also nice (and should be doable > > without any intrusive changes...?) > > Ah, I see. Yes, renaming the files would be easy to do and that's > totally reasonable. I thought you wanted the machine type name > changed. Good. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:53 ` Brian Swetland 2009-06-11 14:57 ` Pavel Machek @ 2009-06-11 14:58 ` Pavel Machek 1 sibling, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-11 14:58 UTC (permalink / raw) To: Brian Swetland; +Cc: kernel list, linux-arm-kernel, san, rlove On Thu 2009-06-11 04:53:10, Brian Swetland wrote: > On Thu, Jun 11, 2009 at 4:48 AM, Pavel Machek<pavel@ucw.cz> wrote: > >> > >> You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img > > > > Aha, fastboot implies that ramdisk is optional.. apparently it is not. > > Well, it *is* optional -- but the kernel as we build it needs an > initrd to do much that's visible. Could probably enable fb console > and provide a commandline that points console there (-c "kernel > commandline" argument to fastboot). I tried that without much luck. Also... defconfig has mem=64M. Is that correct? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:24 ` Brian Swetland 2009-06-11 11:48 ` Pavel Machek @ 2009-06-13 0:41 ` Tim Bird 1 sibling, 0 replies; 167+ messages in thread From: Tim Bird @ 2009-06-13 0:41 UTC (permalink / raw) To: Brian Swetland Cc: Pavel Machek, kernel list, linux-arm-kernel, ibm, san, rlove Brian Swetland wrote: > On Thu, Jun 11, 2009 at 4:09 AM, Pavel Machek<pavel@ucw.cz> wrote: >> Anyway, now I have a tree, and yes it compiles. (After some >> "interesting" questions; perhaps defconfig should be updated?) >> >> Unfortunately, upon fastboot boot uImage, it hangs with black screen >> and backlight on. > > You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img > > Extracting the ramdisk.img from the boot.img in the boot partition on > an existing device is a pain. If you happen to have a cupcake > userspace built from source that ramdisk.img should be suitable. If > not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just > init, init.rc, and adb, but it is necessary to boot. I found the tools located here: "HOWTO: Unpack, Edit, and Repack Boot Images" http://forum.xda-developers.com/showthread.php?t=443994 to be very helpful. I wrote a small wrapper script to extract the recovery image, substitute a new kernel, and re-install it on the ADP1, which I use for my own kernel testing. I can post it somewhere if people are interested. I use the recovery partition instead of the boot partition. I leave the boot partition alone since this thing is also my phone and when I'm done debugging I want to get back to the original code and config easily. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:09 ` Pavel Machek 2009-06-11 11:24 ` Brian Swetland @ 2009-06-11 12:45 ` Bob Copeland 2009-06-11 13:00 ` Pavel Machek 1 sibling, 1 reply; 167+ messages in thread From: Bob Copeland @ 2009-06-11 12:45 UTC (permalink / raw) To: Pavel Machek Cc: Brian Swetland, kernel list, linux-arm-kernel, ibm, san, rlove On Thu, Jun 11, 2009 at 7:09 AM, Pavel Machek<pavel@ucw.cz> wrote: > Anyway, now I have a tree, and yes it compiles. (After some > "interesting" questions; perhaps defconfig should be updated?) > ...and I just selected "3" being default. No help available :-(. I > have cupcake installed, and I believe I installed radio update > required for cupcake. Can someone help? I can send you my .config if you want, I have it working. Note you need the latest userland because the initrd details changed a bit (e.g. a 2.6.29 kernel will not work on the 1.1 userland, but will work on 1.5, something to do with mounting the filesystems, I can't remember exactly from my serial traces.) -- Bob Copeland %% www.bobcopeland.com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:45 ` Bob Copeland @ 2009-06-11 13:00 ` Pavel Machek 2009-06-11 15:09 ` Bob Copeland 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-11 13:00 UTC (permalink / raw) To: Bob Copeland Cc: Brian Swetland, kernel list, linux-arm-kernel, ibm, san, rlove On Thu 2009-06-11 08:45:36, Bob Copeland wrote: > On Thu, Jun 11, 2009 at 7:09 AM, Pavel Machek<pavel@ucw.cz> wrote: > > Anyway, now I have a tree, and yes it compiles. (After some > > "interesting" questions; perhaps defconfig should be updated?) > > > ...and I just selected "3" being default. No help available :-(. I > > have cupcake installed, and I believe I installed radio update > > required for cupcake. Can someone help? > > I can send you my .config if you want, I have it working. That would be cool... > Note you need the latest userland because the initrd details changed > a bit (e.g. a 2.6.29 kernel will not work on the 1.1 userland, but > will work on 1.5, something to do with mounting the filesystems, I > can't remember exactly from my serial traces.) I do have cupcake userland (from JF)... When I change command line options or try to boot zImage, it hangs with rainbow screen. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 13:00 ` Pavel Machek @ 2009-06-11 15:09 ` Bob Copeland 0 siblings, 0 replies; 167+ messages in thread From: Bob Copeland @ 2009-06-11 15:09 UTC (permalink / raw) To: Pavel Machek; +Cc: Brian Swetland, kernel list, linux-arm-kernel, san, rlove [-- Attachment #1: Type: text/plain, Size: 644 bytes --] On Thu, Jun 11, 2009 at 9:00 AM, Pavel Machek<pavel@ucw.cz> wrote: > On Thu 2009-06-11 08:45:36, Bob Copeland wrote: >> I can send you my .config if you want, I have it working. > > That would be cool... Find it attached, it has mac80211 and a few other things enabled on top of the defconfig that you may not need. > I do have cupcake userland (from JF)... When I change command line > options or try to boot zImage, it hangs with rainbow screen. Ok.. I just use the ramdisk from the ADP 1.5 image. I'm based off of d8b8eb53cc52... which is a little buggy, but good enough for my wireless testing. -- Bob Copeland %% www.bobcopeland.com [-- Attachment #2: msm-config --] [-- Type: application/octet-stream, Size: 34904 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.29 # Sat May 16 17:02:04 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0xffff0000 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_PANIC_TIMEOUT=5 CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ASHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_FREEZER=y # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KIRKWOOD is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_LOKI is not set # CONFIG_ARCH_MV78XX0 is not set # CONFIG_ARCH_MXC is not set # CONFIG_ARCH_ORION5X is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_DAVINCI is not set # CONFIG_ARCH_OMAP is not set CONFIG_ARCH_MSM=y # CONFIG_ARCH_W90X900 is not set CONFIG_MSM_AMSS_VERSION=6225 # CONFIG_MSM_AMSS_VERSION_6210 is not set # CONFIG_MSM_AMSS_VERSION_6220 is not set CONFIG_MSM_AMSS_VERSION_6225=y CONFIG_MSM_DEBUG_UART_NONE=y # CONFIG_MSM_DEBUG_UART1 is not set # CONFIG_MSM_DEBUG_UART2 is not set # CONFIG_MSM_DEBUG_UART3 is not set # # MSM Board Type # CONFIG_MACH_HALIBUT=y CONFIG_MACH_TROUT=y CONFIG_MACH_SAPPHIRE=y CONFIG_HTC_HEADSET=y CONFIG_TROUT_BATTCHG=y CONFIG_HTC_PWRSINK=y CONFIG_MSM7X00A_USE_GP_TIMER=y # CONFIG_MSM7X00A_USE_DG_TIMER is not set CONFIG_MSM7X00A_SLEEP_MODE_POWER_COLLAPSE_SUSPEND=y # CONFIG_MSM7X00A_SLEEP_MODE_POWER_COLLAPSE is not set # CONFIG_MSM7X00A_SLEEP_MODE_APPS_SLEEP is not set # CONFIG_MSM7X00A_SLEEP_MODE_RAMP_DOWN_AND_WAIT_FOR_INTERRUPT is not set # CONFIG_MSM7X00A_SLEEP_WAIT_FOR_INTERRUPT is not set CONFIG_MSM7X00A_SLEEP_MODE=0 # CONFIG_MSM7X00A_IDLE_SLEEP_MODE_POWER_COLLAPSE_SUSPEND is not set CONFIG_MSM7X00A_IDLE_SLEEP_MODE_POWER_COLLAPSE=y # CONFIG_MSM7X00A_IDLE_SLEEP_MODE_APPS_SLEEP is not set # CONFIG_MSM7X00A_IDLE_SLEEP_MODE_RAMP_DOWN_AND_WAIT_FOR_INTERRUPT is not set # CONFIG_MSM7X00A_IDLE_SLEEP_WAIT_FOR_INTERRUPT is not set CONFIG_MSM7X00A_IDLE_SLEEP_MODE=1 CONFIG_MSM7X00A_IDLE_SLEEP_MIN_TIME=20000000 CONFIG_MSM7X00A_IDLE_SPIN_TIME=80000 CONFIG_MSM_IDLE_STATS=y CONFIG_MSM_IDLE_STATS_FIRST_BUCKET=62500 CONFIG_MSM_IDLE_STATS_BUCKET_SHIFT=2 CONFIG_MSM_IDLE_STATS_BUCKET_COUNT=10 CONFIG_MSM_FIQ_SUPPORT=y CONFIG_MSM_SERIAL_DEBUGGER=y CONFIG_MSM_SERIAL_DEBUGGER_CONSOLE=y CONFIG_MSM_SMD=y CONFIG_MSM_ONCRPCROUTER=y CONFIG_MSM_RPCSERVERS=y CONFIG_MSM_CPU_FREQ=y CONFIG_MSM_CPU_FREQ_ONDEMAND=y # CONFIG_MSM_CPU_FREQ_SCREEN is not set CONFIG_MSM_CPU_FREQ_ONDEMAND_MAX=384000 CONFIG_MSM_CPU_FREQ_ONDEMAND_MIN=245760 CONFIG_MSM_HW3D=y CONFIG_MSM_ADSP=y CONFIG_WIFI_CONTROL_FUNC=y CONFIG_WIFI_MEM_PREALLOC=y # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_V6=y # CONFIG_CPU_32v6K is not set CONFIG_CPU_32v6=y CONFIG_CPU_ABRT_EV6=y CONFIG_CPU_PABRT_NOIFAR=y CONFIG_CPU_CACHE_V6=y CONFIG_CPU_CACHE_VIPT=y CONFIG_CPU_COPY_V6=y CONFIG_CPU_TLB_V6=y CONFIG_CPU_HAS_ASID=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y # # Processor Features # CONFIG_ARM_THUMB=y # CONFIG_CPU_ICACHE_DISABLE is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_BPREDICT_DISABLE is not set # CONFIG_OUTER_CACHE is not set # # Bus support # # CONFIG_PCI_SYSCALL is not set # CONFIG_ARCH_SUPPORTS_MSI is not set # CONFIG_PCCARD is not set # # Kernel Features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_PREEMPT=y CONFIG_HZ=100 CONFIG_AEABI=y # CONFIG_OABI_COMPAT is not set CONFIG_ARCH_FLATMEM_HAS_HOLES=y # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=0 CONFIG_VIRT_TO_BUS=y CONFIG_UNEVICTABLE_LRU=y CONFIG_ALIGNMENT_TRAP=y # # Boot options # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="mem=64M console=ttyMSM,115200n8" # CONFIG_XIP_KERNEL is not set # CONFIG_KEXEC is not set # # CPU Power Management # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_MIN_TICKS=1 CONFIG_CPU_FREQ_SAMPLING_LATENCY_MULTIPLIER=500 # CONFIG_CPU_IDLE is not set # # Floating point emulation # # # At least one emulation must be selected # # CONFIG_VFP is not set # # Userspace binary formats # CONFIG_BINFMT_ELF=y CONFIG_HAVE_AOUT=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HAS_WAKELOCK=y CONFIG_HAS_EARLYSUSPEND=y CONFIG_WAKELOCK=y CONFIG_WAKELOCK_STAT=y CONFIG_USER_WAKELOCK=y CONFIG_EARLYSUSPEND=y # CONFIG_NO_USER_SPACE_SCREEN_ACCESS_CONTROL is not set # CONFIG_CONSOLE_EARLYSUSPEND is not set CONFIG_FB_EARLYSUSPEND=y # CONFIG_APM_EMULATION is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_NET=y # # Networking options # CONFIG_COMPAT_NET_DEV_OPS=y CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INET_TUNNEL is not set # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set # CONFIG_INET_DIAG is not set # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set CONFIG_ANDROID_PARANOID_NETWORK=y # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_NET_DSA is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_SCHED is not set # CONFIG_DCB is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set CONFIG_BT=y CONFIG_BT_L2CAP=y CONFIG_BT_SCO=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=y # CONFIG_BT_BNEP_MC_FILTER is not set # CONFIG_BT_BNEP_PROTO_FILTER is not set CONFIG_BT_HIDP=y # # Bluetooth device drivers # # CONFIG_BT_HCIBTSDIO is not set CONFIG_BT_HCIUART=y CONFIG_BT_HCIUART_H4=y # CONFIG_BT_HCIUART_BCSP is not set CONFIG_BT_HCIUART_LL=y # CONFIG_BT_HCIVHCI is not set # CONFIG_AF_RXRPC is not set # CONFIG_PHONET is not set CONFIG_WIRELESS=y CONFIG_CFG80211=m # CONFIG_CFG80211_REG_DEBUG is not set CONFIG_NL80211=y CONFIG_WIRELESS_OLD_REGULATORY=y CONFIG_WIRELESS_EXT=y CONFIG_WIRELESS_EXT_SYSFS=y # CONFIG_LIB80211 is not set CONFIG_MAC80211=m # # Rate control algorithm selection # # CONFIG_MAC80211_RC_PID is not set CONFIG_MAC80211_RC_MINSTREL=y # CONFIG_MAC80211_RC_DEFAULT_PID is not set CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel" # CONFIG_MAC80211_MESH is not set # CONFIG_MAC80211_LEDS is not set # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG_MENU is not set # CONFIG_WIMAX is not set CONFIG_RFKILL=y # CONFIG_RFKILL_PM is not set # CONFIG_RFKILL_INPUT is not set CONFIG_RFKILL_LEDS=y # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_CONCAT is not set CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_TESTS is not set # CONFIG_MTD_REDBOOT_PARTS is not set CONFIG_MTD_CMDLINE_PARTS=y # CONFIG_MTD_AFS_PARTS is not set # CONFIG_MTD_AR7_PARTS is not set # # User Modules And Translation Layers # CONFIG_MTD_CHAR=y CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # CONFIG_SSFDC is not set # CONFIG_MTD_OOPS is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # CONFIG_MTD_MSM_NAND=y # CONFIG_MTD_DATAFLASH is not set # CONFIG_MTD_M25P80 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # CONFIG_MTD_NAND is not set # CONFIG_MTD_ONENAND is not set # # LPDDR flash memory drivers # # CONFIG_MTD_LPDDR is not set # # UBI - Unsorted block images # # CONFIG_MTD_UBI is not set # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_MISC_DEVICES=y CONFIG_ANDROID_PMEM=y # CONFIG_ICS932S401 is not set # CONFIG_ENCLOSURE_SERVICES is not set CONFIG_KERNEL_DEBUGGER_CORE=y CONFIG_UID_STAT=y # CONFIG_C2PORT is not set # # EEPROM support # # CONFIG_EEPROM_AT24 is not set # CONFIG_EEPROM_AT25 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_93CX6 is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set # CONFIG_SCSI is not set # CONFIG_SCSI_DMA is not set # CONFIG_SCSI_NETLINK is not set # CONFIG_ATA is not set CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set CONFIG_BLK_DEV_DM=y CONFIG_DM_DEBUG=y CONFIG_DM_CRYPT=y # CONFIG_DM_SNAPSHOT is not set # CONFIG_DM_MIRROR is not set # CONFIG_DM_ZERO is not set # CONFIG_DM_MULTIPATH is not set # CONFIG_DM_DELAY is not set CONFIG_DM_UEVENT=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y # CONFIG_BONDING is not set # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_VETH is not set # CONFIG_PHYLIB is not set CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_AX88796 is not set CONFIG_SMC91X=y # CONFIG_DM9000 is not set # CONFIG_ENC28J60 is not set # CONFIG_SMC911X is not set # CONFIG_SMSC911X is not set # CONFIG_DNET is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set # CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set # CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set # CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set # CONFIG_B44 is not set CONFIG_NETDEV_1000=y CONFIG_NETDEV_10000=y # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set CONFIG_WLAN_80211=y # CONFIG_LIBERTAS is not set # CONFIG_LIBERTAS_THINFIRM is not set # CONFIG_MAC80211_HWSIM is not set # CONFIG_P54_COMMON is not set # CONFIG_IWLWIFI_LEDS is not set # CONFIG_HOSTAP is not set # CONFIG_B43 is not set # CONFIG_B43LEGACY is not set # CONFIG_RT2X00 is not set # CONFIG_WL12XX is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # CONFIG_WAN is not set CONFIG_PPP=y # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=y # CONFIG_PPP_SYNC_TTY is not set CONFIG_PPP_DEFLATE=y CONFIG_PPP_BSDCOMP=y # CONFIG_PPP_MPPE is not set # CONFIG_PPPOE is not set # CONFIG_PPPOL2TP is not set # CONFIG_SLIP is not set CONFIG_SLHC=y # CONFIG_NETCONSOLE is not set CONFIG_MSM_RMNET=y CONFIG_MSM_RMNET_DEBUG=y # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_ISDN is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # # Userland interfaces # # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set CONFIG_INPUT_KEYRESET=y # # Input Device Drivers # # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set CONFIG_INPUT_TOUCHSCREEN=y # CONFIG_TOUCHSCREEN_ADS7846 is not set # CONFIG_TOUCHSCREEN_FUJITSU is not set # CONFIG_TOUCHSCREEN_GUNZE is not set CONFIG_TOUCHSCREEN_ELAN_I2C_8232=y # CONFIG_TOUCHSCREEN_ELO is not set # CONFIG_TOUCHSCREEN_WACOM_W8001 is not set # CONFIG_TOUCHSCREEN_MTOUCH is not set # CONFIG_TOUCHSCREEN_INEXIO is not set # CONFIG_TOUCHSCREEN_MK712 is not set # CONFIG_TOUCHSCREEN_PENMOUNT is not set CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI=y # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set # CONFIG_TOUCHSCREEN_TOUCHWIN is not set # CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set # CONFIG_TOUCHSCREEN_TSC2007 is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set CONFIG_INPUT_UINPUT=y CONFIG_INPUT_GPIO=y CONFIG_INPUT_KEYCHORD=y # # Hardware I/O ports # # CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_DEVMEM is not set # CONFIG_DEVKMEM is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # # CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_MSM=y # CONFIG_SERIAL_MSM_CONSOLE is not set CONFIG_SERIAL_MSM_CLOCK_CONTROL=y CONFIG_SERIAL_MSM_RX_WAKEUP=y CONFIG_SERIAL_MSM_HS=y CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set # CONFIG_LEGACY_PTYS is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_HW_RANDOM is not set # CONFIG_R3964 is not set # CONFIG_RAW_DRIVER is not set # CONFIG_TCG_TPM is not set # CONFIG_DCC_TTY is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y # CONFIG_I2C_CHARDEV is not set CONFIG_I2C_HELPER_AUTO=y # # I2C Hardware Bus support # # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_GPIO is not set CONFIG_I2C_MSM=y # CONFIG_I2C_OCORES is not set # CONFIG_I2C_SIMTEC is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_STUB is not set # # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set CONFIG_SENSORS_AKM8976=y CONFIG_SENSORS_PCA963X=y CONFIG_SENSORS_MT9T013=y # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set CONFIG_SPI=y # CONFIG_SPI_DEBUG is not set CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # # CONFIG_SPI_BITBANG is not set # CONFIG_SPI_GPIO is not set # # SPI Protocol Masters # # CONFIG_SPI_SPIDEV is not set # CONFIG_SPI_TLE62X0 is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set # CONFIG_BATTERY_BQ27x00 is not set # CONFIG_HWMON is not set # CONFIG_THERMAL is not set # CONFIG_THERMAL_HWMON is not set # CONFIG_WATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_TWL4030_CORE is not set # CONFIG_MFD_TMIO is not set # CONFIG_PMIC_DA903X is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_PCF50633 is not set # # Multimedia devices # # # Multimedia core support # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_VIDEO_MEDIA is not set # # Multimedia drivers # CONFIG_DAB=y # # Graphics support # # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_TILEBLITTING is not set # # Frame buffer hardware drivers # # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set CONFIG_FB_MSM=y # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE is not set # CONFIG_LOGO is not set # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_DEBUG is not set # CONFIG_HIDRAW is not set # CONFIG_HID_PID is not set # # Special HID drivers # CONFIG_HID_COMPAT=y # CONFIG_HID_APPLE is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y # CONFIG_USB_ARCH_HAS_OHCI is not set # CONFIG_USB_ARCH_HAS_EHCI is not set # CONFIG_USB is not set # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # # Enable Host or Gadget support to see Inventra options # # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may also be needed; # # CONFIG_USB_GADGET is not set # # OTG and related infrastructure # # # USB Function Support # CONFIG_USB_FUNCTION=y CONFIG_USB_FUNCTION_MSM_HSUSB=y # CONFIG_USB_FUNCTION_NULL is not set # CONFIG_USB_FUNCTION_ZERO is not set # CONFIG_USB_FUNCTION_LOOPBACK is not set CONFIG_USB_FUNCTION_ADB=y # CONFIG_USB_FUNCTION_UMS is not set CONFIG_USB_FUNCTION_MASS_STORAGE=y # CONFIG_USB_FUNCTION_DIAG is not set # CONFIG_USB_FUNCTION_ETHER is not set CONFIG_MMC=y # CONFIG_MMC_DEBUG is not set CONFIG_MMC_UNSAFE_RESUME=y CONFIG_MMC_EMBEDDED_SDIO=y CONFIG_MMC_PARANOID_SD_INIT=y # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=y # CONFIG_MMC_BLOCK_BOUNCE is not set CONFIG_MMC_BLOCK_PARANOID_RESUME=y # CONFIG_SDIO_UART is not set # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # # CONFIG_MMC_SDHCI is not set # CONFIG_MMC_SPI is not set CONFIG_MMC_MSM7X00A=y # CONFIG_MMC_MSM7X00A_RESUME_IN_WQ is not set # CONFIG_MEMSTICK is not set # CONFIG_ACCESSIBILITY is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # CONFIG_LEDS_PCA9532 is not set CONFIG_LEDS_GPIO=y CONFIG_LEDS_CPLD=y # CONFIG_LEDS_PCA955X is not set # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set # CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set CONFIG_LEDS_TRIGGER_SLEEP=y CONFIG_SWITCH=y CONFIG_SWITCH_GPIO=y CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # # CONFIG_RTC_INTF_SYSFS is not set # CONFIG_RTC_INTF_PROC is not set # CONFIG_RTC_INTF_DEV is not set CONFIG_RTC_INTF_ALARM=y # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8581 is not set # # SPI RTC drivers # # CONFIG_RTC_DRV_M41T94 is not set # CONFIG_RTC_DRV_DS1305 is not set # CONFIG_RTC_DRV_DS1390 is not set # CONFIG_RTC_DRV_MAX6902 is not set # CONFIG_RTC_DRV_R9701 is not set # CONFIG_RTC_DRV_RS5C348 is not set # CONFIG_RTC_DRV_DS3234 is not set # # Platform RTC drivers # # CONFIG_RTC_DRV_CMOS is not set # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # CONFIG_RTC_DRV_MSM7X00A=y # CONFIG_DMADEVICES is not set # CONFIG_REGULATOR is not set # CONFIG_UIO is not set CONFIG_STAGING=y # CONFIG_STAGING_EXCLUDE_BUILD is not set # CONFIG_MEILHAUS is not set # CONFIG_ECHO is not set # CONFIG_AGNX is not set # CONFIG_COMEDI is not set # # Android # CONFIG_ANDROID=y CONFIG_ANDROID_BINDER_IPC=y CONFIG_ANDROID_LOGGER=y CONFIG_ANDROID_RAM_CONSOLE=y CONFIG_ANDROID_RAM_CONSOLE_ENABLE_VERBOSE=y CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION=y CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_DATA_SIZE=128 CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_ECC_SIZE=16 CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_SYMBOL_SIZE=8 CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_POLYNOMIAL=0x11d # CONFIG_ANDROID_RAM_CONSOLE_EARLY_INIT is not set CONFIG_ANDROID_TIMED_OUTPUT=y CONFIG_ANDROID_TIMED_GPIO=y CONFIG_ANDROID_LOW_MEMORY_KILLER=y # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4_FS is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_FILE_LOCKING=y # CONFIG_XFS_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set # CONFIG_DNOTIFY is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y # CONFIG_MSDOS_FS is not set CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_YAFFS_FS=y CONFIG_YAFFS_YAFFS1=y # CONFIG_YAFFS_9BYTE_TAGS is not set # CONFIG_YAFFS_DOES_ECC is not set CONFIG_YAFFS_YAFFS2=y CONFIG_YAFFS_AUTO_YAFFS2=y # CONFIG_YAFFS_DISABLE_LAZY_LOAD is not set # CONFIG_YAFFS_DISABLE_WIDE_TNODES is not set # CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED is not set CONFIG_YAFFS_SHORT_NAMES_IN_RAM=y # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # CONFIG_DLM is not set # # Kernel hacking # CONFIG_PRINTK_TIME=y CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_SLAB is not set CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y CONFIG_DEBUG_VM=y # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_MEMORY_INIT is not set # CONFIG_DEBUG_LIST is not set CONFIG_DEBUG_SG=y # CONFIG_DEBUG_NOTIFIERS is not set CONFIG_FRAME_POINTER=y CONFIG_BOOT_PRINTK_DELAY=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_CPU_STALL_DETECTOR is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_LATENCYTOP is not set CONFIG_HAVE_FUNCTION_TRACER=y # # Tracers # # CONFIG_FUNCTION_TRACER is not set # CONFIG_IRQSOFF_TRACER is not set # CONFIG_PREEMPT_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_CONTEXT_SWITCH_TRACER is not set # CONFIG_BOOT_TRACER is not set # CONFIG_TRACE_BRANCH_PROFILING is not set # CONFIG_STACK_TRACER is not set # CONFIG_DYNAMIC_PRINTK_DEBUG is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_LL is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITYFS is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y # # Crypto core or helper # # CONFIG_CRYPTO_FIPS is not set CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=y # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_XTS is not set # # Hash modes # # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_XCBC is not set # # Digest # # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_MD4 is not set # CONFIG_CRYPTO_MD5 is not set # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set # CONFIG_CRYPTO_SHA1 is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_ARC4=y # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_DES is not set # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_TWOFISH_COMMON=y # # Compression # # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_LZO is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_HW=y # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_LAST_BIT=y CONFIG_CRC_CCITT=y # CONFIG_CRC16 is not set # CONFIG_CRC_T10DIF is not set # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_REED_SOLOMON=y CONFIG_REED_SOLOMON_ENC8=y CONFIG_REED_SOLOMON_DEC8=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 8:10 ` Pavel Machek 2009-06-11 8:27 ` Brian Swetland @ 2009-06-11 14:33 ` Alex Riesen 2009-06-11 14:51 ` Pavel Machek 1 sibling, 1 reply; 167+ messages in thread From: Alex Riesen @ 2009-06-11 14:33 UTC (permalink / raw) To: Pavel Machek Cc: Brian Swetland, kernel list, linux-arm-kernel, ibm, san, rlove 2009/6/11 Pavel Machek <pavel@ucw.cz>: > > Strange, I attempted downloading this overnight (285MB!) by > > git clone --template=/data/l/clean-cg/ git://android.git.kernel.org/kernel/msm.git > I believe you need --reference, not --template. No wonder you had to download complete repository anew. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 14:33 ` Alex Riesen @ 2009-06-11 14:51 ` Pavel Machek 0 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-11 14:51 UTC (permalink / raw) To: Alex Riesen Cc: Brian Swetland, kernel list, linux-arm-kernel, ibm, san, rlove On Thu 2009-06-11 16:33:36, Alex Riesen wrote: > 2009/6/11 Pavel Machek <pavel@ucw.cz>: > > > > Strange, I attempted downloading this overnight (285MB!) by > > > > git clone --template=/data/l/clean-cg/ git://android.git.kernel.org/kernel/msm.git > > > > I believe you need --reference, not --template. No wonder you had to download > complete repository anew. Oops, right. My ISP hates me... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 10:31 HTC Dream aka. t-mobile g1 support Pavel Machek 2009-06-10 11:13 ` Ian Molton 2009-06-10 17:43 ` Brian Swetland @ 2009-06-10 19:48 ` Russell King - ARM Linux 2009-06-10 20:24 ` Brian Swetland 2009-06-11 7:02 ` David Miller 2 siblings, 2 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-10 19:48 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, linux-arm-kernel, ibm, swetland, san, rlove On Wed, Jun 10, 2009 at 12:31:31PM +0200, Pavel Machek wrote: > Is there patch for Dream support for 2.6.30 somewhere? The best I > could find is linux-msm tree, which is ... quite a big diff against > 2.6.24: In short not as far as I know, and I'm very disappointed with the state of affairs with google. Basically, the situation surrounding msm can be described as severely wanting - bear in mind that it's been over a year since we last heard anything from the msm guys as far as code submissions go. Personally, I think we should delete the entire codeset which was submitted into mainline - it's next to useless and all the time that folk sit on their hands not maintaining it, it's just not worth having it anywhere near mainline. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 19:48 ` Russell King - ARM Linux @ 2009-06-10 20:24 ` Brian Swetland 2009-06-10 20:47 ` MSM6281 support was: " Stefan Schmidt ` (3 more replies) 2009-06-11 7:02 ` David Miller 1 sibling, 4 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-10 20:24 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, kernel list, linux-arm-kernel, san, rlove On Wed, Jun 10, 2009 at 12:48 PM, Russell King - ARM Linux<linux@arm.linux.org.uk> wrote: > On Wed, Jun 10, 2009 at 12:31:31PM +0200, Pavel Machek wrote: >> Is there patch for Dream support for 2.6.30 somewhere? The best I >> could find is linux-msm tree, which is ... quite a big diff against >> 2.6.24: > > In short not as far as I know, and I'm very disappointed with the state > of affairs with google. > > Basically, the situation surrounding msm can be described as severely > wanting - bear in mind that it's been over a year since we last heard > anything from the msm guys as far as code submissions go. > > Personally, I think we should delete the entire codeset which was > submitted into mainline - it's next to useless and all the time that > folk sit on their hands not maintaining it, it's just not worth having > it anywhere near mainline. 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. 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. We've definitely dropped the ball as far as interacting with folks on the lakml on this, but I do wonder if there's a better option than "delete it all." 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... Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-10 20:24 ` Brian Swetland @ 2009-06-10 20:47 ` Stefan Schmidt 2009-06-10 21:08 ` Brian Swetland 2009-06-10 21:05 ` Daniel Walker ` (2 subsequent siblings) 3 siblings, 1 reply; 167+ messages in thread From: Stefan Schmidt @ 2009-06-10 20:47 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, Pavel Machek, kernel list, linux-arm-kernel, san, rlove Hello. On Wed, 2009-06-10 at 13:24, Brian Swetland wrote: > > 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. A bit offtopic here. (subject change). Is it expected that the android kernel team will also work on systems that use the MSM6K modems with different SoC's? I have soem systems here that use an msm6281 on a dual port ram chip with non msm SoC's. I wonder how difficult it would be to adaept the existing msm smd driver to such a setup. regards Stefan Schmidt ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-10 20:47 ` MSM6281 support was: " Stefan Schmidt @ 2009-06-10 21:08 ` Brian Swetland 2009-06-10 21:28 ` Stefan Schmidt 2009-06-10 21:28 ` Marek Vasut 0 siblings, 2 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-10 21:08 UTC (permalink / raw) To: Stefan Schmidt Cc: Russell King - ARM Linux, Pavel Machek, kernel list, linux-arm-kernel, san, rlove On Wed, Jun 10, 2009 at 1:47 PM, Stefan Schmidt<stefan@datenfreihafen.org> wrote: > Hello. > > On Wed, 2009-06-10 at 13:24, Brian Swetland wrote: >> >> 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. > > A bit offtopic here. (subject change). Is it expected that the android kernel > team will also work on systems that use the MSM6K modems with different SoC's? I > have soem systems here that use an msm6281 on a dual port ram chip with non msm > SoC's. I wonder how difficult it would be to adaept the existing msm smd driver > to such a setup. We only have documentation, support, and permission to do work on 7k and 8k family devices at this point. I don't know anything about the 6k family, and how similar (or not) the shared memory interface would be, so unfortunately I can't provide much help there. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-10 21:08 ` Brian Swetland @ 2009-06-10 21:28 ` Stefan Schmidt 2009-06-10 21:28 ` Marek Vasut 1 sibling, 0 replies; 167+ messages in thread From: Stefan Schmidt @ 2009-06-10 21:28 UTC (permalink / raw) To: Brian Swetland Cc: Stefan Schmidt, Russell King - ARM Linux, Pavel Machek, kernel list, linux-arm-kernel, san, rlove Hello. On Wed, 2009-06-10 at 14:08, Brian Swetland wrote: > On Wed, Jun 10, 2009 at 1:47 PM, Stefan > Schmidt<stefan@datenfreihafen.org> wrote: > > > > On Wed, 2009-06-10 at 13:24, Brian Swetland wrote: > >> > >> 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. > > > > A bit offtopic here. (subject change). Is it expected that the android kernel > > team will also work on systems that use the MSM6K modems with different SoC's? I > > have soem systems here that use an msm6281 on a dual port ram chip with non msm > > SoC's. I wonder how difficult it would be to adaept the existing msm smd driver > > to such a setup. > > We only have documentation, support, and permission to do work on 7k > and 8k family devices at this point. I don't know anything about the > 6k family, and how similar (or not) the shared memory interface would > be, so unfortunately I can't provide much help there. To bad. Thanks for the answer. regards Stefan Schmidt ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-10 21:08 ` Brian Swetland 2009-06-10 21:28 ` Stefan Schmidt @ 2009-06-10 21:28 ` Marek Vasut 2009-06-10 21:33 ` Pavel Machek 1 sibling, 1 reply; 167+ messages in thread From: Marek Vasut @ 2009-06-10 21:28 UTC (permalink / raw) To: linux-arm-kernel Cc: Brian Swetland, Stefan Schmidt, Russell King - ARM Linux, Pavel Machek, kernel list, san, rlove On Wednesday 10 of June 2009 23:08:36 Brian Swetland wrote: > On Wed, Jun 10, 2009 at 1:47 PM, Stefan > > Schmidt<stefan@datenfreihafen.org> wrote: > > Hello. > > > > On Wed, 2009-06-10 at 13:24, Brian Swetland wrote: > >> 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. > > > > A bit offtopic here. (subject change). Is it expected that the android > > kernel team will also work on systems that use the MSM6K modems with > > different SoC's? I have soem systems here that use an msm6281 on a dual > > port ram chip with non msm SoC's. I wonder how difficult it would be to > > adaept the existing msm smd driver to such a setup. > > We only have documentation, support, and permission to do work on 7k > and 8k family devices at this point. I don't know anything about the > 6k family, and how similar (or not) the shared memory interface would > be, so unfortunately I can't provide much help there. Palm Pre apparently uses MSM68xx as a baseband chip, otherwise is omap3 based. The device is out, selling, but I haven't seen any kernel patches from them yet. I hope they release them in a few weeks (even though they should have been out already). > > Brian > > ------------------------------------------------------------------- > List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel > FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php > Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-10 21:28 ` Marek Vasut @ 2009-06-10 21:33 ` Pavel Machek 2009-06-10 22:10 ` Stefan Schmidt 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-10 21:33 UTC (permalink / raw) To: Marek Vasut Cc: linux-arm-kernel, Brian Swetland, Stefan Schmidt, Russell King - ARM Linux, kernel list, san, rlove On Wed 2009-06-10 23:28:39, Marek Vasut wrote: > On Wednesday 10 of June 2009 23:08:36 Brian Swetland wrote: > > On Wed, Jun 10, 2009 at 1:47 PM, Stefan > > > > Schmidt<stefan@datenfreihafen.org> wrote: > > > Hello. > > > > > > On Wed, 2009-06-10 at 13:24, Brian Swetland wrote: > > >> 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. > > > > > > A bit offtopic here. (subject change). Is it expected that the android > > > kernel team will also work on systems that use the MSM6K modems with > > > different SoC's? I have soem systems here that use an msm6281 on a dual > > > port ram chip with non msm SoC's. I wonder how difficult it would be to > > > adaept the existing msm smd driver to such a setup. > > > > We only have documentation, support, and permission to do work on 7k > > and 8k family devices at this point. I don't know anything about the > > 6k family, and how similar (or not) the shared memory interface would > > be, so unfortunately I can't provide much help there. > > Palm Pre apparently uses MSM68xx as a baseband chip, otherwise is omap3 based. > The device is out, selling, but I haven't seen any kernel patches from them > yet. I hope they release them in a few weeks (even though they should have > been out already). If you can get your hands on Palm Pre, it should come with GPL-required sources or offer for source code... if it does not, talk to Harald Welte (gpl-violations.org).... (If you _do_ get your hands on Palm Pre, tell me, I'd like to see the device :-), can show you some androids/openmokos :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-10 21:33 ` Pavel Machek @ 2009-06-10 22:10 ` Stefan Schmidt 2009-06-10 22:19 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: Stefan Schmidt @ 2009-06-10 22:10 UTC (permalink / raw) To: Pavel Machek Cc: Marek Vasut, linux-arm-kernel, Brian Swetland, Stefan Schmidt, Russell King - ARM Linux, kernel list, san, rlove Hello. On Wed, 2009-06-10 at 23:33, Pavel Machek wrote: > On Wed 2009-06-10 23:28:39, Marek Vasut wrote: > > On Wednesday 10 of June 2009 23:08:36 Brian Swetland wrote: > > > On Wed, Jun 10, 2009 at 1:47 PM, Stefan > > > > > > Schmidt<stefan@datenfreihafen.org> wrote: > > > > Hello. > > > > > > > > On Wed, 2009-06-10 at 13:24, Brian Swetland wrote: > > > >> 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. > > > > > > > > A bit offtopic here. (subject change). Is it expected that the android > > > > kernel team will also work on systems that use the MSM6K modems with > > > > different SoC's? I have soem systems here that use an msm6281 on a dual > > > > port ram chip with non msm SoC's. I wonder how difficult it would be to > > > > adaept the existing msm smd driver to such a setup. > > > > > > We only have documentation, support, and permission to do work on 7k > > > and 8k family devices at this point. I don't know anything about the > > > 6k family, and how similar (or not) the shared memory interface would > > > be, so unfortunately I can't provide much help there. > > > > Palm Pre apparently uses MSM68xx as a baseband chip, otherwise is omap3 based. > > The device is out, selling, but I haven't seen any kernel patches from them > > yet. I hope they release them in a few weeks (even though they should have > > been out already). > > If you can get your hands on Palm Pre, it should come with > GPL-required sources or offer for source code... if it does not, talk > to Harald Welte (gpl-violations.org).... They have the licence inside and offer source on request on the letter. I wrote them a mail some hours ago and they state that all source will be on http://opensource.palm.com/ within two weeks. regards Stefan Schmidt ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-10 22:10 ` Stefan Schmidt @ 2009-06-10 22:19 ` Pavel Machek 2009-06-11 4:02 ` Valdis.Kletnieks 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-10 22:19 UTC (permalink / raw) To: Stefan Schmidt, laforge Cc: Marek Vasut, linux-arm-kernel, Brian Swetland, Russell King - ARM Linux, kernel list, san, rlove Hi! Ok, Harald asked for Palm Pre source code in blog entry, so it is fair to cc him :-). > > > Palm Pre apparently uses MSM68xx as a baseband chip, otherwise is omap3 based. > > > The device is out, selling, but I haven't seen any kernel patches from them > > > yet. I hope they release them in a few weeks (even though they should have > > > been out already). > > > > If you can get your hands on Palm Pre, it should come with > > GPL-required sources or offer for source code... if it does not, talk > > to Harald Welte (gpl-violations.org).... > > They have the licence inside and offer source on request on the letter. I wrote > them a mail some hours ago and they state that all source will be on > http://opensource.palm.com/ within two weeks. Ugh, nice approach to GPL :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-10 22:19 ` Pavel Machek @ 2009-06-11 4:02 ` Valdis.Kletnieks 2009-06-11 7:50 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: Valdis.Kletnieks @ 2009-06-11 4:02 UTC (permalink / raw) To: Pavel Machek Cc: Stefan Schmidt, laforge, Marek Vasut, linux-arm-kernel, Brian Swetland, Russell King - ARM Linux, kernel list, san, rlove [-- Attachment #1: Type: text/plain, Size: 506 bytes --] On Thu, 11 Jun 2009 00:19:40 +0200, Pavel Machek said: > > They have the licence inside and offer source on request on the letter. I wrote > > them a mail some hours ago and they state that all source will be on > > http://opensource.palm.com/ within two weeks. > > Ugh, nice approach to GPL :-(. On the other hand, it's far from the worst GPL abuse we've seen. It sounds like they're at least *trying* to DTRT, and they're at least complying with the letter of the license, and *mostly* the spirit... [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support 2009-06-11 4:02 ` Valdis.Kletnieks @ 2009-06-11 7:50 ` Pavel Machek 0 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-11 7:50 UTC (permalink / raw) To: Valdis.Kletnieks Cc: Stefan Schmidt, laforge, Marek Vasut, linux-arm-kernel, Brian Swetland, Russell King - ARM Linux, kernel list, san, rlove On Thu 2009-06-11 00:02:07, Valdis.Kletnieks@vt.edu wrote: > On Thu, 11 Jun 2009 00:19:40 +0200, Pavel Machek said: > > > They have the licence inside and offer source on request on the letter. I wrote > > > them a mail some hours ago and they state that all source will be on > > > http://opensource.palm.com/ within two weeks. > > > > Ugh, nice approach to GPL :-(. > > On the other hand, it's far from the worst GPL abuse we've seen. It sounds > like they're at least *trying* to DTRT, and they're at least complying with the > letter of the license, and *mostly* the spirit... "Far from the worst" is exact. Yes, it could be worse. Question is how they'll respond to those letters. I suspect they will just wait 14 days and then send CD... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 20:24 ` Brian Swetland 2009-06-10 20:47 ` MSM6281 support was: " Stefan Schmidt @ 2009-06-10 21:05 ` Daniel Walker 2009-06-10 21:37 ` Pavel Machek 2009-06-11 9:32 ` HTC Dream aka. t-mobile g1 support Mark Brown 3 siblings, 0 replies; 167+ messages in thread From: Daniel Walker @ 2009-06-10 21:05 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, Pavel Machek, kernel list, linux-arm-kernel, san, rlove On Wed, 2009-06-10 at 13:24 -0700, Brian Swetland wrote: > On Wed, Jun 10, 2009 at 12:48 PM, Russell King - ARM > Linux<linux@arm.linux.org.uk> wrote: > > On Wed, Jun 10, 2009 at 12:31:31PM +0200, Pavel Machek wrote: > >> Is there patch for Dream support for 2.6.30 somewhere? The best I > >> could find is linux-msm tree, which is ... quite a big diff against > >> 2.6.24: > > > > In short not as far as I know, and I'm very disappointed with the state > > of affairs with google. > > > > Basically, the situation surrounding msm can be described as severely > > wanting - bear in mind that it's been over a year since we last heard > > anything from the msm guys as far as code submissions go. > > > > Personally, I think we should delete the entire codeset which was > > submitted into mainline - it's next to useless and all the time that > > folk sit on their hands not maintaining it, it's just not worth having > > it anywhere near mainline. > > 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 assume you guys would accept community submitted clean up patches right? Is there someone maintaining the MSM changes, you maybe? > 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. Typically you send stuff to LKML (or other mailing list) for review, it's not like only one person would be reviewing the code. Daniel ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 20:24 ` Brian Swetland 2009-06-10 20:47 ` MSM6281 support was: " Stefan Schmidt 2009-06-10 21:05 ` Daniel Walker @ 2009-06-10 21:37 ` Pavel Machek 2009-06-10 21:55 ` Brian Swetland 2009-06-11 9:32 ` HTC Dream aka. t-mobile g1 support Mark Brown 3 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-10 21:37 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove Hi! > > On Wed, Jun 10, 2009 at 12:31:31PM +0200, Pavel Machek wrote: > >> Is there patch for Dream support for 2.6.30 somewhere? The best I > >> could find is linux-msm tree, which is ... quite a big diff against > >> 2.6.24: > > > > In short not as far as I know, and I'm very disappointed with the state > > of affairs with google. > > > > Basically, the situation surrounding msm can be described as severely > > wanting - bear in mind that it's been over a year since we last heard > > anything from the msm guys as far as code submissions go. > > > > Personally, I think we should delete the entire codeset which was > > submitted into mainline - it's next to useless and all the time that > > folk sit on their hands not maintaining it, it's just not worth having > > it anywhere near mainline. > > 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. > 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.] Actually, mailing patches so that people do not have to do git pull + diff is very good zeroth step :-). > 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... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 21:37 ` Pavel Machek @ 2009-06-10 21:55 ` Brian Swetland 2009-06-11 8:25 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: Brian Swetland @ 2009-06-10 21:55 UTC (permalink / raw) To: Pavel Machek Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove On Wed, Jun 10, 2009 at 2:37 PM, Pavel Machek<pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 21:55 ` Brian Swetland @ 2009-06-11 8:25 ` Pavel Machek 2009-06-11 8:48 ` Brian Swetland 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-11 8:25 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Wed 2009-06-10 14:55:52, Brian Swetland wrote: > On Wed, Jun 10, 2009 at 2:37 PM, Pavel Machek<pavel@ucw.cz> 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. Merging drivers is (/should be) easy. Merging core features take a while. > >> 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. drivers/staging already contains stuff such a filesystems. Putting arch-specific drivers there should be okay. > 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? ...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. > 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. > > 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. Yeah, you need to repeat it like each two weeks to get attention. > >> 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). Good. > 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. Yes, please. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 8:25 ` Pavel Machek @ 2009-06-11 8:48 ` Brian Swetland 2009-06-12 15:05 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: Brian Swetland @ 2009-06-11 8:48 UTC (permalink / raw) To: Pavel Machek Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH 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 ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 8:48 ` Brian Swetland @ 2009-06-12 15:05 ` Pavel Machek 2009-06-12 15:48 ` David Brown ` (3 more replies) 0 siblings, 4 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-12 15:05 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH 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 ^ permalink raw reply related [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 15:05 ` Pavel Machek @ 2009-06-12 15:48 ` David Brown 2009-06-12 16:00 ` David Brown ` (2 subsequent siblings) 3 siblings, 0 replies; 167+ messages in thread From: David Brown @ 2009-06-12 15:48 UTC (permalink / raw) To: Pavel Machek Cc: Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Fri, Jun 12, 2009 at 05:05:04PM +0200, Pavel Machek wrote: >+Board code names >+---------------- >+ >+board-halibut is a qualcomm reference design. board-sapphire is HTC >+Magic. board-trout is HTC Dream/G1/ADP1. Specifically, 'board-halibut' is one particular Qualcomm reference design, currently one of seven. Support for these devices is in our reference kernel at: https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=summary in the android-msm-2.6.29 branch, which is about 213 commits divergent from Google's tree, posted earlier. We've been trying to work to get our commits to be closer to being appropriate for inclusion in the mainstream kernel. Sadly, most of out work so far ended up being squashed into a single "Initial contribution" commit. It's also a bit unfortunate that our primary development happens on development boards that aren't available to the general public. From what I read here, it seems that mainline change to support the HTC 7201A-based devices is probably the most useful starting point. I'm hoping soon to be able to be involved more directly with ARM kernel development rather than just in an after-the-fact manner. >+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 You should also be able to do: ./fastboot boot boot.img but this is probably only useful if you use the rest of the Android build system, since it will assemble boot.img from the kernel image and the ramdisk. David Brown davidb@quicinc.com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 15:05 ` Pavel Machek 2009-06-12 15:48 ` David Brown @ 2009-06-12 16:00 ` David Brown 2009-06-12 16:43 ` Stefan Schmidt 2009-06-12 20:47 ` HTC Dream compile fixes (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek 2009-06-12 20:50 ` HTC Dream aka. t-mobile g1 support Brian Swetland 3 siblings, 1 reply; 167+ messages in thread From: David Brown @ 2009-06-12 16:00 UTC (permalink / raw) To: Pavel Machek Cc: Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Fri, Jun 12, 2009 at 05:05:04PM +0200, Pavel Machek wrote: >+Board code names >+---------------- >+ >+board-halibut is a qualcomm reference design. board-sapphire is HTC >+Magic. board-trout is HTC Dream/G1/ADP1. Specifically, 'board-halibut' is one particular Qualcomm reference design, currently one of seven. Support for these devices is in our reference kernel at: https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=summary in the android-msm-2.6.29 branch, which is about 213 commits divergent from Google's tree, posted earlier. We've been trying to work to get our commits to be closer to being appropriate for inclusion in the mainstream kernel. Sadly, most of out work so far ended up being squashed into a single "Initial contribution" commit. It's also a bit unfortunate that our primary development happens on development boards that aren't available to the general public. From what I read here, it seems that mainline change to support the HTC 7201A-based devices is probably the most useful starting point. I'm hoping soon to be able to be involved more directly with ARM kernel development rather than just in an after-the-fact manner. >+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 You should also be able to do: ./fastboot boot boot.img but this is probably only useful if you use the rest of the Android build system, since it will assemble boot.img from the kernel image and the ramdisk. David Brown davidb@quicinc.com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 16:00 ` David Brown @ 2009-06-12 16:43 ` Stefan Schmidt 2009-06-12 16:55 ` davidb 0 siblings, 1 reply; 167+ messages in thread From: Stefan Schmidt @ 2009-06-12 16:43 UTC (permalink / raw) To: David Brown Cc: Pavel Machek, Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH Hello. On Fri, 2009-06-12 at 09:00, David Brown wrote: > On Fri, Jun 12, 2009 at 05:05:04PM +0200, Pavel Machek wrote: > > Support for these devices is in our reference kernel at: > > https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=summary > > in the android-msm-2.6.29 branch, which is about 213 commits divergent > from Google's tree, posted earlier. We've been trying to work to get > our commits to be closer to being appropriate for inclusion in the > mainstream kernel. Sadly, most of out work so far ended up being > squashed into a single "Initial contribution" commit. > > It's also a bit unfortunate that our primary development happens on > development boards that aren't available to the general public. That and that one have to sign a contributor agreement just to register on your your site and get in touch. While your kernel tree is public that looks a lot like a closed development process to me. Any plan to make this more transparent? regards Stefan Schmidt ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 16:43 ` Stefan Schmidt @ 2009-06-12 16:55 ` davidb 2009-06-12 17:35 ` Stefan Schmidt 0 siblings, 1 reply; 167+ messages in thread From: davidb @ 2009-06-12 16:55 UTC (permalink / raw) To: Stefan Schmidt Cc: Pavel Machek, Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Fri, Jun 12, 2009 at 09:43:25AM -0700, Stefan Schmidt wrote: > Hello. > > On Fri, 2009-06-12 at 09:00, David Brown wrote: > > On Fri, Jun 12, 2009 at 05:05:04PM +0200, Pavel Machek wrote: > > > > Support for these devices is in our reference kernel at: > > > > https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=summary > > > > It's also a bit unfortunate that our primary development happens on > > development boards that aren't available to the general public. > > That and that one have to sign a contributor agreement just to register on your > your site and get in touch. While your kernel tree is public that looks a lot > like a closed development process to me. > > Any plan to make this more transparent? We're definitely working on it. I think the intent is to have a Gerrit instance to accept contributions. I'll have to look into whether this can be done without signing the agreement. Right now, I can't even contribute anything, so there are a lot of issues to work out. David ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 16:55 ` davidb @ 2009-06-12 17:35 ` Stefan Schmidt 0 siblings, 0 replies; 167+ messages in thread From: Stefan Schmidt @ 2009-06-12 17:35 UTC (permalink / raw) To: Stefan Schmidt, Pavel Machek, Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH Hello. On Fri, 2009-06-12 at 09:55, davidb@quicinc.com wrote: > On Fri, Jun 12, 2009 at 09:43:25AM -0700, Stefan Schmidt wrote: > > > > On Fri, 2009-06-12 at 09:00, David Brown wrote: > > > On Fri, Jun 12, 2009 at 05:05:04PM +0200, Pavel Machek wrote: > > > > > > Support for these devices is in our reference kernel at: > > > > > > https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=summary > > > > > > It's also a bit unfortunate that our primary development happens on > > > development boards that aren't available to the general public. > > > > That and that one have to sign a contributor agreement just to register on your > > your site and get in touch. While your kernel tree is public that looks a lot > > like a closed development process to me. > > > > Any plan to make this more transparent? > > We're definitely working on it. Good. > I think the intent is to have a > Gerrit instance to accept contributions. I'll have to look into > whether this can be done without signing the agreement. Right > now, I can't even contribute anything, so there are a lot of > issues to work out. Gerrit is the Android review system? I'm only interested into the kernel and especially running a mainline kernel on different devices. Anyway, a public review process and some more informations on what you are working and how you would like to bring it mainline would help here. regards Stefan Schmidt ^ permalink raw reply [flat|nested] 167+ messages in thread
* HTC Dream compile fixes (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-12 15:05 ` Pavel Machek 2009-06-12 15:48 ` David Brown 2009-06-12 16:00 ` David Brown @ 2009-06-12 20:47 ` Pavel Machek 2009-06-12 20:50 ` HTC Dream aka. t-mobile g1 support Brian Swetland 3 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-12 20:47 UTC (permalink / raw) To: Brian Swetland; +Cc: kernel list, linux-arm-kernel, san, rlove, Greg KH Fix compilation of pwrsink with CONFIG_WAKELOCK disabled. Signed-off-by: Pavel Machek <pavel@ucw.cz> diff --git a/arch/arm/mach-msm/htc_pwrsink.c b/arch/arm/mach-msm/htc_pwrsink.c index 3105a7c..3d3c55c 100644 --- a/arch/arm/mach-msm/htc_pwrsink.c +++ b/arch/arm/mach-msm/htc_pwrsink.c @@ -229,11 +229,13 @@ void htc_pwrsink_resume_late(struct early_suspend *h) htc_pwrsink_set(PWRSINK_SYSTEM_LOAD, 38); } +#ifdef CONFIG_WAKELOCK struct early_suspend htc_pwrsink_early_suspend = { .level = EARLY_SUSPEND_LEVEL_DISABLE_FB + 1, .suspend = htc_pwrsink_suspend_early, .resume = htc_pwrsink_resume_late, }; +#endif static int __init htc_pwrsink_probe(struct platform_device *pdev) { @@ -252,10 +254,12 @@ static int __init htc_pwrsink_probe(struct platform_device *pdev) initialized = 1; +#ifdef CONFIG_WAKELOCK if (pdata->suspend_early) htc_pwrsink_early_suspend.suspend = pdata->suspend_early; if (pdata->resume_late) htc_pwrsink_early_suspend.resume = pdata->resume_late; +#endif register_early_suspend(&htc_pwrsink_early_suspend); return 0; -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply related [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 15:05 ` Pavel Machek ` (2 preceding siblings ...) 2009-06-12 20:47 ` HTC Dream compile fixes (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek @ 2009-06-12 20:50 ` Brian Swetland 2009-06-12 22:02 ` Ian Molton ` (2 more replies) 3 siblings, 3 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-12 20:50 UTC (permalink / raw) To: Pavel Machek Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Fri, Jun 12, 2009 at 8:05 AM, Pavel Machek<pavel@ucw.cz> wrote: >> On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 20:50 ` HTC Dream aka. t-mobile g1 support Brian Swetland @ 2009-06-12 22:02 ` Ian Molton 2009-06-12 22:27 ` Brian Swetland 2009-06-12 22:04 ` Pavel Machek 2009-06-15 17:01 ` Pavel Machek 2 siblings, 1 reply; 167+ messages in thread From: Ian Molton @ 2009-06-12 22:02 UTC (permalink / raw) To: Brian Swetland Cc: Pavel Machek, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH Brian Swetland wrote: > 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. Is there a reason that this couldnt be done in userspace? ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 22:02 ` Ian Molton @ 2009-06-12 22:27 ` Brian Swetland 2009-06-12 22:31 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: Brian Swetland @ 2009-06-12 22:27 UTC (permalink / raw) To: Ian Molton Cc: Pavel Machek, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Fri, Jun 12, 2009 at 3:02 PM, Ian Molton<ian@mnementh.co.uk> wrote: > Brian Swetland wrote: > >> 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. > > Is there a reason that this couldnt be done in userspace? It'd be a lot more overhead -- in some cases it's updated with relatively fine granularity (wifi driver changing state, backlight changing, etc), and on the kernel side it's just updating a shared memory location with the current estimate. Userspace doesn't necessarily have the visibility into driver state to update it accurately, and punching that information down to userspace and then having userspace feed it back up to the kernel seems like more overhead and code to maintain to me. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 22:27 ` Brian Swetland @ 2009-06-12 22:31 ` Pavel Machek 2009-06-12 22:36 ` Brian Swetland 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-12 22:31 UTC (permalink / raw) To: Brian Swetland Cc: Ian Molton, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Fri 2009-06-12 15:27:01, Brian Swetland wrote: > On Fri, Jun 12, 2009 at 3:02 PM, Ian Molton<ian@mnementh.co.uk> wrote: > > Brian Swetland wrote: > > > >> 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. > > > > Is there a reason that this couldnt be done in userspace? > > It'd be a lot more overhead -- in some cases it's updated with > relatively fine granularity (wifi driver changing state, backlight > changing, etc), and on the kernel side it's just updating a shared > memory location with the current estimate. Userspace doesn't > necessarily have the visibility into driver state to update it > accurately, and punching that information down to userspace and then > having userspace feed it back up to the kernel seems like more > overhead and code to maintain to me. Actually I agree with Brian here, this is better done at kernel level. OTOH, at least initially, it does not need to be done at all. It will make battery readings less reliable but hey... the battery meter does not work reliably anyway and estimating capacity left from voltage acceptably on other platforms... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 22:31 ` Pavel Machek @ 2009-06-12 22:36 ` Brian Swetland 2009-06-15 17:06 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: Brian Swetland @ 2009-06-12 22:36 UTC (permalink / raw) To: Pavel Machek Cc: Ian Molton, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Fri, Jun 12, 2009 at 3:31 PM, Pavel Machek<pavel@ucw.cz> wrote: >> > Is there a reason that this couldnt be done in userspace? >> >> It'd be a lot more overhead -- in some cases it's updated with >> relatively fine granularity (wifi driver changing state, backlight >> changing, etc), and on the kernel side it's just updating a shared >> memory location with the current estimate. Userspace doesn't >> necessarily have the visibility into driver state to update it >> accurately, and punching that information down to userspace and then >> having userspace feed it back up to the kernel seems like more >> overhead and code to maintain to me. > > Actually I agree with Brian here, this is better done at kernel level. > > OTOH, at least initially, it does not need to be done at all. It will > make battery readings less reliable but hey... the battery meter does > not work reliably anyway and estimating capacity left from voltage > acceptably on other platforms... I'd agree. This stuff can wait until the core support is solid. I'd fight harder for conditional support for wakelocks since that has a much bigger impact on battery life (being able to know when it's safe to power collapse in idle, etc), whereas this just improves the accuracy of the battery gauging. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 22:36 ` Brian Swetland @ 2009-06-15 17:06 ` Pavel Machek 0 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-15 17:06 UTC (permalink / raw) To: Brian Swetland Cc: Ian Molton, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH > > Actually I agree with Brian here, this is better done at kernel level. > > > > OTOH, at least initially, it does not need to be done at all. It will > > make battery readings less reliable but hey... the battery meter does > > not work reliably anyway and estimating capacity left from voltage > > acceptably on other platforms... > > I'd agree. This stuff can wait until the core support is solid. I'd > fight harder for conditional support for wakelocks since that has a > much bigger impact on battery life (being able to know when it's safe > to power collapse in idle, etc), whereas this just improves the > accuracy of the battery gauging. Yes, wakelocks are more important than battery gauging... but they need core support :-(; and they can wait, too. Getting serial support & board-dream upstream are very good first steps (thanks!). I'm currently trying to get 2.6.30 + your series of 3 + framebuffer changes to boot. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 20:50 ` HTC Dream aka. t-mobile g1 support Brian Swetland 2009-06-12 22:02 ` Ian Molton @ 2009-06-12 22:04 ` Pavel Machek 2009-06-15 17:01 ` Pavel Machek 2 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-12 22:04 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH Hi! > >> > 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). Uch, ouch. hw3d.c is certainly not required for boot. htc_* probably can live elsewhere. Actually, htc_acoustic... that's some kind of microphone mixer. That should reside in sound/ and use normal ALSA interface...? > >> 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. Some qdsp5 stuff is example of similar code, but your stuff is actually quite okay. Its just... there's quite a lot of it. I was not trying to say that your code is horrible. I was trying to point out that drivers/staging accepts even horrible code, and that it is "submit first, checkpatch next". > >> 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? timed_output is "interesting", but probably acceptable. openmoko uses /sys/class/leds/gta01\:vibrator/brightness for vibrator control; that has advantage of having access to trigger infrastructure. lcd-backlight should be in /sys/class/backlight, not /sys/class/leds. class/switch is "interesting". I'd expect keyboard open/closed, but instead do sd door. Why is mass storage there? > > 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. Thanks! > > 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. Ok. It would be nice to provide description how the system looks like somewhere in the docs. > >> > 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. Ok, plus a keyboard would be cool :-). Fortunately, those are the components that seem to be reasonably simple. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 20:50 ` HTC Dream aka. t-mobile g1 support Brian Swetland 2009-06-12 22:02 ` Ian Molton 2009-06-12 22:04 ` Pavel Machek @ 2009-06-15 17:01 ` Pavel Machek 2009-06-15 17:10 ` Bill Gatliff 2009-06-15 18:32 ` Brian Swetland 2 siblings, 2 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-15 17:01 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH Browsing -msm sources... { .name = "flash", .gpio = TROUT_GPIO_FLASH_EN, .max_timeout = 400, }, ...in trout... Does dream really support flash? { .name = "spotlight", .gpio = TROUT_GPIO_SPOTLIGHT_EN, }, ...what is spotlight? I wish dream had some way to produce light in dark... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 17:01 ` Pavel Machek @ 2009-06-15 17:10 ` Bill Gatliff 2009-06-15 18:32 ` Brian Swetland 1 sibling, 0 replies; 167+ messages in thread From: Bill Gatliff @ 2009-06-15 17:10 UTC (permalink / raw) To: Pavel Machek Cc: Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH Pavel Machek wrote: > ...in trout... Does dream really support flash? > > { > .name = "spotlight", > .gpio = TROUT_GPIO_SPOTLIGHT_EN, > }, > > ...what is spotlight? I wish dream had some way to produce light in > dark... > > I can't sleep, much less dream, if it's too bright. :) b.g. -- Bill Gatliff bgat@billgatliff.com ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 17:01 ` Pavel Machek 2009-06-15 17:10 ` Bill Gatliff @ 2009-06-15 18:32 ` Brian Swetland 2009-06-17 9:11 ` Pavel Machek 1 sibling, 1 reply; 167+ messages in thread From: Brian Swetland @ 2009-06-15 18:32 UTC (permalink / raw) To: Pavel Machek Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Mon, Jun 15, 2009 at 10:01 AM, Pavel Machek<pavel@ucw.cz> wrote: > > Browsing -msm sources... > > { > .name = "flash", > .gpio = TROUT_GPIO_FLASH_EN, > .max_timeout = 400, > }, > > > ...in trout... Does dream really support flash? > > { > .name = "spotlight", > .gpio = TROUT_GPIO_SPOTLIGHT_EN, > }, > > ...what is spotlight? I wish dream had some way to produce light in > dark... Earlier revisions had an LED flash for the camera. This didn't make it into the final hardware. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 18:32 ` Brian Swetland @ 2009-06-17 9:11 ` Pavel Machek 2009-06-17 9:40 ` Brian Swetland 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-17 9:11 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH > > ...in trout... Does dream really support flash? > > > > { > > .name = "spotlight", > > .gpio = TROUT_GPIO_SPOTLIGHT_EN, > > }, > > > > ...what is spotlight? I wish dream had some way to produce light in > > dark... > > Earlier revisions had an LED flash for the camera. This didn't make > it into the final hardware. Ok, and what is the spotlight? Did flash have two modes? One more question... do you have keymap.map to make console usable? By default, keyboard lacks any special characters... --- Flash is not wired on Dreams users actually have, document that. Document purpose of pwrsink.c. Signed-off-by: Pavel Machek <pavel@ucw.cz> diff --git a/arch/arm/mach-msm/board-trout.c b/arch/arm/mach-msm/board-trout.c index c1a7431..a65cce5 100644 --- a/arch/arm/mach-msm/board-trout.c +++ b/arch/arm/mach-msm/board-trout.c @@ -304,6 +304,8 @@ static struct timed_gpio timed_gpios[] = { .max_timeout = 15000, }, { + /* Prototype versions of HTC dream had LED flash; + released hw lacks it. */ .name = "flash", .gpio = TROUT_GPIO_FLASH_EN, .max_timeout = 400, diff --git a/arch/arm/mach-msm/htc_pwrsink.c b/arch/arm/mach-msm/htc_pwrsink.c index 3d3c55c..b74f776 100644 --- a/arch/arm/mach-msm/htc_pwrsink.c +++ b/arch/arm/mach-msm/htc_pwrsink.c @@ -15,6 +15,10 @@ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * + * Some of HTC devices don't have a battery gauge IC and estimate + * current drain based on hints provided to the baseband from the apps + * processor. + * */ #include <linux/platform_device.h> -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply related [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-17 9:11 ` Pavel Machek @ 2009-06-17 9:40 ` Brian Swetland 2009-06-17 17:16 ` HTC Dream keymap (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek ` (2 more replies) 0 siblings, 3 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-17 9:40 UTC (permalink / raw) To: Pavel Machek Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH, Arve Hjønnevåg On Wed, Jun 17, 2009 at 2:11 AM, Pavel Machek<pavel@ucw.cz> wrote: >> > ...in trout... Does dream really support flash? >> > >> > { >> > .name = "spotlight", >> > .gpio = TROUT_GPIO_SPOTLIGHT_EN, >> > }, >> > >> > ...what is spotlight? I wish dream had some way to produce light in >> > dark... >> >> Earlier revisions had an LED flash for the camera. This didn't make >> it into the final hardware. > > Ok, and what is the spotlight? Did flash have two modes? iirc "spotlight" was the anti-redeye pre-illumination mode. > One more question... do you have keymap.map to make console usable? By > default, keyboard lacks any special characters... I don't think we ever put together a full keymap for the console, since we don't use it much. Arve might have done something with setkey once upon a time. > Flash is not wired on Dreams users actually have, document that. We should probably just remove the mapping for it entirely. The EVT hardware that had flash capability is long-since obsolete and never existed in very high quantities. I'll take a look through the board files to see what else we can lose -- I think there may be keymaps for some early versions of development hardware, etc, that also could go. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* HTC Dream keymap (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-17 9:40 ` Brian Swetland @ 2009-06-17 17:16 ` Pavel Machek 2009-06-17 21:36 ` HTC Dream aka. t-mobile g1 support Arve Hjønnevåg 2009-06-23 13:06 ` HTC Dream in 2.6.31-git? " Pavel Machek 2 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-17 17:16 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH, Arve Hj??nnev??g Hi! > > One more question... do you have keymap.map to make console usable? By > > default, keyboard lacks any special characters... > > I don't think we ever put together a full keymap for the console, > since we don't use it much. Arve might have done something with > setkey once upon a time. Maybe not "full", but very usable. F1..F10 are missing, but there's still place where to map them. --- Keymap suitable for HTC Dream. Signed-off-by: Pavel Machek <pavel@ucw.cz> --- commit abde64fc50078f6b5fa3773c652eef8d3079225f tree d2fe81626af1922cff8a924e7e5aa193d817fd7e parent a7571e0d1492573d67a999efb9acf30781a471e8 author Pavel <pavel@ucw.cz> Wed, 17 Jun 2009 19:15:29 +0200 committer Pavel <pavel@ucw.cz> Wed, 17 Jun 2009 19:15:29 +0200 drivers/char/Makefile | 2 drivers/char/defkeymap.map | 381 +++++++++++++++++++++++++------------------- 2 files changed, 214 insertions(+), 169 deletions(-) diff --git a/drivers/char/Makefile b/drivers/char/Makefile index 5ab656b..1bcbd9e 100644 --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -126,7 +126,7 @@ $(obj)/defkeymap.o: $(obj)/defkeymap.c # Uncomment if you're changing the keymap and have an appropriate # loadkeys version for the map. By default, we'll use the shipped # versions. -# GENERATE_KEYMAP := 1 +GENERATE_KEYMAP := 1 ifdef GENERATE_KEYMAP diff --git a/drivers/char/defkeymap.map b/drivers/char/defkeymap.map index 50b30ca..a89bcfd 100644 --- a/drivers/char/defkeymap.map +++ b/drivers/char/defkeymap.map @@ -1,7 +1,6 @@ # Default kernel keymap. This uses 7 modifier combinations. -keymaps 0-2,4-5,8,12 -# Change the above line into -# keymaps 0-2,4-6,8,12 +keymaps 0-2,4-6,8,12 +# # in case you want the entries # altgr control keycode 83 = Boot # altgr control keycode 111 = Boot @@ -11,8 +10,26 @@ keymaps 0-2,4-5,8,12 # be saved by mapping AltGr to Alt (and adapting a few entries): # keycode 100 = Alt # -keycode 1 = Escape Escape - alt keycode 1 = Meta_Escape + +# Keymap for HTC Dream +# Pavel Machek <pavel@ucw.cz> +# +# What is labeled "alt" on device is AltGr in keymap. +# Button with search icon and home button near ball serve as Alt. +# Both menu buttons should serve as control. +# "alt" + azxc serve as arrow keys. +# +# Menu near left shift is F1, ouch. +# +# Special keys are mapped like this: +# 139 - ctrl +# [menu] +# [green] [home] o [back] [red] +# 231 102 - alt 158 107 + + +#keycode 1 = Escape Escape +# alt keycode 1 = Meta_Escape keycode 2 = one exclam alt keycode 2 = Meta_one keycode 3 = two at at @@ -41,177 +58,196 @@ keycode 10 = nine parenleft bracketright alt keycode 10 = Meta_nine keycode 11 = zero parenright braceright alt keycode 11 = Meta_zero -keycode 12 = minus underscore backslash - control keycode 12 = Control_underscore - shift control keycode 12 = Control_underscore - alt keycode 12 = Meta_minus -keycode 13 = equal plus - alt keycode 13 = Meta_equal +#keycode 12 = minus underscore backslash +# control keycode 12 = Control_underscore +# shift control keycode 12 = Control_underscore +# alt keycode 12 = Meta_minus +#keycode 13 = equal plus +# alt keycode 13 = Meta_equal keycode 14 = Delete Delete control keycode 14 = BackSpace alt keycode 14 = Meta_Delete -keycode 15 = Tab Tab - alt keycode 15 = Meta_Tab +#keycode 15 = Tab Tab +# alt keycode 15 = Meta_Tab keycode 16 = q + altgr keycode 16 = Tab keycode 17 = w + altgr keycode 17 = grave keycode 18 = e - altgr keycode 18 = Hex_E + altgr keycode 18 = underscore keycode 19 = r keycode 20 = t keycode 21 = y keycode 22 = u keycode 23 = i + altgr keycode 23 = minus keycode 24 = o + altgr keycode 24 = plus keycode 25 = p -keycode 26 = bracketleft braceleft - control keycode 26 = Escape - alt keycode 26 = Meta_bracketleft -keycode 27 = bracketright braceright asciitilde - control keycode 27 = Control_bracketright - alt keycode 27 = Meta_bracketright + altgr keycode 25 = equal +#keycode 26 = bracketleft braceleft +# control keycode 26 = Escape +# alt keycode 26 = Meta_bracketleft +#keycode 27 = bracketright braceright asciitilde +# control keycode 27 = Control_bracketright +# alt keycode 27 = Meta_bracketright keycode 28 = Return alt keycode 28 = Meta_Control_m -keycode 29 = Control +#keycode 29 = Control keycode 30 = a - altgr keycode 30 = Hex_A + altgr keycode 30 = Up keycode 31 = s + altgr keycode 31 = bar keycode 32 = d - altgr keycode 32 = Hex_D + altgr keycode 32 = backslash keycode 33 = f - altgr keycode 33 = Hex_F + altgr keycode 33 = bracketleft keycode 34 = g + altgr keycode 34 = bracketright keycode 35 = h + altgr keycode 35 = colon keycode 36 = j + altgr keycode 36 = semicolon keycode 37 = k + altgr keycode 37 = quotedbl keycode 38 = l -keycode 39 = semicolon colon - alt keycode 39 = Meta_semicolon -keycode 40 = apostrophe quotedbl - control keycode 40 = Control_g - alt keycode 40 = Meta_apostrophe -keycode 41 = grave asciitilde - control keycode 41 = nul - alt keycode 41 = Meta_grave + altgr keycode 38 = apostrophe +#keycode 39 = semicolon colon +# alt keycode 39 = Meta_semicolon +#keycode 40 = apostrophe quotedbl +# control keycode 40 = Control_g +# alt keycode 40 = Meta_apostrophe +#keycode 41 = grave asciitilde +# control keycode 41 = nul +# alt keycode 41 = Meta_grave keycode 42 = Shift -keycode 43 = backslash bar - control keycode 43 = Control_backslash - alt keycode 43 = Meta_backslash +#keycode 43 = backslash bar +# control keycode 43 = Control_backslash +# alt keycode 43 = Meta_backslash keycode 44 = z + altgr keycode 44 = Left keycode 45 = x + altgr keycode 45 = Down keycode 46 = c - altgr keycode 46 = Hex_C + altgr keycode 46 = Right keycode 47 = v + altgr keycode 47 = bracketleft keycode 48 = b - altgr keycode 48 = Hex_B + altgr keycode 48 = bracketright keycode 49 = n + altgr keycode 49 = less keycode 50 = m -keycode 51 = comma less + altgr keycode 50 = greater +keycode 51 = comma + altgr keycode 51 = question alt keycode 51 = Meta_comma -keycode 52 = period greater +keycode 52 = period control keycode 52 = Compose alt keycode 52 = Meta_period -keycode 53 = slash question - control keycode 53 = Delete - alt keycode 53 = Meta_slash + altgr keycode 52 = slash +#keycode 53 = slash question +# control keycode 53 = Delete +# alt keycode 53 = Meta_slash keycode 54 = Shift -keycode 55 = KP_Multiply -keycode 56 = Alt +#keycode 55 = KP_Multiply +keycode 56 = AltGr keycode 57 = space space control keycode 57 = nul alt keycode 57 = Meta_space -keycode 58 = Caps_Lock -keycode 59 = F1 F11 Console_13 - control keycode 59 = F1 - alt keycode 59 = Console_1 - control alt keycode 59 = Console_1 -keycode 60 = F2 F12 Console_14 - control keycode 60 = F2 - alt keycode 60 = Console_2 - control alt keycode 60 = Console_2 -keycode 61 = F3 F13 Console_15 - control keycode 61 = F3 - alt keycode 61 = Console_3 - control alt keycode 61 = Console_3 -keycode 62 = F4 F14 Console_16 - control keycode 62 = F4 - alt keycode 62 = Console_4 - control alt keycode 62 = Console_4 -keycode 63 = F5 F15 Console_17 - control keycode 63 = F5 - alt keycode 63 = Console_5 - control alt keycode 63 = Console_5 -keycode 64 = F6 F16 Console_18 - control keycode 64 = F6 - alt keycode 64 = Console_6 - control alt keycode 64 = Console_6 -keycode 65 = F7 F17 Console_19 - control keycode 65 = F7 - alt keycode 65 = Console_7 - control alt keycode 65 = Console_7 -keycode 66 = F8 F18 Console_20 - control keycode 66 = F8 - alt keycode 66 = Console_8 - control alt keycode 66 = Console_8 -keycode 67 = F9 F19 Console_21 - control keycode 67 = F9 - alt keycode 67 = Console_9 - control alt keycode 67 = Console_9 -keycode 68 = F10 F20 Console_22 - control keycode 68 = F10 - alt keycode 68 = Console_10 - control alt keycode 68 = Console_10 -keycode 69 = Num_Lock - shift keycode 69 = Bare_Num_Lock -keycode 70 = Scroll_Lock Show_Memory Show_Registers - control keycode 70 = Show_State - alt keycode 70 = Scroll_Lock -keycode 71 = KP_7 - alt keycode 71 = Ascii_7 - altgr keycode 71 = Hex_7 -keycode 72 = KP_8 - alt keycode 72 = Ascii_8 - altgr keycode 72 = Hex_8 -keycode 73 = KP_9 - alt keycode 73 = Ascii_9 - altgr keycode 73 = Hex_9 -keycode 74 = KP_Subtract -keycode 75 = KP_4 - alt keycode 75 = Ascii_4 - altgr keycode 75 = Hex_4 -keycode 76 = KP_5 - alt keycode 76 = Ascii_5 - altgr keycode 76 = Hex_5 -keycode 77 = KP_6 - alt keycode 77 = Ascii_6 - altgr keycode 77 = Hex_6 -keycode 78 = KP_Add -keycode 79 = KP_1 - alt keycode 79 = Ascii_1 - altgr keycode 79 = Hex_1 -keycode 80 = KP_2 - alt keycode 80 = Ascii_2 - altgr keycode 80 = Hex_2 -keycode 81 = KP_3 - alt keycode 81 = Ascii_3 - altgr keycode 81 = Hex_3 -keycode 82 = KP_0 - alt keycode 82 = Ascii_0 - altgr keycode 82 = Hex_0 -keycode 83 = KP_Period -# altgr control keycode 83 = Boot - control alt keycode 83 = Boot -keycode 84 = Last_Console + altgr keycode 59 = Escape +#keycode 58 = Caps_Lock +# menu key near left shift +keycode 59 = Control +# control keycode 59 = F1 +# alt keycode 59 = Console_1 +# control alt keycode 59 = Console_1 +#keycode 60 = F2 F12 Console_14 +# control keycode 60 = F2 +# alt keycode 60 = Console_2 +# control alt keycode 60 = Console_2 +#keycode 61 = F3 F13 Console_15 +# control keycode 61 = F3 +# alt keycode 61 = Console_3 +# control alt keycode 61 = Console_3 +#keycode 62 = F4 F14 Console_16 +# control keycode 62 = F4 +# alt keycode 62 = Console_4 +# control alt keycode 62 = Console_4 +#keycode 63 = F5 F15 Console_17 +# control keycode 63 = F5 +# alt keycode 63 = Console_5 +# control alt keycode 63 = Console_5 +#keycode 64 = F6 F16 Console_18 +# control keycode 64 = F6 +# alt keycode 64 = Console_6 +# control alt keycode 64 = Console_6 +#keycode 65 = F7 F17 Console_19 +# control keycode 65 = F7 +# alt keycode 65 = Console_7 +# control alt keycode 65 = Console_7 +#keycode 66 = F8 F18 Console_20 +# control keycode 66 = F8 +# alt keycode 66 = Console_8 +# control alt keycode 66 = Console_8 +#keycode 67 = F9 F19 Console_21 +# control keycode 67 = F9 +# alt keycode 67 = Console_9 +# control alt keycode 67 = Console_9 +#keycode 68 = F10 F20 Console_22 +# control keycode 68 = F10 +# alt keycode 68 = Console_10 +# control alt keycode 68 = Console_10 +#keycode 69 = Num_Lock +# shift keycode 69 = Bare_Num_Lock +#keycode 70 = Scroll_Lock Show_Memory Show_Registers +# control keycode 70 = Show_State +# alt keycode 70 = Scroll_Lock +#keycode 71 = KP_7 +# alt keycode 71 = Ascii_7 +# altgr keycode 71 = Hex_7 +#keycode 72 = KP_8 +# alt keycode 72 = Ascii_8 +# altgr keycode 72 = Hex_8 +#keycode 73 = KP_9 +# alt keycode 73 = Ascii_9 +# altgr keycode 73 = Hex_9 +#keycode 74 = KP_Subtract +#keycode 75 = KP_4 +# alt keycode 75 = Ascii_4 +# altgr keycode 75 = Hex_4 +#keycode 76 = KP_5 +# alt keycode 76 = Ascii_5 +# altgr keycode 76 = Hex_5 +#keycode 77 = KP_6 +# alt keycode 77 = Ascii_6 +# altgr keycode 77 = Hex_6 +#keycode 78 = KP_Add +#keycode 79 = KP_1 +# alt keycode 79 = Ascii_1 +# altgr keycode 79 = Hex_1 +#keycode 80 = KP_2 +# alt keycode 80 = Ascii_2 +# altgr keycode 80 = Hex_2 +#keycode 81 = KP_3 +# alt keycode 81 = Ascii_3 +# altgr keycode 81 = Hex_3 +#keycode 82 = KP_0 +# alt keycode 82 = Ascii_0 +# altgr keycode 82 = Hex_0 +#keycode 83 = KP_Period +# control alt keycode 83 = Boot +#keycode 84 = Last_Console keycode 85 = -keycode 86 = less greater bar - alt keycode 86 = Meta_less -keycode 87 = F11 F11 Console_23 - control keycode 87 = F11 - alt keycode 87 = Console_11 - control alt keycode 87 = Console_11 -keycode 88 = F12 F12 Console_24 - control keycode 88 = F12 - alt keycode 88 = Console_12 - control alt keycode 88 = Console_12 +#keycode 86 = less greater bar +# alt keycode 86 = Meta_less +#keycode 87 = F11 F11 Console_23 +# control keycode 87 = F11 +# alt keycode 87 = Console_11 +# control alt keycode 87 = Console_11 +#keycode 88 = F12 F12 Console_24 +# control keycode 88 = F12 +# alt keycode 88 = Console_12 +# control alt keycode 88 = Console_12 keycode 89 = keycode 90 = keycode 91 = @@ -219,38 +255,38 @@ keycode 92 = keycode 93 = keycode 94 = keycode 95 = -keycode 96 = KP_Enter -keycode 97 = Control -keycode 98 = KP_Divide -keycode 99 = Control_backslash - control keycode 99 = Control_backslash - alt keycode 99 = Control_backslash +#keycode 96 = KP_Enter +#keycode 97 = Control +#keycode 98 = KP_Divide +#keycode 99 = Control_backslash +# control keycode 99 = Control_backslash +# alt keycode 99 = Control_backslash keycode 100 = AltGr -keycode 101 = Break -keycode 102 = Find -keycode 103 = Up -keycode 104 = Prior - shift keycode 104 = Scroll_Backward -keycode 105 = Left - alt keycode 105 = Decr_Console -keycode 106 = Right - alt keycode 106 = Incr_Console -keycode 107 = Select -keycode 108 = Down -keycode 109 = Next - shift keycode 109 = Scroll_Forward -keycode 110 = Insert -keycode 111 = Remove -# altgr control keycode 111 = Boot - control alt keycode 111 = Boot -keycode 112 = Macro -keycode 113 = F13 -keycode 114 = F14 -keycode 115 = Help -keycode 116 = Do -keycode 117 = F17 -keycode 118 = KP_MinPlus -keycode 119 = Pause +#keycode 101 = Break +# Button with icon of home +keycode 102 = Alt +#keycode 103 = Up +#keycode 104 = Prior +# shift keycode 104 = Scroll_Backward +#keycode 105 = Left +# alt keycode 105 = Decr_Console +#keycode 106 = Right +# alt keycode 106 = Incr_Console +#keycode 107 = Select +#keycode 108 = Down +#keycode 109 = Next +# shift keycode 109 = Scroll_Forward +#keycode 110 = Insert +#keycode 111 = Remove +# control alt keycode 111 = Boot +#keycode 112 = Macro +#keycode 113 = F13 +#keycode 114 = F14 +#keycode 115 = Help +#keycode 116 = Do +#keycode 117 = F17 +#keycode 118 = KP_MinPlus +#keycode 119 = Pause keycode 120 = keycode 121 = keycode 122 = @@ -258,7 +294,16 @@ keycode 123 = keycode 124 = keycode 125 = keycode 126 = -keycode 127 = +# O find key +# \ +keycode 127 = Alt + +# Menu in buttons +keycode 139 = Control +# @~ +keycode 215 = at + altgr keycode 215 = asciitilde + string F1 = "\033[[A" string F2 = "\033[[B" string F3 = "\033[[C" -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply related [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-17 9:40 ` Brian Swetland 2009-06-17 17:16 ` HTC Dream keymap (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek @ 2009-06-17 21:36 ` Arve Hjønnevåg 2009-06-18 10:13 ` Pavel Machek 2009-06-23 13:06 ` HTC Dream in 2.6.31-git? " Pavel Machek 2 siblings, 1 reply; 167+ messages in thread From: Arve Hjønnevåg @ 2009-06-17 21:36 UTC (permalink / raw) To: Brian Swetland Cc: Pavel Machek, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Wed, Jun 17, 2009 at 2:40 AM, Brian Swetland<swetland@google.com> wrote: > On Wed, Jun 17, 2009 at 2:11 AM, Pavel Machek<pavel@ucw.cz> wrote: ... >> One more question... do you have keymap.map to make console usable? By >> default, keyboard lacks any special characters... > > I don't think we ever put together a full keymap for the console, > since we don't use it much. Arve might have done something with > setkey once upon a time. > I used setkey on older hardware to get a usable console, but the original dream keyboards did not need a special keymap to be useful. We change the keymap in vendor/htc/dream/init.trout.rc, but it is probably the opposite of what you want. -- Arve Hjønnevåg ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-17 21:36 ` HTC Dream aka. t-mobile g1 support Arve Hjønnevåg @ 2009-06-18 10:13 ` Pavel Machek 2009-06-18 19:33 ` Brian Swetland 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-18 10:13 UTC (permalink / raw) To: Arve Hj?nnev?g Cc: Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Wed 2009-06-17 14:36:50, Arve Hj?nnev?g wrote: > On Wed, Jun 17, 2009 at 2:40 AM, Brian Swetland<swetland@google.com> wrote: > > On Wed, Jun 17, 2009 at 2:11 AM, Pavel Machek<pavel@ucw.cz> wrote: > ... > >> One more question... do you have keymap.map to make console usable? By > >> default, keyboard lacks any special characters... > > > > I don't think we ever put together a full keymap for the console, > > since we don't use it much. Arve might have done something with > > setkey once upon a time. > > I used setkey on older hardware to get a usable console, but the > original dream keyboards did not need a special keymap to be useful. > We change the keymap in vendor/htc/dream/init.trout.rc, but it is > probably the opposite of what you want. Ok, I created something useful in the meantime. Question is, what to do with the new keymap? I can obviously keep it at local patch, but... PC defkeymap.map makes HTC Dream useless. HTC Dream defkeymap.map makes PC useless :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-18 10:13 ` Pavel Machek @ 2009-06-18 19:33 ` Brian Swetland 2009-06-18 19:38 ` David Miller 0 siblings, 1 reply; 167+ messages in thread From: Brian Swetland @ 2009-06-18 19:33 UTC (permalink / raw) To: Pavel Machek Cc: Arve Hj?nnev?g, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Thu, Jun 18, 2009 at 3:13 AM, Pavel Machek<pavel@ucw.cz> wrote: >> >> I used setkey on older hardware to get a usable console, but the >> original dream keyboards did not need a special keymap to be useful. >> We change the keymap in vendor/htc/dream/init.trout.rc, but it is >> probably the opposite of what you want. > > Ok, I created something useful in the meantime. Question is, what to > do with the new keymap? I can obviously keep it at local patch, but... > > PC defkeymap.map makes HTC Dream useless. > > HTC Dream defkeymap.map makes PC useless :-(. Yeah, I wasn't sure how to handle this. We try to keep the msm/dream stuff in a state that doesn't break other parts of the tree, but there doesn't seem to be support for different keymaps for different devices. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-18 19:33 ` Brian Swetland @ 2009-06-18 19:38 ` David Miller 2009-06-18 23:07 ` defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: David Miller @ 2009-06-18 19:38 UTC (permalink / raw) To: swetland Cc: pavel, arve, linux, linux-kernel, linux-arm-kernel, san, rlove, greg From: Brian Swetland <swetland@google.com> Date: Thu, 18 Jun 2009 12:33:48 -0700 > Yeah, I wasn't sure how to handle this. We try to keep the msm/dream > stuff in a state that doesn't break other parts of the tree, but there > doesn't seem to be support for different keymaps for different > devices. How it's supposed to work is that you have a specific keyboard driver and that emits PC keyboard codes into the core kernel using a translation table in your driver. For example on Sparc machines we have a Sun Type-4/5 keyboard driver, but all applications and the kernel see PC keycodes. ^ permalink raw reply [flat|nested] 167+ messages in thread
* defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-18 19:38 ` David Miller @ 2009-06-18 23:07 ` Pavel Machek 2009-06-22 9:33 ` Jiri Kosina 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-18 23:07 UTC (permalink / raw) To: David Miller, dmitry.torokhov, linux-input, jikos Cc: swetland, arve, linux, linux-kernel, linux-arm-kernel, san, rlove, greg Hi! Debate is about keymaps: Ok, I created something useful in the meantime. Question is, what to do with the new keymap? I can obviously keep it at local patch, but... PC defkeymap.map makes HTC Dream useless. HTC Dream defkeymap.map makes PC useless :-(. > > Yeah, I wasn't sure how to handle this. We try to keep the msm/dream > > stuff in a state that doesn't break other parts of the tree, but there > > doesn't seem to be support for different keymaps for different > > devices. > > How it's supposed to work is that you have a specific keyboard driver > and that emits PC keyboard codes into the core kernel using a > translation table in your driver. Of course, Dream does that. But that's not _nearly_ enough. Dream lacks keys such as: esc, arrows, symbols (/;'[]\-=). That means that for +, you can't press shift-=, you need to press altgr-P. So yes, mapping keycodes helps (at least you get a-z,0-9), but that's basically it, and keys it has are not enough to actually type loadkeys /foo/bar/baz.map :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-18 23:07 ` defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek @ 2009-06-22 9:33 ` Jiri Kosina 2009-06-22 17:22 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: Jiri Kosina @ 2009-06-22 9:33 UTC (permalink / raw) To: Pavel Machek Cc: David Miller, Dmitry Torokhov, linux-input, swetland, arve, linux, linux-kernel, linux-arm-kernel, san, rlove, Greg KH On Fri, 19 Jun 2009, Pavel Machek wrote: > > > Yeah, I wasn't sure how to handle this. We try to keep the > > > msm/dream stuff in a state that doesn't break other parts of the > > > tree, but there doesn't seem to be support for different keymaps for > > > different devices. > > How it's supposed to work is that you have a specific keyboard driver > > and that emits PC keyboard codes into the core kernel using a > > translation table in your driver. > Of course, Dream does that. But that's not _nearly_ enough. Dream > lacks keys such as: esc, arrows, symbols (/;'[]\-=). That means that > for +, you can't press shift-=, you need to press altgr-P. I don't seem to have enough context, but wouldn't writing a separate serio driver, which would do all the needed translations be enough here? -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-22 9:33 ` Jiri Kosina @ 2009-06-22 17:22 ` Pavel Machek 0 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-22 17:22 UTC (permalink / raw) To: Jiri Kosina Cc: David Miller, Dmitry Torokhov, linux-input, swetland, arve, linux, linux-kernel, linux-arm-kernel, san, rlove, Greg KH On Mon 2009-06-22 11:33:31, Jiri Kosina wrote: > On Fri, 19 Jun 2009, Pavel Machek wrote: > > > > > Yeah, I wasn't sure how to handle this. We try to keep the > > > > msm/dream stuff in a state that doesn't break other parts of the > > > > tree, but there doesn't seem to be support for different keymaps for > > > > different devices. > > > How it's supposed to work is that you have a specific keyboard driver > > > and that emits PC keyboard codes into the core kernel using a > > > translation table in your driver. > > Of course, Dream does that. But that's not _nearly_ enough. Dream > > lacks keys such as: esc, arrows, symbols (/;'[]\-=). That means that > > for +, you can't press shift-=, you need to press altgr-P. > > I don't seem to have enough context, but wouldn't writing a separate serio > driver, which would do all the needed translations be enough here? Umm. Yes, we could parse the keyboard combinations in the keyboard driver, and then emulate the PC keyboard. It would be incredibly ugly. Such as: If user presses Alt+I, (labeled "-" on keyboard), emulate "Shift+=" press, then let the defkeymap.map translate it back to "-". I... guess it will be nicer if the keyboard driver specifies which keymap to use? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-17 9:40 ` Brian Swetland 2009-06-17 17:16 ` HTC Dream keymap (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek 2009-06-17 21:36 ` HTC Dream aka. t-mobile g1 support Arve Hjønnevåg @ 2009-06-23 13:06 ` Pavel Machek 2009-06-23 21:45 ` davidb 2 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-23 13:06 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH, Arve Hj??nnev??g Hi! Is there version of linux-msm tree for 2.6.31-git ...? (even 2.6.30 version would help). I tried naively porting patches forward, but resulting kernel would not boot :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-23 13:06 ` HTC Dream in 2.6.31-git? " Pavel Machek @ 2009-06-23 21:45 ` davidb 2009-06-24 9:10 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: davidb @ 2009-06-23 21:45 UTC (permalink / raw) To: Pavel Machek Cc: Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH, Arve Hj??nnev??g On Tue, Jun 23, 2009 at 06:06:15AM -0700, Pavel Machek wrote: > Is there version of linux-msm tree for 2.6.31-git ...? (even 2.6.30 version > would help). I tried naively porting patches forward, but resulting > kernel would not boot :-(. Not yet, at least not yet in our tree. I'm hoping to get to this fairly soon. Is the Dream the only target that people here actually have, or did anyone get a Magic recently? I'm trying to track down one of the G1's we purchased, since they all seem to have become people's personal phones. David ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-23 21:45 ` davidb @ 2009-06-24 9:10 ` Pavel Machek 2009-06-24 23:37 ` Arve Hjønnevåg 0 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-24 9:10 UTC (permalink / raw) To: davidb Cc: Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH, Arve Hj??nnev??g On Tue 2009-06-23 14:45:43, davidb@quicinc.com wrote: > On Tue, Jun 23, 2009 at 06:06:15AM -0700, Pavel Machek wrote: > > > Is there version of linux-msm tree for 2.6.31-git ...? (even 2.6.30 version > > would help). I tried naively porting patches forward, but resulting > > kernel would not boot :-(. > > Not yet, at least not yet in our tree. I'm hoping to get to this > fairly soon. If you have any patches, let me know; you'll have one happy tester. > Is the Dream the only target that people here actually have, or > did anyone get a Magic recently? I'm trying to track down one of Magic will go on sale here at the end of month; I believe it is already available at other markets. But being "Dream without keyboard", I'm not sure what is attractive about it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-24 9:10 ` Pavel Machek @ 2009-06-24 23:37 ` Arve Hjønnevåg 2009-06-25 11:42 ` Pavel Machek 2009-06-26 23:01 ` Pavel Machek 0 siblings, 2 replies; 167+ messages in thread From: Arve Hjønnevåg @ 2009-06-24 23:37 UTC (permalink / raw) To: Pavel Machek Cc: davidb, Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Wed, Jun 24, 2009 at 2:10 AM, Pavel Machek<pavel@ucw.cz> wrote: > On Tue 2009-06-23 14:45:43, davidb@quicinc.com wrote: >> On Tue, Jun 23, 2009 at 06:06:15AM -0700, Pavel Machek wrote: >> >> > Is there version of linux-msm tree for 2.6.31-git ...? (even 2.6.30 version >> > would help). I tried naively porting patches forward, but resulting >> > kernel would not boot :-(. >> >> Not yet, at least not yet in our tree. I'm hoping to get to this >> fairly soon. > > If you have any patches, let me know; you'll have one happy tester. > I don't have time to merge or rebase onto 2.6.31 and test it right now, but I pushed my old 2.6.30-rc2 test branch to git://android.git.kernel.org/kernel/experimental.git (as android-msm-2.6.30-rc2-test) which should at least get you closer to booting on 2.6.31. -- Arve Hjønnevåg ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-24 23:37 ` Arve Hjønnevåg @ 2009-06-25 11:42 ` Pavel Machek 2009-06-26 23:01 ` Pavel Machek 1 sibling, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-25 11:42 UTC (permalink / raw) To: Arve Hj?nnev?g Cc: davidb, Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH On Wed 2009-06-24 16:37:33, Arve Hj?nnev?g wrote: > On Wed, Jun 24, 2009 at 2:10 AM, Pavel Machek<pavel@ucw.cz> wrote: > > On Tue 2009-06-23 14:45:43, davidb@quicinc.com wrote: > >> On Tue, Jun 23, 2009 at 06:06:15AM -0700, Pavel Machek wrote: > >> > >> > Is there version of linux-msm tree for 2.6.31-git ...? (even 2.6.30 version > >> > would help). I tried naively porting patches forward, but resulting > >> > kernel would not boot :-(. > >> > >> Not yet, at least not yet in our tree. I'm hoping to get to this > >> fairly soon. > > > > If you have any patches, let me know; you'll have one happy tester. > > > > I don't have time to merge or rebase onto 2.6.31 and test it right > now, but I pushed my old 2.6.30-rc2 test branch to > git://android.git.kernel.org/kernel/experimental.git (as > android-msm-2.6.30-rc2-test) which should at least get you closer to > booting on 2.6.31. Thanks! It actually boots for me. I'll see if I can get 2.6.30 & 2.6.31-rc to boot, too. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support) 2009-06-24 23:37 ` Arve Hjønnevåg 2009-06-25 11:42 ` Pavel Machek @ 2009-06-26 23:01 ` Pavel Machek 1 sibling, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-26 23:01 UTC (permalink / raw) To: Arve Hj?nnev?g Cc: davidb, Brian Swetland, Russell King - ARM Linux, kernel list, linux-arm-kernel, san, rlove, Greg KH [-- Attachment #1: Type: text/plain, Size: 1358 bytes --] On Wed 2009-06-24 16:37:33, Arve Hj?nnev?g wrote: > On Wed, Jun 24, 2009 at 2:10 AM, Pavel Machek<pavel@ucw.cz> wrote: > > On Tue 2009-06-23 14:45:43, davidb@quicinc.com wrote: > >> On Tue, Jun 23, 2009 at 06:06:15AM -0700, Pavel Machek wrote: > >> > >> > Is there version of linux-msm tree for 2.6.31-git ...? (even 2.6.30 version > >> > would help). I tried naively porting patches forward, but resulting > >> > kernel would not boot :-(. > >> > >> Not yet, at least not yet in our tree. I'm hoping to get to this > >> fairly soon. > > > > If you have any patches, let me know; you'll have one happy tester. > > > > I don't have time to merge or rebase onto 2.6.31 and test it right > now, but I pushed my old 2.6.30-rc2 test branch to > git://android.git.kernel.org/kernel/experimental.git (as > android-msm-2.6.30-rc2-test) which should at least get you closer to > booting on 2.6.31. Thanks! I forward ported patches to 2.6.31-rc1, and it seems to boot/work well enough for a shell. (I _did_ take few shortcuts). Resulting diff (2.5MB) is at http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/g1.8.diff . config attached. Now.. I do have a git tree with my hacks, but I guess they are just too hacky. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: .config --] [-- Type: text/plain, Size: 35129 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.31-rc1 # Sat Jun 27 00:49:30 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0xffff0000 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_PANIC_TIMEOUT=5 CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ASHMEM=y # # Performance Counters # CONFIG_VM_EVENT_COUNTERS=y # CONFIG_STRIP_ASM_SYMS is not set CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_FREEZER=y # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_MXC is not set # CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KIRKWOOD is not set # CONFIG_ARCH_LOKI is not set # CONFIG_ARCH_MV78XX0 is not set # CONFIG_ARCH_ORION5X is not set # CONFIG_ARCH_MMP is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set # CONFIG_ARCH_OMAP is not set CONFIG_ARCH_MSM=y CONFIG_MSM_AMSS_VERSION=6225 # CONFIG_MSM_AMSS_VERSION_6210 is not set # CONFIG_MSM_AMSS_VERSION_6220 is not set CONFIG_MSM_AMSS_VERSION_6225=y CONFIG_MSM_DEBUG_UART_NONE=y # CONFIG_MSM_DEBUG_UART1 is not set # CONFIG_MSM_DEBUG_UART2 is not set # CONFIG_MSM_DEBUG_UART3 is not set # # MSM Board Type # # CONFIG_MACH_HALIBUT is not set CONFIG_MACH_TROUT=y # CONFIG_MACH_SAPPHIRE is not set CONFIG_HTC_HEADSET=y CONFIG_TROUT_BATTCHG=y CONFIG_HTC_PWRSINK=y CONFIG_MSM7X00A_USE_GP_TIMER=y # CONFIG_MSM7X00A_USE_DG_TIMER is not set CONFIG_MSM7X00A_SLEEP_MODE_POWER_COLLAPSE_SUSPEND=y # CONFIG_MSM7X00A_SLEEP_MODE_POWER_COLLAPSE is not set # CONFIG_MSM7X00A_SLEEP_MODE_APPS_SLEEP is not set # CONFIG_MSM7X00A_SLEEP_MODE_RAMP_DOWN_AND_WAIT_FOR_INTERRUPT is not set # CONFIG_MSM7X00A_SLEEP_WAIT_FOR_INTERRUPT is not set CONFIG_MSM7X00A_SLEEP_MODE=0 # CONFIG_MSM7X00A_IDLE_SLEEP_MODE_POWER_COLLAPSE_SUSPEND is not set CONFIG_MSM7X00A_IDLE_SLEEP_MODE_POWER_COLLAPSE=y # CONFIG_MSM7X00A_IDLE_SLEEP_MODE_APPS_SLEEP is not set # CONFIG_MSM7X00A_IDLE_SLEEP_MODE_RAMP_DOWN_AND_WAIT_FOR_INTERRUPT is not set # CONFIG_MSM7X00A_IDLE_SLEEP_WAIT_FOR_INTERRUPT is not set CONFIG_MSM7X00A_IDLE_SLEEP_MODE=1 CONFIG_MSM7X00A_IDLE_SLEEP_MIN_TIME=20000000 CONFIG_MSM7X00A_IDLE_SPIN_TIME=80000 CONFIG_MSM_IDLE_STATS=y CONFIG_MSM_IDLE_STATS_FIRST_BUCKET=62500 CONFIG_MSM_IDLE_STATS_BUCKET_SHIFT=2 CONFIG_MSM_IDLE_STATS_BUCKET_COUNT=10 CONFIG_MSM_FIQ_SUPPORT=y # CONFIG_MSM_SERIAL_DEBUGGER is not set CONFIG_MSM_SMD=y CONFIG_MSM_ONCRPCROUTER=y CONFIG_MSM_RPCSERVERS=y CONFIG_MSM_CPU_FREQ=y CONFIG_MSM_CPU_FREQ_ONDEMAND=y # CONFIG_MSM_CPU_FREQ_SCREEN is not set CONFIG_MSM_CPU_FREQ_ONDEMAND_MAX=384000 CONFIG_MSM_CPU_FREQ_ONDEMAND_MIN=245760 CONFIG_MSM_HW3D=y CONFIG_MSM_ADSP=y CONFIG_WIFI_CONTROL_FUNC=y CONFIG_WIFI_MEM_PREALLOC=y # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_V6=y # CONFIG_CPU_32v6K is not set CONFIG_CPU_32v6=y CONFIG_CPU_ABRT_EV6=y CONFIG_CPU_PABRT_NOIFAR=y CONFIG_CPU_CACHE_V6=y CONFIG_CPU_CACHE_VIPT=y CONFIG_CPU_COPY_V6=y CONFIG_CPU_TLB_V6=y CONFIG_CPU_HAS_ASID=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y # # Processor Features # CONFIG_ARM_THUMB=y # CONFIG_CPU_ICACHE_DISABLE is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_BPREDICT_DISABLE is not set # CONFIG_ARM_ERRATA_411920 is not set # # Bus support # # CONFIG_PCI_SYSCALL is not set # CONFIG_ARCH_SUPPORTS_MSI is not set # CONFIG_PCCARD is not set # # Kernel Features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_PREEMPT=y CONFIG_HZ=100 CONFIG_AEABI=y # CONFIG_OABI_COMPAT is not set # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set # CONFIG_HIGHMEM is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=0 CONFIG_VIRT_TO_BUS=y CONFIG_HAVE_MLOCK=y CONFIG_HAVE_MLOCKED_PAGE_BIT=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ALIGNMENT_TRAP=y # CONFIG_UACCESS_WITH_MEMCPY is not set # # Boot options # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="mem=64M console=ttyMSM,115200n8" # CONFIG_XIP_KERNEL is not set # CONFIG_KEXEC is not set # # CPU Power Management # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # CONFIG_CPU_IDLE is not set # # Floating point emulation # # # At least one emulation must be selected # # CONFIG_VFP is not set # # Userspace binary formats # CONFIG_BINFMT_ELF=y CONFIG_HAVE_AOUT=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HAS_WAKELOCK=y CONFIG_HAS_EARLYSUSPEND=y CONFIG_WAKELOCK=y CONFIG_WAKELOCK_STAT=y CONFIG_USER_WAKELOCK=y CONFIG_EARLYSUSPEND=y # CONFIG_NO_USER_SPACE_SCREEN_ACCESS_CONTROL is not set # CONFIG_CONSOLE_EARLYSUSPEND is not set CONFIG_FB_EARLYSUSPEND=y # CONFIG_APM_EMULATION is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INET_TUNNEL is not set # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set # CONFIG_INET_DIAG is not set # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set CONFIG_ANDROID_PARANOID_NETWORK=y # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_NET_DSA is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_PHONET is not set # CONFIG_IEEE802154 is not set # CONFIG_NET_SCHED is not set # CONFIG_DCB is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set # CONFIG_WIRELESS is not set # CONFIG_WIMAX is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_CONCAT is not set CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_TESTS is not set # CONFIG_MTD_REDBOOT_PARTS is not set CONFIG_MTD_CMDLINE_PARTS=y # CONFIG_MTD_AFS_PARTS is not set # CONFIG_MTD_AR7_PARTS is not set # # User Modules And Translation Layers # CONFIG_MTD_CHAR=y CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # CONFIG_SSFDC is not set # CONFIG_MTD_OOPS is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # CONFIG_MTD_MSM_NAND=y # CONFIG_MTD_DATAFLASH is not set # CONFIG_MTD_M25P80 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # CONFIG_MTD_NAND is not set # CONFIG_MTD_ONENAND is not set # # LPDDR flash memory drivers # # CONFIG_MTD_LPDDR is not set # # UBI - Unsorted block images # # CONFIG_MTD_UBI is not set # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_MISC_DEVICES=y CONFIG_ANDROID_PMEM=y # CONFIG_ICS932S401 is not set # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_KERNEL_DEBUGGER_CORE is not set # CONFIG_ISL29003 is not set CONFIG_UID_STAT=y # CONFIG_C2PORT is not set # # EEPROM support # # CONFIG_EEPROM_AT24 is not set # CONFIG_EEPROM_AT25 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_MAX6875 is not set # CONFIG_EEPROM_93CX6 is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set # CONFIG_SCSI is not set # CONFIG_SCSI_DMA is not set # CONFIG_SCSI_NETLINK is not set # CONFIG_ATA is not set CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set CONFIG_BLK_DEV_DM=y CONFIG_DM_DEBUG=y CONFIG_DM_CRYPT=y # CONFIG_DM_SNAPSHOT is not set # CONFIG_DM_MIRROR is not set # CONFIG_DM_ZERO is not set # CONFIG_DM_MULTIPATH is not set # CONFIG_DM_DELAY is not set CONFIG_DM_UEVENT=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y # CONFIG_BONDING is not set # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_VETH is not set # CONFIG_PHYLIB is not set CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_AX88796 is not set CONFIG_SMC91X=y # CONFIG_DM9000 is not set # CONFIG_ENC28J60 is not set # CONFIG_ETHOC is not set # CONFIG_SMC911X is not set # CONFIG_SMSC911X is not set # CONFIG_DNET is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set # CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set # CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set # CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set # CONFIG_B44 is not set # CONFIG_KS8842 is not set CONFIG_NETDEV_1000=y CONFIG_NETDEV_10000=y # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set CONFIG_WLAN_80211=y # CONFIG_LIBERTAS is not set # CONFIG_HOSTAP is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # CONFIG_WAN is not set CONFIG_PPP=y # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=y # CONFIG_PPP_SYNC_TTY is not set CONFIG_PPP_DEFLATE=y CONFIG_PPP_BSDCOMP=y # CONFIG_PPP_MPPE is not set # CONFIG_PPPOE is not set # CONFIG_PPPOL2TP is not set # CONFIG_SLIP is not set CONFIG_SLHC=y # CONFIG_NETCONSOLE is not set # CONFIG_MSM_RMNET is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_ISDN is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # # Userland interfaces # # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set CONFIG_INPUT_KEYRESET=y # # Input Device Drivers # # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set CONFIG_INPUT_TOUCHSCREEN=y # CONFIG_TOUCHSCREEN_ADS7846 is not set # CONFIG_TOUCHSCREEN_AD7877 is not set # CONFIG_TOUCHSCREEN_AD7879_I2C is not set # CONFIG_TOUCHSCREEN_AD7879_SPI is not set # CONFIG_TOUCHSCREEN_AD7879 is not set # CONFIG_TOUCHSCREEN_EETI is not set # CONFIG_TOUCHSCREEN_FUJITSU is not set # CONFIG_TOUCHSCREEN_GUNZE is not set CONFIG_TOUCHSCREEN_ELAN_I2C_8232=y # CONFIG_TOUCHSCREEN_ELO is not set # CONFIG_TOUCHSCREEN_WACOM_W8001 is not set # CONFIG_TOUCHSCREEN_MTOUCH is not set # CONFIG_TOUCHSCREEN_INEXIO is not set # CONFIG_TOUCHSCREEN_MK712 is not set # CONFIG_TOUCHSCREEN_PENMOUNT is not set CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI=y # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set # CONFIG_TOUCHSCREEN_TOUCHWIN is not set # CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set # CONFIG_TOUCHSCREEN_TSC2007 is not set # CONFIG_TOUCHSCREEN_W90X900 is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set CONFIG_INPUT_KEYCHORD=y # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set CONFIG_INPUT_UINPUT=y CONFIG_INPUT_GPIO=y # # Hardware I/O ports # # CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_DEVMEM is not set # CONFIG_DEVKMEM is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # # CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MAX3100 is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_MSM=y # CONFIG_SERIAL_MSM_CONSOLE is not set CONFIG_SERIAL_MSM_CLOCK_CONTROL=y CONFIG_SERIAL_MSM_RX_WAKEUP=y CONFIG_SERIAL_MSM_HS=y CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set # CONFIG_LEGACY_PTYS is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_HW_RANDOM is not set # CONFIG_R3964 is not set # CONFIG_RAW_DRIVER is not set # CONFIG_TCG_TPM is not set # CONFIG_DCC_TTY is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y # CONFIG_I2C_CHARDEV is not set CONFIG_I2C_HELPER_AUTO=y # # I2C Hardware Bus support # # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_GPIO is not set CONFIG_I2C_MSM=y # CONFIG_I2C_OCORES is not set # CONFIG_I2C_SIMTEC is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_STUB is not set # # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_TSL2550 is not set CONFIG_SENSORS_AKM8976=y CONFIG_SENSORS_PCA963X=y CONFIG_SENSORS_MT9T013=y # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set CONFIG_SPI=y # CONFIG_SPI_DEBUG is not set CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # # CONFIG_SPI_BITBANG is not set # CONFIG_SPI_GPIO is not set # # SPI Protocol Masters # # CONFIG_SPI_SPIDEV is not set # CONFIG_SPI_TLE62X0 is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set # CONFIG_BATTERY_BQ27x00 is not set # CONFIG_BATTERY_MAX17040 is not set # CONFIG_HWMON is not set # CONFIG_THERMAL is not set # CONFIG_THERMAL_HWMON is not set # CONFIG_WATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_TWL4030_CORE is not set # CONFIG_MFD_TMIO is not set # CONFIG_PMIC_DA903X is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_AB3100_CORE is not set # CONFIG_EZX_PCAP is not set # CONFIG_MEDIA_SUPPORT is not set # # Graphics support # # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_TILEBLITTING is not set # # Frame buffer hardware drivers # # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set CONFIG_FB_MSM=y # CONFIG_FB_BROADSHEET is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_FONT_6x11 is not set # CONFIG_FONT_7x14 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # CONFIG_FONT_MINI_4x6 is not set # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # CONFIG_FONT_10x18 is not set # CONFIG_LOGO is not set # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_DEBUG is not set # CONFIG_HIDRAW is not set # CONFIG_HID_PID is not set # # Special HID drivers # CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y # CONFIG_USB_ARCH_HAS_OHCI is not set # CONFIG_USB_ARCH_HAS_EHCI is not set # CONFIG_USB is not set # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # # Enable Host or Gadget support to see Inventra options # # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # CONFIG_USB_GADGET is not set # # OTG and related infrastructure # # # USB Function Support # CONFIG_USB_FUNCTION=y CONFIG_USB_FUNCTION_MSM_HSUSB=y # CONFIG_USB_FUNCTION_NULL is not set # CONFIG_USB_FUNCTION_ZERO is not set # CONFIG_USB_FUNCTION_LOOPBACK is not set CONFIG_USB_FUNCTION_ADB=y # CONFIG_USB_FUNCTION_UMS is not set CONFIG_USB_FUNCTION_MASS_STORAGE=y # CONFIG_USB_FUNCTION_DIAG is not set # CONFIG_USB_FUNCTION_ETHER is not set CONFIG_MMC=y # CONFIG_MMC_DEBUG is not set CONFIG_MMC_UNSAFE_RESUME=y CONFIG_MMC_EMBEDDED_SDIO=y CONFIG_MMC_PARANOID_SD_INIT=y # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=y # CONFIG_MMC_BLOCK_BOUNCE is not set CONFIG_MMC_BLOCK_PARANOID_RESUME=y # CONFIG_SDIO_UART is not set # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # # CONFIG_MMC_SDHCI is not set # CONFIG_MMC_SPI is not set CONFIG_MMC_MSM7X00A=y # CONFIG_MMC_MSM7X00A_RESUME_IN_WQ is not set # CONFIG_MEMSTICK is not set # CONFIG_ACCESSIBILITY is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # CONFIG_LEDS_PCA9532 is not set CONFIG_LEDS_GPIO=y CONFIG_LEDS_GPIO_PLATFORM=y # CONFIG_LEDS_LP5521 is not set CONFIG_LEDS_CPLD=y # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_DAC124S085 is not set # CONFIG_LEDS_BD2802 is not set # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set # CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set # CONFIG_LEDS_TRIGGER_SLEEP is not set # # iptables trigger is under Netfilter config (LED target) # CONFIG_SWITCH=y CONFIG_SWITCH_GPIO=y CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # # CONFIG_RTC_INTF_SYSFS is not set # CONFIG_RTC_INTF_PROC is not set # CONFIG_RTC_INTF_DEV is not set CONFIG_RTC_INTF_ALARM=y # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8581 is not set # CONFIG_RTC_DRV_RX8025 is not set # # SPI RTC drivers # # CONFIG_RTC_DRV_M41T94 is not set # CONFIG_RTC_DRV_DS1305 is not set # CONFIG_RTC_DRV_DS1390 is not set # CONFIG_RTC_DRV_MAX6902 is not set # CONFIG_RTC_DRV_R9701 is not set # CONFIG_RTC_DRV_RS5C348 is not set # CONFIG_RTC_DRV_DS3234 is not set # # Platform RTC drivers # # CONFIG_RTC_DRV_CMOS is not set # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # CONFIG_RTC_DRV_MSM7X00A=y # CONFIG_DMADEVICES is not set # CONFIG_AUXDISPLAY is not set # CONFIG_REGULATOR is not set # CONFIG_UIO is not set CONFIG_STAGING=y # CONFIG_STAGING_EXCLUDE_BUILD is not set # CONFIG_MEILHAUS is not set # CONFIG_ECHO is not set # CONFIG_COMEDI is not set # # Android # CONFIG_ANDROID=y CONFIG_ANDROID_BINDER_IPC=y CONFIG_ANDROID_LOGGER=y CONFIG_ANDROID_RAM_CONSOLE=y CONFIG_ANDROID_RAM_CONSOLE_ENABLE_VERBOSE=y CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION=y CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_DATA_SIZE=128 CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_ECC_SIZE=16 CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_SYMBOL_SIZE=8 CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_POLYNOMIAL=0x11d # CONFIG_ANDROID_RAM_CONSOLE_EARLY_INIT is not set CONFIG_ANDROID_TIMED_OUTPUT=y CONFIG_ANDROID_TIMED_GPIO=y CONFIG_ANDROID_LOW_MEMORY_KILLER=y # CONFIG_DST is not set # CONFIG_POHMELFS is not set # CONFIG_B3DFG is not set # CONFIG_PLAN9AUTH is not set # CONFIG_HECI is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4_FS is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y # CONFIG_DNOTIFY is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y # CONFIG_MSDOS_FS is not set CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_YAFFS_FS=y CONFIG_YAFFS_YAFFS1=y # CONFIG_YAFFS_9BYTE_TAGS is not set # CONFIG_YAFFS_DOES_ECC is not set CONFIG_YAFFS_YAFFS2=y CONFIG_YAFFS_AUTO_YAFFS2=y # CONFIG_YAFFS_DISABLE_LAZY_LOAD is not set # CONFIG_YAFFS_DISABLE_WIDE_TNODES is not set # CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED is not set CONFIG_YAFFS_SHORT_NAMES_IN_RAM=y # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # CONFIG_NILFS2_FS is not set CONFIG_NETWORK_FILESYSTEMS=y # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # CONFIG_DLM is not set # # Kernel hacking # CONFIG_PRINTK_TIME=y CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_DETECT_HUNG_TASK=y # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_KMEMLEAK is not set CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y CONFIG_DEBUG_VM=y # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_MEMORY_INIT is not set # CONFIG_DEBUG_LIST is not set CONFIG_DEBUG_SG=y # CONFIG_DEBUG_NOTIFIERS is not set CONFIG_BOOT_PRINTK_DELAY=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_CPU_STALL_DETECTOR is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_LATENCYTOP is not set # CONFIG_PAGE_POISONING is not set CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_TRACING_SUPPORT=y # CONFIG_FTRACE is not set # CONFIG_DYNAMIC_DEBUG is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set CONFIG_ARM_UNWIND=y # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_LL is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITYFS is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y # # Crypto core or helper # # CONFIG_CRYPTO_FIPS is not set CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set CONFIG_CRYPTO_WORKQUEUE=y # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=y # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_XTS is not set # # Hash modes # # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_XCBC is not set # # Digest # # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_MD4 is not set # CONFIG_CRYPTO_MD5 is not set # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set # CONFIG_CRYPTO_SHA1 is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_ARC4=y # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_DES is not set # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_TWOFISH_COMMON=y # # Compression # # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_ZLIB is not set # CONFIG_CRYPTO_LZO is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_HW=y # CONFIG_BINARY_PRINTF is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_LAST_BIT=y CONFIG_CRC_CCITT=y # CONFIG_CRC16 is not set # CONFIG_CRC_T10DIF is not set # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_DECOMPRESS_GZIP=y CONFIG_REED_SOLOMON=y CONFIG_REED_SOLOMON_ENC8=y CONFIG_REED_SOLOMON_DEC8=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_NLATTR=y ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 20:24 ` Brian Swetland ` (2 preceding siblings ...) 2009-06-10 21:37 ` Pavel Machek @ 2009-06-11 9:32 ` Mark Brown 3 siblings, 0 replies; 167+ messages in thread From: Mark Brown @ 2009-06-11 9:32 UTC (permalink / raw) To: Brian Swetland Cc: Russell King - ARM Linux, Pavel Machek, kernel list, linux-arm-kernel, san, rlove On Wed, Jun 10, 2009 at 01:24:42PM -0700, Brian Swetland wrote: > 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. Perhaps you might find common cause with the OMAP guys? They've got similar issues to resolve with things like the DSPs on OMAPs. > 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... Is there more driver stuff which you could get upstream? I'd have expected that it should be easier to get drivers in than the more invasive changes like wakelocks. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-10 19:48 ` Russell King - ARM Linux 2009-06-10 20:24 ` Brian Swetland @ 2009-06-11 7:02 ` David Miller 2009-06-11 7:18 ` Russell King - ARM Linux ` (3 more replies) 1 sibling, 4 replies; 167+ messages in thread From: David Miller @ 2009-06-11 7:02 UTC (permalink / raw) To: linux; +Cc: pavel, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove From: Russell King - ARM Linux <linux@arm.linux.org.uk> Date: Wed, 10 Jun 2009 20:48:52 +0100 > In short not as far as I know, and I'm very disappointed with the state > of affairs with google. And of course, this whole android situation has absolutely nothing to do with how much of a pain in that ass you are to deal with as ARM maintainer. Absolutely nothing, right? :-( ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 7:02 ` David Miller @ 2009-06-11 7:18 ` Russell King - ARM Linux 2009-06-11 7:37 ` Pavel Machek ` (2 subsequent siblings) 3 siblings, 0 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 7:18 UTC (permalink / raw) To: David Miller, Andrew Morton Cc: pavel, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove On Thu, Jun 11, 2009 at 12:02:19AM -0700, David Miller wrote: > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > Date: Wed, 10 Jun 2009 20:48:52 +0100 > > > In short not as far as I know, and I'm very disappointed with the state > > of affairs with google. > > And of course, this whole android situation has absolutely nothing to > do with how much of a pain in that ass you are to deal with as ARM > maintainer. > > Absolutely nothing, right? It's a shame you don't talk to Andrew Morton more - he'll tell you exactly what the issue is here. You've already demonstrated that you're a total idiot over the device tree stuff, and now you're just continuing that approach. Now stop poking for idiotic nose in where its only function is to make trouble and crawl back under whatever rock you came from. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 7:02 ` David Miller 2009-06-11 7:18 ` Russell King - ARM Linux @ 2009-06-11 7:37 ` Pavel Machek 2009-06-11 10:00 ` Mark Brown ` (2 more replies) 2009-06-11 17:53 ` Marek Vasut 2009-06-13 0:38 ` Ben Dooks 3 siblings, 3 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-11 7:37 UTC (permalink / raw) To: David Miller Cc: linux, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove On Thu 2009-06-11 00:02:19, David Miller wrote: > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > Date: Wed, 10 Jun 2009 20:48:52 +0100 > > > In short not as far as I know, and I'm very disappointed with the state > > of affairs with google. > > And of course, this whole android situation has absolutely nothing to > do with how much of a pain in that ass you are to deal with as ARM > maintainer. Well, linux-arm-devel being subscribers-only and patch management system that needs special headers certainly does not help here :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 7:37 ` Pavel Machek @ 2009-06-11 10:00 ` Mark Brown 2009-06-11 10:34 ` Russell King - ARM Linux 2009-06-11 17:10 ` Ben Dooks 2 siblings, 0 replies; 167+ messages in thread From: Mark Brown @ 2009-06-11 10:00 UTC (permalink / raw) To: Pavel Machek Cc: David Miller, linux, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote: > Well, linux-arm-devel being subscribers-only and patch management > system that needs special headers certainly does not help here :-(. For the more actively developed subarchitectures code actually flows in via git these days - the subarchitecture maintainers send pull requests. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 7:37 ` Pavel Machek 2009-06-11 10:00 ` Mark Brown @ 2009-06-11 10:34 ` Russell King - ARM Linux 2009-06-11 10:44 ` David Miller ` (3 more replies) 2009-06-11 17:10 ` Ben Dooks 2 siblings, 4 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 10:34 UTC (permalink / raw) To: Pavel Machek Cc: David Miller, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote: > On Thu 2009-06-11 00:02:19, David Miller wrote: > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > Date: Wed, 10 Jun 2009 20:48:52 +0100 > > > > > In short not as far as I know, and I'm very disappointed with the state > > > of affairs with google. > > > > And of course, this whole android situation has absolutely nothing to > > do with how much of a pain in that ass you are to deal with as ARM > > maintainer. > > Well, linux-arm-devel being subscribers-only and patch management > system that needs special headers certainly does not help here :-(. That's got nothing to do with it. You're just using that as an excuse to bash me with. The real problem with android is that their efforts to mainline the code are very sparse - I seem to recollect that there were two attempts about a year or more apart, the first of which was relatively painless and the second which was more problematical (partly caused because they'd left it soo long since the last submission.) Around the time of their second submission, someone who used to be more active in the ARM community started making accusations against Google for "throwing their code over the wall and disappearing" and "claiming that their code is on kernel.org now". They went on to say (and I'm quoting) "i don't think they give a shit about what you or i have to say about it". Having dealt with Brian's kernel submissions and provided feedback on them, I took issue with those comments because that wasn't how I (or even akpm) saw the situation. The result of that was the person making those accusations fell out with me. However, as a result of the complete lack of effort to update patches as a result of feedback coupled with my lack of bandwidth to review complex code implementing things like cross-bridge APIs (eg, ARM <-> DSP communications channels), Brian basically gave up trying to get stuff into mainline. Now, ask yourself this question: why should I have to be the one to review things like ARM <-> DSP communication channel code? Hint: I don't want to because I know nothing about the subject. Where should I send these people to get such code reviewed? No idea, there seems to be no one _anywhere_ who would seem to be interested in it. Andrew tried to resolve this review problem by getting some co-operation between various members of the ARM community - so that two or three people with large code bases would do mutual reviews and gain from each others efforts. The result of that was... precisely nothing. No interest in lifting a finger to help someone else. So, to go pointing blame at various things you don't like is not only naieve but down right idiotic and stupid. I suggest you stop your personal (and as demonstrated in other emails to me over your Zaurus problems) persistent rmk bashing agenda and wake up to reality. And now think whether you are part of the problem - when you load me up with your Zaurus problems, a platform which I know precisely zilch about, and I have to waste time fighting tooth and nail to get you to talk to people who might be able to help you. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 10:34 ` Russell King - ARM Linux @ 2009-06-11 10:44 ` David Miller 2009-06-11 10:47 ` David Miller 2009-06-11 10:55 ` Russell King - ARM Linux 2009-06-11 11:12 ` Brian Swetland ` (2 subsequent siblings) 3 siblings, 2 replies; 167+ messages in thread From: David Miller @ 2009-06-11 10:44 UTC (permalink / raw) To: linux; +Cc: pavel, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove From: Russell King - ARM Linux <linux@arm.linux.org.uk> Date: Thu, 11 Jun 2009 11:34:57 +0100 > Around the time of their second submission, someone who used to be more > active in the ARM community started making accusations against Google > for "throwing their code over the wall and disappearing" and "claiming > that their code is on kernel.org now". They went on to say (and I'm > quoting) "i don't think they give a shit about what you or i have to > say about it". > > Having dealt with Brian's kernel submissions and provided feedback on > them, I took issue with those comments because that wasn't how I (or even > akpm) saw the situation. The result of that was the person making those > accusations fell out with me. You should give full disclosure and say where and in what context those statements were made. They were made in IRC and people say all kinds of random things on IRC when they're in a foul mood, are piss drunk, or simply got up on the wrong side of the bed that day. It's not like this was stated on a public mailing list or on some public web site. It was IRC for heaven's sake. And then then YOU took it to private email with various people. And it's a certainty that you're volatile way of interacting with people does nothing to help in situations like that. I can just imagine how you handled discussing things with that person at that moment in time, and how things likely escalated because of your attitude problem. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 10:44 ` David Miller @ 2009-06-11 10:47 ` David Miller 2009-06-11 11:05 ` Russell King - ARM Linux 2009-06-11 10:55 ` Russell King - ARM Linux 1 sibling, 1 reply; 167+ messages in thread From: David Miller @ 2009-06-11 10:47 UTC (permalink / raw) To: linux; +Cc: pavel, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove From: David Miller <davem@davemloft.net> Date: Thu, 11 Jun 2009 03:44:21 -0700 (PDT) > It's not like this was stated on a public mailing list or on some > public web site. It was IRC for heaven's sake. And BTW something you said in the same IRC arena shortly thereafterwards: <rmk> in hind sight, xxxxxxx was effectively right when he said on here a while ago <rmk> 22:34 <xxxxxx> jejb: google also just pretty much threw their ARM code over the wall and disappeared There you are quoting this person, the same way you are quoting him here and demeaning him in this very email thread. And yet there you are agreeing with him. You're such a hypocrite Russell. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 10:47 ` David Miller @ 2009-06-11 11:05 ` Russell King - ARM Linux 2009-06-11 11:11 ` David Miller 0 siblings, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 11:05 UTC (permalink / raw) To: David Miller; +Cc: pavel, linux-kernel, linux-arm-kernel, swetland, san, rlove On Thu, Jun 11, 2009 at 03:47:32AM -0700, David Miller wrote: > From: David Miller <davem@davemloft.net> > Date: Thu, 11 Jun 2009 03:44:21 -0700 (PDT) > > > It's not like this was stated on a public mailing list or on some > > public web site. It was IRC for heaven's sake. > > And BTW something you said in the same IRC arena shortly > thereafterwards: > > <rmk> in hind sight, xxxxxxx was effectively right when he said on here a while ago > <rmk> 22:34 <xxxxxx> jejb: google also just pretty much threw their ARM code over the wall and disappeared > > There you are quoting this person, the same way you are quoting him > here and demeaning him in this very email thread. > > And yet there you are agreeing with him. > > You're such a hypocrite Russell. I'm sorry, that's the precise same channel and network which those comments were first made by the person who made them. And now read precisely what I said rather than twisting it to your own agenda. Particularly the bit where I wrote "in hind sight". There's lots of things everyone would do differently if they knew what happens in the future. Unfortunately, we live in a causal universe where we can't predict with certaintly what will happen. At the time the comments were first made, Brian _was_ making an effort, and the comments seemed to be unfounded accusations. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:05 ` Russell King - ARM Linux @ 2009-06-11 11:11 ` David Miller 0 siblings, 0 replies; 167+ messages in thread From: David Miller @ 2009-06-11 11:11 UTC (permalink / raw) To: linux; +Cc: pavel, linux-kernel, linux-arm-kernel, swetland, san, rlove From: Russell King - ARM Linux <linux@arm.linux.org.uk> Date: Thu, 11 Jun 2009 12:05:39 +0100 > On Thu, Jun 11, 2009 at 03:47:32AM -0700, David Miller wrote: >> <rmk> in hind sight, xxxxxxx was effectively right when he said on here a while ago >> <rmk> 22:34 <xxxxxx> jejb: google also just pretty much threw their ARM code over the wall and disappeared ... > I'm sorry, that's the precise same channel and network which those > comments were first made by the person who made them. > > And now read precisely what I said rather than twisting it to your own > agenda. You're the one who can't read. The words "was" and "when" were used, which indicate a point in time (not only for the statement but also when it applies). You didn't say "his comments back then actually do apply now". But it may be convenient for you to portray things this way. Russell, if you only knew how people speak of you in private.... ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 10:44 ` David Miller 2009-06-11 10:47 ` David Miller @ 2009-06-11 10:55 ` Russell King - ARM Linux 2009-06-11 11:04 ` David Miller 1 sibling, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 10:55 UTC (permalink / raw) To: David Miller Cc: pavel, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove On Thu, Jun 11, 2009 at 03:44:21AM -0700, David Miller wrote: > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > Date: Thu, 11 Jun 2009 11:34:57 +0100 > > Around the time of their second submission, someone who used to be more > > active in the ARM community started making accusations against Google > > for "throwing their code over the wall and disappearing" and "claiming > > that their code is on kernel.org now". They went on to say (and I'm > > quoting) "i don't think they give a shit about what you or i have to > > say about it". > > > > Having dealt with Brian's kernel submissions and provided feedback on > > them, I took issue with those comments because that wasn't how I (or even > > akpm) saw the situation. The result of that was the person making those > > accusations fell out with me. > > You should give full disclosure and say where and in what context > those statements were made. Yes, the bits I paraphrased above in quotes were from IRC, and I have no problem saying so. What I don't want to do is to quote precisely what was said or provide the identity of the person making those statements on a public mailing list (certainly not without permission.) > And then then YOU took it to private email with various people. No, you are just totally wrong there. It was ALREADY in private *constructive* email between Andrew and myself at the time the comments were made, with Andrew trying to find a solution to allow review of the code to take place. Now, you can carry on blaming me for the android situation in your own world of lies, or you can wake up to reality and find out some reliable facts from someone like Andrew Morton before continuing to assign blame and malace. Which will it be? ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 10:55 ` Russell King - ARM Linux @ 2009-06-11 11:04 ` David Miller 0 siblings, 0 replies; 167+ messages in thread From: David Miller @ 2009-06-11 11:04 UTC (permalink / raw) To: linux; +Cc: pavel, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove From: Russell King - ARM Linux <linux@arm.linux.org.uk> Date: Thu, 11 Jun 2009 11:55:51 +0100 > Now, you can carry on blaming me for the android situation in your own > world of lies, or you can wake up to reality and find out some reliable > facts from someone like Andrew Morton before continuing to assign blame > and malace. Which will it be? Oh Russell, I had an extensive discussion with Andrew when this whole situation happened. And I was pissed as hell because this person was one of my best networking contributors so I knew that you're judgments and assesments of him were not representative of him as a person nor as a developer. And therefore I told Andrew how much I disagreed with what you were doing and how the way you generally handle things is generally upsetting to me. He definitely did not flat out dismiss the things I was saying nor my opinions in this matter. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 10:34 ` Russell King - ARM Linux 2009-06-11 10:44 ` David Miller @ 2009-06-11 11:12 ` Brian Swetland 2009-06-11 11:18 ` Russell King - ARM Linux 2009-06-11 11:18 ` Pavel Machek 2009-06-11 11:34 ` Alan Cox 3 siblings, 1 reply; 167+ messages in thread From: Brian Swetland @ 2009-06-11 11:12 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, David Miller, linux-kernel, linux-arm-kernel, ibm, san, rlove On Thu, Jun 11, 2009 at 3:34 AM, Russell King - ARM Linux<linux@arm.linux.org.uk> wrote: > > However, as a result of the complete lack of effort to update patches > as a result of feedback coupled with my lack of bandwidth to review > complex code implementing things like cross-bridge APIs (eg, ARM <-> > DSP communications channels), Brian basically gave up trying to get > stuff into mainline. Well, "gave up" feels a little final to me. We still would like to get stuff upstream. I will admit to finding the process discouraging at times, but a larger part of it is just finding the time to sit down, tidy up the current state of our world against the tip-of-tree on mainline, and push out another round of patches. I'm hoping to find some larger windows of time to devote to this later this year. Since we also have to maintain a stable, shippable tree for products going out the door and to provide baseline support for the platform, we end up having to maintain multiple trees -- it's obviously not realistic to expect that we're going to get 30000-50000 lines of new code reviewed quickly, but we do need all the functionality there to actually support shipping devices. When time gets tight (more often than I like), the towards-mainline stuff gets backburnered. Obviously, we suffer for this in that we end up having more to rebase every time we move forward, so it would be to our benefit to get better at pushing this stuff upstream and reduce the delta between mainline and our tree. > Now, ask yourself this question: why should I have to be the one to > review things like ARM <-> DSP communication channel code? Hint: I > don't want to because I know nothing about the subject. Where should > I send these people to get such code reviewed? No idea, there seems > to be no one _anywhere_ who would seem to be interested in it. The drivers/staging system looks like it has some potential to help here. Greg has been scooping our generic code into there recently, and I know Arve's seen patches for binder issues go by, etc. It feels (if I'm understanding the intent) a bit more like the model I'm more used to (get a relatively clean piece of code that is functional checked in, and then refine it). > Andrew tried to resolve this review problem by getting some co-operation > between various members of the ARM community - so that two or three > people with large code bases would do mutual reviews and gain from > each others efforts. The result of that was... precisely nothing. No > interest in lifting a finger to help someone else. I think Andrew's idea is a good one, but we just haven't had the time to try to sort this out. I'll have to see what we can do here. Recently, we've been involved in omap3 work as well and have been interacting more with folks in the omap kernel community as a result. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:12 ` Brian Swetland @ 2009-06-11 11:18 ` Russell King - ARM Linux 2009-06-11 11:22 ` David Miller 2009-06-11 11:42 ` Brian Swetland 0 siblings, 2 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 11:18 UTC (permalink / raw) To: Brian Swetland Cc: Pavel Machek, David Miller, linux-kernel, linux-arm-kernel, ibm, san, rlove On Thu, Jun 11, 2009 at 04:12:39AM -0700, Brian Swetland wrote: > I think Andrew's idea is a good one, but we just haven't had the time > to try to sort this out. I'll have to see what we can do here. > Recently, we've been involved in omap3 work as well and have been > interacting more with folks in the omap kernel community as a result. Brian, Can you clear up this thread, which seems to be descending into absurdness. David Miller seems to be of the opinion that I was rude or otherwise insulting to you. Was this the case? Was the only problem you had interacting with me to do with the time it takes to receive feedback on patches which you'd submitted and getting them merged? I believe that caused you to question several times whether you were doing things in the right way. Thanks. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:18 ` Russell King - ARM Linux @ 2009-06-11 11:22 ` David Miller 2009-06-11 11:49 ` Russell King - ARM Linux 2009-06-11 11:42 ` Brian Swetland 1 sibling, 1 reply; 167+ messages in thread From: David Miller @ 2009-06-11 11:22 UTC (permalink / raw) To: linux; +Cc: swetland, pavel, linux-kernel, linux-arm-kernel, ibm, san, rlove From: Russell King - ARM Linux <linux@arm.linux.org.uk> Date: Thu, 11 Jun 2009 12:18:22 +0100 > Can you clear up this thread, which seems to be descending into absurdness. > > David Miller seems to be of the opinion that I was rude or otherwise > insulting to you. Was this the case? Getting one selected person's opinion is not indicative of your general behavior towards people and how you tend to handle ARM maintainence specifically. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:22 ` David Miller @ 2009-06-11 11:49 ` Russell King - ARM Linux 2009-06-11 12:00 ` David Miller 0 siblings, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 11:49 UTC (permalink / raw) To: David Miller; +Cc: swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 04:22:26AM -0700, David Miller wrote: > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > Date: Thu, 11 Jun 2009 12:18:22 +0100 > > > Can you clear up this thread, which seems to be descending into absurdness. > > > > David Miller seems to be of the opinion that I was rude or otherwise > > insulting to you. Was this the case? > > Getting one selected person's opinion is not indicative of your > general behavior towards people and how you tend to handle ARM > maintainence specifically. I can not keep up with the number of patches that need to be reviewed and ultimately merged. I know this, and I freely admit it, and I have done so on many occasions. I also admit that there are those whom I don't get on with, to varying degrees. This I am ashamed about, and I try to avoid future occurances repeating themselves by various measures, some of which have not had the desired outcome. I think that's all public knowledge. However, what I'm trying to point out, and you're going out of your way to twist, is that only the former is an issue where Brian is concerned. Brian has now replied and we finally have the issue out in the open. So, can you now drop the shovel (please avoid your foot) and start dealing with the facts? Thanks. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:49 ` Russell King - ARM Linux @ 2009-06-11 12:00 ` David Miller 2009-06-11 12:38 ` Russell King - ARM Linux 0 siblings, 1 reply; 167+ messages in thread From: David Miller @ 2009-06-11 12:00 UTC (permalink / raw) To: linux; +Cc: swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove From: Russell King - ARM Linux <linux@arm.linux.org.uk> Date: Thu, 11 Jun 2009 12:49:12 +0100 > I can not keep up with the number of patches that need to be > reviewed and ultimately merged. I know this, and I freely admit it, > and I have done so on many occasions. Then split up the responsibilities to other people instead of being the choke point. Controlling everything isn't so important. Or, alternatively, experiment with tools that could potentially make you more efficient (patchwork has worked wonders for me). Anything other than simply leaving things as they are... ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:00 ` David Miller @ 2009-06-11 12:38 ` Russell King - ARM Linux 2009-06-11 12:54 ` Alan Cox ` (4 more replies) 0 siblings, 5 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 12:38 UTC (permalink / raw) To: David Miller; +Cc: swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > Date: Thu, 11 Jun 2009 12:49:12 +0100 > > > I can not keep up with the number of patches that need to be > > reviewed and ultimately merged. I know this, and I freely admit it, > > and I have done so on many occasions. > > Then split up the responsibilities to other people instead of being > the choke point. Controlling everything isn't so important. Don't you think that I've been trying to get other people to be more involved? - I've been pushing people to send patches to the relevent mailing list(s) and maintainer(s) for years. - I've been pushing people to send their ARM patches to the ARM mailing list rather than directly into the patch system for review (it even has a comment telling people this) so that others can get involved in reviewing them, and sharing that work load. Do you think either have been anywhere near successful? For the most part, the answer is no. People concentrate on their own areas, and won't look at someone with a new class of platforms (eg, the STMP or W90x900 stuff). I'd absolutely love it if the review load could be shared, but for the most part it just doesn't happen. Everyone's far too busy with their own stuff to help out (and that's a reason that they'll give if tackled head on about it.) As I've already said, akpm tried to setup a mutual review between several ARM folk, but as far as I'm aware, it has so far been unsuccessful (exactly why I don't know.) So to somehow level an accusation at me that I'm tightly controlling this stuff is way off the mark. I've been trying to get greater participation but it's just not happening. > Or, alternatively, experiment with tools that could potentially make > you more efficient (patchwork has worked wonders for me). If patchwork can replace what my patch system does for me (which is basically to help ensure that patches don't get lost which need applying - that's different from logging every single patch) then I'll gladly look at it. It will mean that some of the sanity checks on the patch content, which happen automatically with the patch system, will need to be done manually. If patchwork just gathers up every patch which has ever been seen on a mailing list, then stuff will get lost at a higher rate than today and it will have a negative impact. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:38 ` Russell King - ARM Linux @ 2009-06-11 12:54 ` Alan Cox 2009-06-11 13:12 ` Russell King - ARM Linux ` (3 more replies) 2009-06-11 13:21 ` Pavel Machek ` (3 subsequent siblings) 4 siblings, 4 replies; 167+ messages in thread From: Alan Cox @ 2009-06-11 12:54 UTC (permalink / raw) To: Russell King - ARM Linux Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove > For the most part, the answer is no. People concentrate on their own > areas, and won't look at someone with a new class of platforms (eg, > the STMP or W90x900 stuff). That would appear to be rational behaviour on their part. > As I've already said, akpm tried to setup a mutual review between > several ARM folk, but as far as I'm aware, it has so far been > unsuccessful (exactly why I don't know.) Because its not rational economic behaviour on their part ? > If patchwork just gathers up every patch which has ever been seen on > a mailing list, then stuff will get lost at a higher rate than today > and it will have a negative impact. Stop trying to stand in the middle of the motorway and directing traffic. You will get run over if you do that even if you are the best person on the planet at that job. The problem is perfectly sortable with a bit of experimenting. This is a first suggestion - it might not work but it can't make things much worse and if the current system doesn't work the first process to fix it is to change things. Make your tree the core ARM code only, any other patches you don't accept. Aggressively push stuff out to platform code, and if people want to change core code "because our platform is different" make them extract it into the platform layer not carry it in the core bits. Nominate a bunch of people for the main ARM platforms. What they put into their platform specific trees goes direct from them to -next and if they trash their own platform thats their problem (and they can come to you for advice ;)) Leave it to the platform people to push their driver code through the right channels. You may be ten times better than them at the job, but there are a hundred of them. Each of the teams now has an economic focus that is in accord with what they need to do "Get our platform working well", and as a secondary effect if one of the teams accidentally messes up another they've both got economic incentives to fix their shared problem. For core code issues you can just follow Linus usual approach of "I'll merge this when you've all stopped fighting and agreed a solution" (again you'll note this creates the correct incentives). Which all in all might give you a bit more time to go gliding rather than running around like a lunatic trying to herd cats. Alan ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:54 ` Alan Cox @ 2009-06-11 13:12 ` Russell King - ARM Linux 2009-06-11 16:26 ` Kevin Hilman 2009-07-22 17:54 ` ARM platform trees (was: Re: HTC Dream aka. t-mobile g1 support) Kevin Hilman 2009-06-11 13:18 ` HTC Dream aka. t-mobile g1 support Brian Swetland ` (2 subsequent siblings) 3 siblings, 2 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 13:12 UTC (permalink / raw) To: Alan Cox Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote: > Make your tree the core ARM code only, any other patches you don't > accept. Aggressively push stuff out to platform code, and if people want > to change core code "because our platform is different" make them extract > it into the platform layer not carry it in the core bits. I'm all for giving this a try after this merge window is over. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 13:12 ` Russell King - ARM Linux @ 2009-06-11 16:26 ` Kevin Hilman 2009-06-11 16:57 ` Nicolas Pitre 2009-07-22 17:54 ` ARM platform trees (was: Re: HTC Dream aka. t-mobile g1 support) Kevin Hilman 1 sibling, 1 reply; 167+ messages in thread From: Kevin Hilman @ 2009-06-11 16:26 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote: >> Make your tree the core ARM code only, any other patches you don't >> accept. Aggressively push stuff out to platform code, and if people want >> to change core code "because our platform is different" make them extract >> it into the platform layer not carry it in the core bits. > > I'm all for giving this a try after this merge window is over. Speaking as maintainer of one ARM subarch (davinci) and active contributor to another (OMAP), I would gladly give this a try as well. Kevin ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 16:26 ` Kevin Hilman @ 2009-06-11 16:57 ` Nicolas Pitre 0 siblings, 0 replies; 167+ messages in thread From: Nicolas Pitre @ 2009-06-11 16:57 UTC (permalink / raw) To: Kevin Hilman Cc: Russell King - ARM Linux, Alan Cox, David Miller, swetland, pavel, lkml, linux-arm-kernel, san, rlove On Thu, 11 Jun 2009, Kevin Hilman wrote: > Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > > > On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote: > >> Make your tree the core ARM code only, any other patches you don't > >> accept. Aggressively push stuff out to platform code, and if people want > >> to change core code "because our platform is different" make them extract > >> it into the platform layer not carry it in the core bits. > > > > I'm all for giving this a try after this merge window is over. > > Speaking as maintainer of one ARM subarch (davinci) and active > contributor to another (OMAP), I would gladly give this a try as well. Speaking as maintainer of a couple other ARM subarchs (Orion, Kirkwood, MV78xx0, ...) I would gladly accept full responsibility (and blame) for them as well. I think Russell could avoid astraining to himself full review for every patch concerning those that I send his way, and merely look at the diffstat to be sure I'm not crapping onto the core ARM code. Linus certainly doesn't do much more than that on his end already. It's been a couple merge windows now that RMK started accepting git pull requests from a couple people in addition to his patch system, and that has worked pretty well overall. Nicolas ^ permalink raw reply [flat|nested] 167+ messages in thread
* ARM platform trees (was: Re: HTC Dream aka. t-mobile g1 support) 2009-06-11 13:12 ` Russell King - ARM Linux 2009-06-11 16:26 ` Kevin Hilman @ 2009-07-22 17:54 ` Kevin Hilman 2009-07-22 20:55 ` Russell King - ARM Linux 1 sibling, 1 reply; 167+ messages in thread From: Kevin Hilman @ 2009-07-22 17:54 UTC (permalink / raw) To: Alan Cox Cc: Russell King - ARM Linux, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote: >> Make your tree the core ARM code only, any other patches you don't >> accept. Aggressively push stuff out to platform code, and if people want >> to change core code "because our platform is different" make them extract >> it into the platform layer not carry it in the core bits. > > I'm all for giving this a try after this merge window is over. So, in preparation for the next merge window... Is there an official way for ARM platform maintainers like myself to get stuff merged via Linus' tree? Is simply sending a pull request to Linus/LKML all that's required? For myself, I have the pending stuff queued up in a 'for-next' branch that is included into linux-next already. Is anything else required? Kevin ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: ARM platform trees (was: Re: HTC Dream aka. t-mobile g1 support) 2009-07-22 17:54 ` ARM platform trees (was: Re: HTC Dream aka. t-mobile g1 support) Kevin Hilman @ 2009-07-22 20:55 ` Russell King - ARM Linux 0 siblings, 0 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-07-22 20:55 UTC (permalink / raw) To: Kevin Hilman Cc: Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Wed, Jul 22, 2009 at 10:54:06AM -0700, Kevin Hilman wrote: > Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > > > On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote: > >> Make your tree the core ARM code only, any other patches you don't > >> accept. Aggressively push stuff out to platform code, and if people want > >> to change core code "because our platform is different" make them extract > >> it into the platform layer not carry it in the core bits. > > > > I'm all for giving this a try after this merge window is over. > > So, in preparation for the next merge window... > > Is there an official way for ARM platform maintainers like myself to > get stuff merged via Linus' tree? Is simply sending a pull request to > Linus/LKML all that's required? Yup. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:54 ` Alan Cox 2009-06-11 13:12 ` Russell King - ARM Linux @ 2009-06-11 13:18 ` Brian Swetland 2009-06-11 13:21 ` Tony Lindgren 2009-06-11 13:28 ` Russell King - ARM Linux 3 siblings, 0 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-11 13:18 UTC (permalink / raw) To: Alan Cox Cc: Russell King - ARM Linux, David Miller, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 5:54 AM, Alan Cox<alan@lxorguk.ukuu.org.uk> wrote: > > Make your tree the core ARM code only, any other patches you don't > accept. Aggressively push stuff out to platform code, and if people want > to change core code "because our platform is different" make them extract > it into the platform layer not carry it in the core bits. > > Nominate a bunch of people for the main ARM platforms. What they put into > their platform specific trees goes direct from them to -next and if they > trash their own platform thats their problem (and they can come to you > for advice ;)) > > Leave it to the platform people to push their driver code through the > right channels. This would seem to address a lot of the scalability issues, and from what I can tell, it's pretty hard for somebody mucking stuff up in arch/arm/mach-something/... to break arch/arm/mach-otherthing/... I'd be thrilled to get the msm stuff in to the main tree and deal with patches submitted against it (and the android stuff in staging seems to show that people will start submitting patches against things if it's in the mainline -- for example the binder patches that have turned up, etc). As far as what we're maintaining in the android-msm tree, there's: generic android drivers -- most of which are already in staging thanks to Greg arch/arm/mach-msm/... -- 7k (and soon 8k) SoC support various msm drivers -- could be submitted via drivers/staging and the usual review process a couple small generic arm patches -- stuff that we should be discussing in lakml some generic linux patches -- Arve's pretty good about sending these to lkml as they happen Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:54 ` Alan Cox 2009-06-11 13:12 ` Russell King - ARM Linux 2009-06-11 13:18 ` HTC Dream aka. t-mobile g1 support Brian Swetland @ 2009-06-11 13:21 ` Tony Lindgren 2009-06-11 13:37 ` Russell King - ARM Linux 2009-06-11 13:28 ` Russell King - ARM Linux 3 siblings, 1 reply; 167+ messages in thread From: Tony Lindgren @ 2009-06-11 13:21 UTC (permalink / raw) To: Alan Cox Cc: Russell King - ARM Linux, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove * Alan Cox <alan@lxorguk.ukuu.org.uk> [090611 05:54]: > > For the most part, the answer is no. People concentrate on their own > > areas, and won't look at someone with a new class of platforms (eg, > > the STMP or W90x900 stuff). > > That would appear to be rational behaviour on their part. > > > As I've already said, akpm tried to setup a mutual review between > > several ARM folk, but as far as I'm aware, it has so far been > > unsuccessful (exactly why I don't know.) > > Because its not rational economic behaviour on their part ? > > > If patchwork just gathers up every patch which has ever been seen on > > a mailing list, then stuff will get lost at a higher rate than today > > and it will have a negative impact. Just to comment on the patchwork, we've been using p.k.o for the omap stuff for few months. It helps for sure as I can now nuke my omap inbox on regular basis without losing patches :) But even just for the omap code, we need several people dealing with them, otherwise there's just too many patches floating around. So in order to use patchwork for arm patches, it would have to be distributed to many people to make any use of it like Alan is suggesting. Otherwise it just fills up with tons of patches. > Stop trying to stand in the middle of the motorway and directing traffic. > You will get run over if you do that even if you are the best person on > the planet at that job. > > The problem is perfectly sortable with a bit of experimenting. This is a > first suggestion - it might not work but it can't make things much worse > and if the current system doesn't work the first process to fix it is to > change things. > > Make your tree the core ARM code only, any other patches you don't > accept. Aggressively push stuff out to platform code, and if people want > to change core code "because our platform is different" make them extract > it into the platform layer not carry it in the core bits. > > Nominate a bunch of people for the main ARM platforms. What they put into > their platform specific trees goes direct from them to -next and if they > trash their own platform thats their problem (and they can come to you > for advice ;)) We've done this for two merge windows now for omap patches where the patches have been posted to linux-arm-kernel, then they go into the for-next tree, and then Russell merges them in. It has worked OK, although Russell had some comments about having hard time keeping track on what he had reviewed already. > Leave it to the platform people to push their driver code through the > right channels. > > You may be ten times better than them at the job, but there are a hundred > of them. Some code Russell of course wants to review more carefully, like the omap clock code that Russell has contributed heavily on. But in general, I believe Alan's approach would help to distribute the merging, and scale it up. > Each of the teams now has an economic focus that is in accord with what > they need to do "Get our platform working well", and as a secondary > effect if one of the teams accidentally messes up another they've both > got economic incentives to fix their shared problem. For core code > issues you can just follow Linus usual approach of "I'll merge this when > you've all stopped fighting and agreed a solution" (again you'll note > this creates the correct incentives). > > Which all in all might give you a bit more time to go gliding rather than > running around like a lunatic trying to herd cats. Of course we'd still like to get Russell's comments too on the code where possible :) Tony ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 13:21 ` Tony Lindgren @ 2009-06-11 13:37 ` Russell King - ARM Linux 2009-06-11 14:00 ` Tony Lindgren 2009-06-11 14:47 ` Pavel Machek 0 siblings, 2 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 13:37 UTC (permalink / raw) To: Tony Lindgren Cc: Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 06:21:35AM -0700, Tony Lindgren wrote: > We've done this for two merge windows now for omap patches where the > patches have been posted to linux-arm-kernel, then they go into the > for-next tree, and then Russell merges them in. > > It has worked OK, although Russell had some comments about having hard > time keeping track on what he had reviewed already. Yes, as I understand it, there was a closed room discussion between several folk about how you'd handle sending your next round of patches to me. What you apparantly decided (and I'm saying this from how it appeared on the receiving end and sort-of had it confirmed by Kevin in conference) is that you'd send a patch set for me to review, I'd review it, and then you'd merge it within your git tree into a branch for me. You'd then do the same thing with the next patch set, and so forth. Eventually, near the merge window, you sent a pull request for the entire lot, by which time I looked at the list of changes and wondered whether that encompassed everything you'd asked me to review, or whether it contained extra stuff, or whether it was for something quite different, or what. So by separating the review from the merge by weeks or even months, it created additional problems. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 13:37 ` Russell King - ARM Linux @ 2009-06-11 14:00 ` Tony Lindgren 2009-06-11 14:06 ` Russell King - ARM Linux 2009-06-11 14:47 ` Pavel Machek 1 sibling, 1 reply; 167+ messages in thread From: Tony Lindgren @ 2009-06-11 14:00 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove * Russell King - ARM Linux <linux@arm.linux.org.uk> [090611 06:38]: > On Thu, Jun 11, 2009 at 06:21:35AM -0700, Tony Lindgren wrote: > > We've done this for two merge windows now for omap patches where the > > patches have been posted to linux-arm-kernel, then they go into the > > for-next tree, and then Russell merges them in. > > > > It has worked OK, although Russell had some comments about having hard > > time keeping track on what he had reviewed already. > > Yes, as I understand it, there was a closed room discussion between > several folk about how you'd handle sending your next round of patches > to me. Yes, this was to coordinate the merge conflicts that we knew were going to happen. > What you apparantly decided (and I'm saying this from how it appeared > on the receiving end and sort-of had it confirmed by Kevin in conference) > is that you'd send a patch set for me to review, I'd review it, and then > you'd merge it within your git tree into a branch for me. You'd then do > the same thing with the next patch set, and so forth. > > Eventually, near the merge window, you sent a pull request for the > entire lot, by which time I looked at the list of changes and wondered > whether that encompassed everything you'd asked me to review, or whether > it contained extra stuff, or whether it was for something quite different, > or what. Hmm, well it was what was posted to the list, and I kept piling it up into for-next as the patchsets got reviewed. > So by separating the review from the merge by weeks or even months, it > created additional problems. Yeah this can be a problem as at that point you have to pull or check the patches again if you don't trust people to send you the stuff that got posted earlier. You suggested pulling each set as they get reviewed into some omap branch in your tree, do you want to try that the next merge window? What I can easily see happening with this approach is that we end up waiting 1 - 2 weeks between each set before you pull, which can make merging painfully slow as we may have let's say five 10 patch sets to merge. Also, what do we do with the sets that you don't have time to review or don't want to review? Regards, Tony ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 14:00 ` Tony Lindgren @ 2009-06-11 14:06 ` Russell King - ARM Linux 2009-06-11 15:41 ` Tony Lindgren 2009-06-11 17:29 ` Nicolas Pitre 0 siblings, 2 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 14:06 UTC (permalink / raw) To: Tony Lindgren Cc: Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 07:00:39AM -0700, Tony Lindgren wrote: > You suggested pulling each set as they get reviewed into some omap branch > in your tree, do you want to try that the next merge window? If we're following Alan's suggestion, then as I see it you're entirely responsible for tracking what's in OMAP, getting it into linux-next and (I guess) ultimately sending Linus a pull request for it during the merge window. I just become someone who can put their oar into reviewing OMAP patches as and when. So the question is: do you want to give this a go? ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 14:06 ` Russell King - ARM Linux @ 2009-06-11 15:41 ` Tony Lindgren 2009-06-11 15:51 ` Alan Cox 2009-06-11 17:29 ` Nicolas Pitre 1 sibling, 1 reply; 167+ messages in thread From: Tony Lindgren @ 2009-06-11 15:41 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Tony Lindgren, Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 03:06:24PM +0100, Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 07:00:39AM -0700, Tony Lindgren wrote: > > You suggested pulling each set as they get reviewed into some omap branch > > in your tree, do you want to try that the next merge window? > > If we're following Alan's suggestion, then as I see it you're entirely > responsible for tracking what's in OMAP, getting it into linux-next and > (I guess) ultimately sending Linus a pull request for it during the > merge window. I just become someone who can put their oar into reviewing > OMAP patches as and when. > > So the question is: do you want to give this a go? How about this: - We post patches for review to the related lists like always - You and others ack nak as usual - If you want more time to look at something, you reply with a comment - I wait few days and if no comments, pile them into for-next - I send a pull request to you to keep things coordinated for arm - If you want something merged earlier, you let know and send pull request I'm flexible, and willing to try other things if that helps you. But I think we (as arm community) should coordinate the arm patches ourselves. So I'd rather see you pull in stuff and send it to Linus rather than bug Linus with a pull request for stuff that he may not care too much about. Cheers, Tony ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 15:41 ` Tony Lindgren @ 2009-06-11 15:51 ` Alan Cox 0 siblings, 0 replies; 167+ messages in thread From: Alan Cox @ 2009-06-11 15:51 UTC (permalink / raw) To: Tony Lindgren Cc: Russell King - ARM Linux, Tony Lindgren, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove > - I wait few days and if no comments, pile them into for-next > > - I send a pull request to you to keep things coordinated for arm You don't even need that - you can decouple that further and there are good reasons to do so to some extent. > - If you want something merged earlier, you let know and send pull > request > > I'm flexible, and willing to try other things if that helps you. > But I think we (as arm community) should coordinate the arm patches > ourselves. So I'd rather see you pull in stuff and send it to > Linus rather than bug Linus with a pull request for stuff that > he may not care too much about. The sooner its in next the sooner its really visible. Whether Russell pulls your tree for the final merge and resends it on or you do it directly is fairly irrelevant to the final merge but you maximise exposure if linux-next is directly pulling your trees and adding them after the arm tree somewhere. If you get collisions Stephen will just drop your tree while you fix it. Similarly if you end up with an overlap where your patches end up in both trees git will figure it out itself. Alan ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 14:06 ` Russell King - ARM Linux 2009-06-11 15:41 ` Tony Lindgren @ 2009-06-11 17:29 ` Nicolas Pitre 2009-06-11 21:22 ` Ryan Mallon 2009-06-12 10:26 ` Tony Lindgren 1 sibling, 2 replies; 167+ messages in thread From: Nicolas Pitre @ 2009-06-11 17:29 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Tony Lindgren, Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, 11 Jun 2009, Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 07:00:39AM -0700, Tony Lindgren wrote: > > You suggested pulling each set as they get reviewed into some omap branch > > in your tree, do you want to try that the next merge window? > > If we're following Alan's suggestion, then as I see it you're entirely > responsible for tracking what's in OMAP, getting it into linux-next and > (I guess) ultimately sending Linus a pull request for it during the > merge window. I just become someone who can put their oar into reviewing > OMAP patches as and when. I don't see things exactly that way. linux-next is a fully automated "let's dump everything together and see what is going to explode" kind of tree. There is no patch review except from those who see their code being dammaged by the blast. And it is automated in the sense that git pull operations are done automatically, even if someone deals with the merge conflicts manually afterwards. My tree can be pulled into linux-next directly or through your tree, or even through both paths in parallel and git will deal with it just fine. And at the end of the day the linux-next tree is tossed in the garbage bin anyway. I think that you, as the ARM maintainer, should continue gathering all the ARM subarchitectures into a coherent ARM tree and arbitrate conflicts when they occur. You should especially keep a tight control on the very core ARM code. But everything under arch/arm/mach-* you should let people maintaining those have control of that themselves and free yourself from that responsibility as much as possible. The current directory structure is quite indicative of where the boundaries are already. This way, if I make a mess of arch/arm/mach-orion5x/* then you just need to pass the blame straight to me. Nicolas ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 17:29 ` Nicolas Pitre @ 2009-06-11 21:22 ` Ryan Mallon 2009-06-11 21:40 ` H Hartley Sweeten 2009-06-12 1:21 ` Nicolas Pitre 2009-06-12 10:26 ` Tony Lindgren 1 sibling, 2 replies; 167+ messages in thread From: Ryan Mallon @ 2009-06-11 21:22 UTC (permalink / raw) To: Nicolas Pitre Cc: Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove Nicolas Pitre wrote: > On Thu, 11 Jun 2009, Russell King - ARM Linux wrote: > > I think that you, as the ARM maintainer, should continue gathering all > the ARM subarchitectures into a coherent ARM tree and arbitrate > conflicts when they occur. You should especially keep a tight control > on the very core ARM code. But everything under arch/arm/mach-* you > should let people maintaining those have control of that themselves and > free yourself from that responsibility as much as possible. The current > directory structure is quite indicative of where the boundaries are > already. This way, if I make a mess of arch/arm/mach-orion5x/* then you > just need to pass the blame straight to me. > That works okay for the more popular sub-architectures like pxa, etc, where there are a lot of people to review code and sort out issues between themselves. However, for the architecture I do most of my work on, ep93xx, there are basically two of us, Hartley and myself, doing active work. It seems a bit dodgy if all the patches to ep93xx are written by one of us and acked by the other with no input from anybody else. It would be very easy for the ep93xx code to become and complete mess, and lack any coherency with the other sub-archs. I prefer having Russell, or somebody else, at least have a glance at the patches before they get applied. ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon Unit 5, Amuri Park Phone: +64 3 3779127 404 Barbadoes St Fax: +64 3 3779135 PO Box 13 889 Email: ryan@bluewatersys.com Christchurch, 8013 Web: http://www.bluewatersys.com New Zealand Freecall Australia 1800 148 751 USA 1800 261 2934 ^ permalink raw reply [flat|nested] 167+ messages in thread
* RE: HTC Dream aka. t-mobile g1 support 2009-06-11 21:22 ` Ryan Mallon @ 2009-06-11 21:40 ` H Hartley Sweeten 2009-06-12 1:21 ` Nicolas Pitre 1 sibling, 0 replies; 167+ messages in thread From: H Hartley Sweeten @ 2009-06-11 21:40 UTC (permalink / raw) To: Ryan Mallon, Nicolas Pitre Cc: Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thursday, June 11, 2009 2:23 PM, Ryan Mallon wrote: > Nicolas Pitre wrote: > > On Thu, 11 Jun 2009, Russell King - ARM Linux wrote: > > > > I think that you, as the ARM maintainer, should continue gathering all > > the ARM subarchitectures into a coherent ARM tree and arbitrate > > conflicts when they occur. You should especially keep a tight control > > on the very core ARM code. But everything under arch/arm/mach-* you > > should let people maintaining those have control of that themselves and > > free yourself from that responsibility as much as possible. The current > > directory structure is quite indicative of where the boundaries are > > already. This way, if I make a mess of arch/arm/mach-orion5x/* then you > > just need to pass the blame straight to me. > > > > That works okay for the more popular sub-architectures like pxa, etc, > where there are a lot of people to review code and sort out issues > between themselves. However, for the architecture I do most of my work > on, ep93xx, there are basically two of us, Hartley and myself, doing > active work. > > It seems a bit dodgy if all the patches to ep93xx are written by one of > us and acked by the other with no input from anybody else. It would be > very easy for the ep93xx code to become and complete mess, and lack any > coherency with the other sub-archs. I prefer having Russell, or somebody > else, at least have a glance at the patches before they get applied. I agree with Ryan. I review everything Ryan (or others) submit for ep93xx and add my Sign-off-by or Tested-by as appropriate, I don't think I have every actually added an Acked-by to any patch (I could be wrong). Ryan does similar for my patches. Before anything actually gets applied I am much more comfortable with an ok from Russell and then going through his patch system. The third party makes sure that we don't do anything silly (or stupid). Regards, Hartley ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 21:22 ` Ryan Mallon 2009-06-11 21:40 ` H Hartley Sweeten @ 2009-06-12 1:21 ` Nicolas Pitre 2009-06-12 1:26 ` Ryan Mallon 1 sibling, 1 reply; 167+ messages in thread From: Nicolas Pitre @ 2009-06-12 1:21 UTC (permalink / raw) To: Ryan Mallon Cc: Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Fri, 12 Jun 2009, Ryan Mallon wrote: > Nicolas Pitre wrote: > > On Thu, 11 Jun 2009, Russell King - ARM Linux wrote: > > > > I think that you, as the ARM maintainer, should continue gathering all > > the ARM subarchitectures into a coherent ARM tree and arbitrate > > conflicts when they occur. You should especially keep a tight control > > on the very core ARM code. But everything under arch/arm/mach-* you > > should let people maintaining those have control of that themselves and > > free yourself from that responsibility as much as possible. The current > > directory structure is quite indicative of where the boundaries are > > already. This way, if I make a mess of arch/arm/mach-orion5x/* then you > > just need to pass the blame straight to me. > > > > That works okay for the more popular sub-architectures like pxa, etc, > where there are a lot of people to review code and sort out issues > between themselves. However, for the architecture I do most of my work > on, ep93xx, there are basically two of us, Hartley and myself, doing > active work. > > It seems a bit dodgy if all the patches to ep93xx are written by one of > us and acked by the other with no input from anybody else. It would be > very easy for the ep93xx code to become and complete mess, and lack any > coherency with the other sub-archs. I prefer having Russell, or somebody > else, at least have a glance at the patches before they get applied. This is all fine. If you prefer some external help to judge your patches that's OK. In fact I'm not advocating for people to stop posting their patches to linux-arm-kernel at all. It is a good thing for patches to be aired on the mailing list for everyone to see and comment. However if you start gathering more developers around the ep93xx then someone should take charge and be responsible for it. And this must not necessarily be Russell as his cycles are not infinite. Nicolas ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 1:21 ` Nicolas Pitre @ 2009-06-12 1:26 ` Ryan Mallon 2009-06-12 1:51 ` Nicolas Pitre 2009-06-12 7:46 ` Alan Cox 0 siblings, 2 replies; 167+ messages in thread From: Ryan Mallon @ 2009-06-12 1:26 UTC (permalink / raw) To: Nicolas Pitre Cc: Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove Nicolas Pitre wrote: > On Fri, 12 Jun 2009, Ryan Mallon wrote: > >> Nicolas Pitre wrote: >>> On Thu, 11 Jun 2009, Russell King - ARM Linux wrote: >>> >>> I think that you, as the ARM maintainer, should continue gathering all >>> the ARM subarchitectures into a coherent ARM tree and arbitrate >>> conflicts when they occur. You should especially keep a tight control >>> on the very core ARM code. But everything under arch/arm/mach-* you >>> should let people maintaining those have control of that themselves and >>> free yourself from that responsibility as much as possible. The current >>> directory structure is quite indicative of where the boundaries are >>> already. This way, if I make a mess of arch/arm/mach-orion5x/* then you >>> just need to pass the blame straight to me. >>> >> That works okay for the more popular sub-architectures like pxa, etc, >> where there are a lot of people to review code and sort out issues >> between themselves. However, for the architecture I do most of my work >> on, ep93xx, there are basically two of us, Hartley and myself, doing >> active work. >> >> It seems a bit dodgy if all the patches to ep93xx are written by one of >> us and acked by the other with no input from anybody else. It would be >> very easy for the ep93xx code to become and complete mess, and lack any >> coherency with the other sub-archs. I prefer having Russell, or somebody >> else, at least have a glance at the patches before they get applied. > > This is all fine. If you prefer some external help to judge your > patches that's OK. In fact I'm not advocating for people to stop > posting their patches to linux-arm-kernel at all. It is a good thing > for patches to be aired on the mailing list for everyone to see and > comment. > > However if you start gathering more developers around the ep93xx then > someone should take charge and be responsible for it. And this must not > necessarily be Russell as his cycles are not infinite. Thats my point though: In the meantime, it falls on Russell by default to be the one to verify all the patches going through. I think the same is true for new architectures, if nobody else has the interest/hardware besides those posting the patches, then who is meant to do the reviewing/acking? ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon Unit 5, Amuri Park Phone: +64 3 3779127 404 Barbadoes St Fax: +64 3 3779135 PO Box 13 889 Email: ryan@bluewatersys.com Christchurch, 8013 Web: http://www.bluewatersys.com New Zealand Freecall Australia 1800 148 751 USA 1800 261 2934 ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 1:26 ` Ryan Mallon @ 2009-06-12 1:51 ` Nicolas Pitre 2009-06-12 2:16 ` Brian Swetland 2009-06-12 7:46 ` Alan Cox 1 sibling, 1 reply; 167+ messages in thread From: Nicolas Pitre @ 2009-06-12 1:51 UTC (permalink / raw) To: Ryan Mallon Cc: Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, swetland, pavel, lkml, linux-arm-kernel, san, rlove On Fri, 12 Jun 2009, Ryan Mallon wrote: > Nicolas Pitre wrote: > > This is all fine. If you prefer some external help to judge your > > patches that's OK. In fact I'm not advocating for people to stop > > posting their patches to linux-arm-kernel at all. It is a good thing > > for patches to be aired on the mailing list for everyone to see and > > comment. > > > > However if you start gathering more developers around the ep93xx then > > someone should take charge and be responsible for it. And this must not > > necessarily be Russell as his cycles are not infinite. > > Thats my point though: In the meantime, it falls on Russell by default > to be the one to verify all the patches going through. I think the same > is true for new architectures, if nobody else has the interest/hardware > besides those posting the patches, then who is meant to do the > reviewing/acking? I think that, at some point, if nobody else has the interest/hardware, then you are on your own. Just make sure that your code respects the kernel coding style, has no obvious API misuses, and that it does not affect anyone else. At that point if you can convince people that your code is actually useful and that you'll be around to quickly respond if/when issues are reported then it should just be merged. Nicolas ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 1:51 ` Nicolas Pitre @ 2009-06-12 2:16 ` Brian Swetland 2009-06-12 10:25 ` Ian Molton 2009-06-12 10:35 ` Pavel Machek 0 siblings, 2 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-12 2:16 UTC (permalink / raw) To: Nicolas Pitre Cc: Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, pavel, lkml, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 6:51 PM, Nicolas Pitre<nico@cam.org> wrote: > On Fri, 12 Jun 2009, Ryan Mallon wrote: >> Nicolas Pitre wrote: >> >> Thats my point though: In the meantime, it falls on Russell by default >> to be the one to verify all the patches going through. I think the same >> is true for new architectures, if nobody else has the interest/hardware >> besides those posting the patches, then who is meant to do the >> reviewing/acking? > > I think that, at some point, if nobody else has the interest/hardware, > then you are on your own. Just make sure that your code respects the > kernel coding style, has no obvious API misuses, and that it does not > affect anyone else. At that point if you can convince people that your > code is actually useful and that you'll be around to quickly respond > if/when issues are reported then it should just be merged. My hope with the msm support is to get buildable, bootable (we're there now), style-clean (we probably have stuff that needs help yet, though I think we're improving) support for the platform in the tree so people can actually build mainline for things like HTC Dream / Sapphire, Qualcomm's SURF boards, etc. At that point, I think we'll get more people looking at, testing, and hopefully contributing and reviewing patches in that domain -- I know there are a lot of folks out there hacking on ADP1 (the unlocked dev phone) or "rooted" G1s, and some of them tinker with things at the kernel level. >From a practical standpoint, some questions about trying to get a bunch of msm stuff cleaned up possibly for 2.6.31: - would having some ifdefs around code using wakelock support be acceptable for the time being? The wakelock/suspendblock review does seem to be making progress on linux-pm if not super quickly, and I'd rather maintain some ifdefs than maintain two different versions of drivers while it's getting sorted out. - from where we are now, with .30 about to be wrapped up, what's the reasonable timeline for putting together a patch series for mach-msm and for drivers/staging/msm7k or the like? When should I be sending what to where? Presumably to lakml at the least? - is it essential to completely flatten down to single patches for new drivers? We do have history including contributions from Qualcomm, HTC, etc, which would be nice to preserve in some cases, but if that's impractical, we can do a complete rebase and flatten on top of tip of tree. I'd love review/feedback on things -- I think, to Alan's original suggestion, I just would like to avoid ending up in a holding pattern on getting support for these SoCs and devices into mainline (especially if we can do it without breaking anybody else). I do understand if there aren't a lot of people interested in wading through the frightening realm of AMSS/QDSP remote interfaces... Thanks, Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 2:16 ` Brian Swetland @ 2009-06-12 10:25 ` Ian Molton 2009-06-12 10:35 ` Pavel Machek 1 sibling, 0 replies; 167+ messages in thread From: Ian Molton @ 2009-06-12 10:25 UTC (permalink / raw) To: Brian Swetland Cc: Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, pavel, lkml, linux-arm-kernel, san, rlove Brian Swetland wrote: > > - would having some ifdefs around code using wakelock support be > acceptable for the time being? The wakelock/suspendblock review does > seem to be making progress on linux-pm if not super quickly, and I'd > rather maintain some ifdefs than maintain two different versions of > drivers while it's getting sorted out. Personally, I'd say no. Use git - create a version with them dropped and then you can create a wakelock-dev branch on top of that with your new stuff in, which can be rebased should the underlying branch move on (or get merged with mainline). Its a problem that wouldnt exist if the original drivers had been submitted long ago... ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 2:16 ` Brian Swetland 2009-06-12 10:25 ` Ian Molton @ 2009-06-12 10:35 ` Pavel Machek 2009-06-12 10:40 ` Alan Cox 2009-06-12 10:44 ` Brian Swetland 1 sibling, 2 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-12 10:35 UTC (permalink / raw) To: Brian Swetland Cc: Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel, san, rlove Hi! > >> Thats my point though: In the meantime, it falls on Russell by default > >> to be the one to verify all the patches going through. I think the same > >> is true for new architectures, if nobody else has the interest/hardware > >> besides those posting the patches, then who is meant to do the > >> reviewing/acking? > > > > I think that, at some point, if nobody else has the interest/hardware, > > then you are on your own. Just make sure that your code respects the > > kernel coding style, has no obvious API misuses, and that it does not > > affect anyone else. At that point if you can convince people that your > > code is actually useful and that you'll be around to quickly respond > > if/when issues are reported then it should just be merged. > > My hope with the msm support is to get buildable, bootable (we're > there now), style-clean (we probably have stuff that needs help yet, I still can't get it to boot :-(. > At that point, I think we'll get more people looking at, testing, and > hopefully contributing and reviewing patches in that domain -- I know > there are a lot of folks out there hacking on ADP1 (the unlocked dev > phone) or "rooted" G1s, and some of them tinker with things at the > kernel level. > > >From a practical standpoint, some questions about trying to get a > bunch of msm stuff cleaned up possibly for 2.6.31: > - would having some ifdefs around code using wakelock support be > acceptable for the time being? The wakelock/suspendblock review does > seem to be making progress on linux-pm if not super quickly, and I'd > rather maintain some ifdefs than maintain two different versions of > drivers while it's getting sorted out. #ifdefs are too ugly, I'm afraid. And there will be need for for second tree, at least temporarily. > - from where we are now, with .30 about to be wrapped up, what's the > reasonable timeline for putting together a patch series for mach-msm > and for drivers/staging/msm7k or the like? When should I be sending > what to where? Presumably to lakml at the least? Well, I guess "start ASAP and maybe we can make it into .32". > - is it essential to completely flatten down to single patches for new > drivers? We do have history including contributions from Qualcomm, > HTC, etc, which would be nice to preserve in some cases, but if that's > impractical, we can do a complete rebase and flatten on top of tip of > tree. I guess preserving history is not top priority. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 10:35 ` Pavel Machek @ 2009-06-12 10:40 ` Alan Cox 2009-06-12 10:44 ` Brian Swetland 1 sibling, 0 replies; 167+ messages in thread From: Alan Cox @ 2009-06-12 10:40 UTC (permalink / raw) To: Pavel Machek Cc: Brian Swetland, Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, David Miller, lkml, linux-arm-kernel, san, rlove O> > - is it essential to completely flatten down to single patches for new > > drivers? We do have history including contributions from Qualcomm, > > HTC, etc, which would be nice to preserve in some cases, but if that's > > impractical, we can do a complete rebase and flatten on top of tip of > > tree. > > I guess preserving history is not top priority. Preserving the history is very important if it contains things like authorship data. If you are feeding a git tree into the kernel then its probably best to keep it in that format all the way to Linus. Alan ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 10:35 ` Pavel Machek 2009-06-12 10:40 ` Alan Cox @ 2009-06-12 10:44 ` Brian Swetland 2009-06-12 11:05 ` Pavel Machek 2009-06-13 7:05 ` Brian Swetland 1 sibling, 2 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-12 10:44 UTC (permalink / raw) To: Pavel Machek Cc: Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel, san, rlove On Fri, Jun 12, 2009 at 3:35 AM, Pavel Machek<pavel@ucw.cz> wrote: >> >> My hope with the msm support is to get buildable, bootable (we're >> there now), style-clean (we probably have stuff that needs help yet, > > I still can't get it to boot :-(. I think the cupcake userspace and the latest 2.6.29 kernel aren't getting along. I'm putting together instructions for building a minimal userspace (what we call tiny android -- and what I use for bringup and kernel testing), and once I've had a chance to verify that everything works end-to-end with the latest kernel, donut branch, and have verified this on ADP1, I'll send an update. Probably some time over the weekend. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 10:44 ` Brian Swetland @ 2009-06-12 11:05 ` Pavel Machek 2009-06-13 7:05 ` Brian Swetland 1 sibling, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-12 11:05 UTC (permalink / raw) To: Brian Swetland Cc: Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel, san, rlove On Fri 2009-06-12 03:44:21, Brian Swetland wrote: > On Fri, Jun 12, 2009 at 3:35 AM, Pavel Machek<pavel@ucw.cz> wrote: > >> > >> My hope with the msm support is to get buildable, bootable (we're > >> there now), style-clean (we probably have stuff that needs help yet, > > > > I still can't get it to boot :-(. > > I think the cupcake userspace and the latest 2.6.29 kernel aren't > getting along. I'm putting together instructions for building a > minimal userspace (what we call tiny android -- and what I use for > bringup and kernel testing), and once I've had a chance to verify that > everything works end-to-end with the latest kernel, donut branch, and > have verified this on ADP1, I'll send an update. Probably some time > over the weekend. Ok, I just got 2.6.29 to boot. It seems that fastboot really needs zImage, and thet one needs to be patient when staring at rainbow screen. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 10:44 ` Brian Swetland 2009-06-12 11:05 ` Pavel Machek @ 2009-06-13 7:05 ` Brian Swetland 2009-06-15 16:21 ` davidb 2009-06-15 17:09 ` Pavel Machek 1 sibling, 2 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-13 7:05 UTC (permalink / raw) To: Pavel Machek Cc: Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel On Fri, Jun 12, 2009 at 3:44 AM, Brian Swetland<swetland@google.com> wrote: > On Fri, Jun 12, 2009 at 3:35 AM, Pavel Machek<pavel@ucw.cz> wrote: >> >> I still can't get it to boot :-(. > > I think the cupcake userspace and the latest 2.6.29 kernel aren't > getting along. I'm putting together instructions for building a > minimal userspace (what we call tiny android -- and what I use for > bringup and kernel testing), and once I've had a chance to verify that > everything works end-to-end with the latest kernel, donut branch, and > have verified this on ADP1, I'll send an update. Probably some time > over the weekend. For anyone who wants a minimal android userspace image (handy for bringup and test on adp1, etc), I've thrown together a small project based on the android stack but including only the bare essentials (libc, libm, linker, init, shell, some commandline tools, adbd, etc): http://github.com/swetland/tinydroid/tree/master It's a much smaller checkout (~100MB), and builds much faster (~1 minute or less on a modern, fast box), and will get you a ramdisk.img and a minimal system.img that play nicely with the android-msm-2.6.29 kernel. Final images turn up in out/target/product/generic. I suspect it wouldn't be hard to just get something like a full arm-debian distribution booting, but that's not something I've ever tried. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 7:05 ` Brian Swetland @ 2009-06-15 16:21 ` davidb 2009-06-15 16:27 ` Pavel Machek 2009-06-15 22:25 ` Ben Leslie 2009-06-15 17:09 ` Pavel Machek 1 sibling, 2 replies; 167+ messages in thread From: davidb @ 2009-06-15 16:21 UTC (permalink / raw) To: Brian Swetland Cc: Pavel Machek, Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel On Sat, Jun 13, 2009 at 12:05:50AM -0700, Brian Swetland wrote: > I suspect it wouldn't be hard to just get something like a full > arm-debian distribution booting, but that's not something I've ever > tried. We built a userspace around ptxdist. We're still in the process of releasing it, but part of it is at <https://www.codeaurora.org/gitweb/quic/le/> The Android busybox <http://benno.id.au/blog/2007/11/14/android-busybox> mostly works. The poster doesn't seem to provide source, even though busybox requires modification to build for Android (although not much). The tricky part about something like arm-debian is storage. You might be able to stick an ext2 on an microSD card, but obviously that's only going to work once the SD driver is functioning. The phone targets don't generally have ethernet ports on them. David ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 16:21 ` davidb @ 2009-06-15 16:27 ` Pavel Machek 2009-06-15 16:45 ` davidb 2009-06-15 22:25 ` Ben Leslie 1 sibling, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-15 16:27 UTC (permalink / raw) To: Brian Swetland, Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel Hi! > > I suspect it wouldn't be hard to just get something like a full > > arm-debian distribution booting, but that's not something I've ever > > tried. > > We built a userspace around ptxdist. We're still in the process > of releasing it, but part of it is at > <https://www.codeaurora.org/gitweb/quic/le/> > > The Android busybox > <http://benno.id.au/blog/2007/11/14/android-busybox> mostly > works. The poster doesn't seem to provide source, even though > busybox requires modification to build for Android (although not > much). Thanks, I'll take a look. With right .config file and google's msm tree, running debian is fairly easy. > The tricky part about something like arm-debian is storage. You > might be able to stick an ext2 on an microSD card, but obviously > that's only going to work once the SD driver is functioning. The > phone targets don't generally have ethernet ports on them. ext2 on microSD is the key, :-), yes. It boots into multiuser after some complains when it tries to access internal NAND (udev?!). The only problem is lack of reasonable keymap. No arrows, no escape, no ctrl, no alt, no special symbols... That makes using command line very tricky. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 16:27 ` Pavel Machek @ 2009-06-15 16:45 ` davidb 0 siblings, 0 replies; 167+ messages in thread From: davidb @ 2009-06-15 16:45 UTC (permalink / raw) To: Pavel Machek Cc: Brian Swetland, Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel On Mon, Jun 15, 2009 at 09:27:46AM -0700, Pavel Machek wrote: > With right .config file and google's msm tree, running debian is > fairly easy. > > > The tricky part about something like arm-debian is storage. You > > might be able to stick an ext2 on an microSD card, but obviously > > that's only going to work once the SD driver is functioning. The > > phone targets don't generally have ethernet ports on them. > > ext2 on microSD is the key, :-), yes. It boots into multiuser after > some complains when it tries to access internal NAND (udev?!). What kind of complaints? There is some trickiness going on with the partition table on the NAND, because the CPU running Linux doesn't have permissions to read the actual partition table. > The only problem is lack of reasonable keymap. No arrows, no > escape, no ctrl, no alt, no special symbols... That makes using > command line very tricky. Probably related to drivers/char/keyboard.c's #warning "Cannot generate rawmode keyboard for your architecture yet." Does it help to change the change the big block of 'if defined...' so that CONFIG_ARM isn't dependent on CONFIG_KEYBOARD_ATKBD? I'm not sure why that's there, perhaps there aren't many ARM devices with USB host controllers in them? David ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 16:21 ` davidb 2009-06-15 16:27 ` Pavel Machek @ 2009-06-15 22:25 ` Ben Leslie 2009-06-15 22:39 ` davidb 1 sibling, 1 reply; 167+ messages in thread From: Ben Leslie @ 2009-06-15 22:25 UTC (permalink / raw) To: Brian Swetland, Pavel Machek, Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel On Tue, Jun 16, 2009 at 2:21 AM, <davidb@quicinc.com> wrote: > On Sat, Jun 13, 2009 at 12:05:50AM -0700, Brian Swetland wrote: > >> I suspect it wouldn't be hard to just get something like a full >> arm-debian distribution booting, but that's not something I've ever >> tried. > > We built a userspace around ptxdist. We're still in the process > of releasing it, but part of it is at > <https://www.codeaurora.org/gitweb/quic/le/> > > The Android busybox > <http://benno.id.au/blog/2007/11/14/android-busybox> mostly > works. The poster doesn't seem to provide source, even though > busybox requires modification to build for Android (although not > much). I didn't need to change anything; I just compiled busybox; No changes required. (Note: It is a static binary that includes glibc). Cheers, Benno ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 22:25 ` Ben Leslie @ 2009-06-15 22:39 ` davidb 2009-06-15 23:41 ` Ben Leslie 0 siblings, 1 reply; 167+ messages in thread From: davidb @ 2009-06-15 22:39 UTC (permalink / raw) To: Ben Leslie Cc: Brian Swetland, Pavel Machek, Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel On Mon, Jun 15, 2009 at 03:25:35PM -0700, Ben Leslie wrote: > > The Android busybox > > <http://benno.id.au/blog/2007/11/14/android-busybox> mostly > > works. The poster doesn't seem to provide source, even though > > busybox requires modification to build for Android (although not > > much). > > I didn't need to change anything; I just compiled busybox; No changes > required. (Note: It is a static binary that includes glibc). I wonder if it's changed since you built it, then. I had to hack up a few paths since the Android environment doesn't put things in normal places. David ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 22:39 ` davidb @ 2009-06-15 23:41 ` Ben Leslie 2009-06-16 6:12 ` davidb 0 siblings, 1 reply; 167+ messages in thread From: Ben Leslie @ 2009-06-15 23:41 UTC (permalink / raw) To: Ben Leslie, Brian Swetland, Pavel Machek, Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel On Tue, Jun 16, 2009 at 8:39 AM, <davidb@quicinc.com> wrote: > On Mon, Jun 15, 2009 at 03:25:35PM -0700, Ben Leslie wrote: > >> > The Android busybox >> > <http://benno.id.au/blog/2007/11/14/android-busybox> mostly >> > works. The poster doesn't seem to provide source, even though >> > busybox requires modification to build for Android (although not >> > much). >> >> I didn't need to change anything; I just compiled busybox; No changes >> required. (Note: It is a static binary that includes glibc). > > I wonder if it's changed since you built it, then. I had to hack > up a few paths since the Android environment doesn't put things > in normal places. Possibly, it was quite some time ago! And I have an imperfect memory. I'm fairly sure I would have put up any patches if I did need to change things; that is what I normally do. I'm trying to dig the source tree out of my archive just to verify. I would say that the binary there is pretty much completely redundant now. Any new busybox 'for android' should probably build against the Android C library, with the Android version of gcc etc. My contribution was done before any of the Android source was available, and was compiled with the codesourcery gcc compiler. (Note: Strictly speaking I really should have the source code for it irrespective of if I made any changes to the source code; rectifying that now.) Cheers, Benno ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 23:41 ` Ben Leslie @ 2009-06-16 6:12 ` davidb 0 siblings, 0 replies; 167+ messages in thread From: davidb @ 2009-06-16 6:12 UTC (permalink / raw) To: Ben Leslie Cc: Brian Swetland, Pavel Machek, Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel On Mon, Jun 15, 2009 at 04:41:14PM -0700, Ben Leslie wrote: > I would say that the binary there is pretty much completely redundant now. > Any new busybox 'for android' should probably build against the Android > C library, with the Android version of gcc etc. My contribution was done > before any of the Android source was available, and was compiled with > the codesourcery gcc compiler. A coworker spent a day or so trying to get this working and ran into a lot of difficulties. Bionic is missing a lot of things that just aren't needed by Android, and busybox makes a lot of assumptions about the C library. It'd be nice to have, but I think it would be a good amount of work. For now, we're just living with a static glibc version. David ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 7:05 ` Brian Swetland 2009-06-15 16:21 ` davidb @ 2009-06-15 17:09 ` Pavel Machek 1 sibling, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-15 17:09 UTC (permalink / raw) To: Brian Swetland Cc: Nicolas Pitre, Ryan Mallon, Russell King - ARM Linux, Tony Lindgren, Alan Cox, David Miller, lkml, linux-arm-kernel > I suspect it wouldn't be hard to just get something like a full > arm-debian distribution booting, but that's not something I've ever > tried. It is indeed extremely easy with ext2 on sd card. I can write howto if there's interest, but I guess people can just figure it out :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 1:26 ` Ryan Mallon 2009-06-12 1:51 ` Nicolas Pitre @ 2009-06-12 7:46 ` Alan Cox 1 sibling, 0 replies; 167+ messages in thread From: Alan Cox @ 2009-06-12 7:46 UTC (permalink / raw) To: Ryan Mallon Cc: Nicolas Pitre, Russell King - ARM Linux, Tony Lindgren, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove > Thats my point though: In the meantime, it falls on Russell by default > to be the one to verify all the patches going through. I think the same No it doesn't > is true for new architectures, if nobody else has the interest/hardware > besides those posting the patches, then who is meant to do the > reviewing/acking? If nobody else is interested then you can do the reviewing/acking because clearly nobody else cares if you make a mistake. And if they do then they'll be motivated to add resources to assist you ;) Alan ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 17:29 ` Nicolas Pitre 2009-06-11 21:22 ` Ryan Mallon @ 2009-06-12 10:26 ` Tony Lindgren 1 sibling, 0 replies; 167+ messages in thread From: Tony Lindgren @ 2009-06-12 10:26 UTC (permalink / raw) To: Nicolas Pitre Cc: Russell King - ARM Linux, Alan Cox, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove * Nicolas Pitre <nico@cam.org> [090611 10:30]: > On Thu, 11 Jun 2009, Russell King - ARM Linux wrote: > > > On Thu, Jun 11, 2009 at 07:00:39AM -0700, Tony Lindgren wrote: > > > You suggested pulling each set as they get reviewed into some omap branch > > > in your tree, do you want to try that the next merge window? > > > > If we're following Alan's suggestion, then as I see it you're entirely > > responsible for tracking what's in OMAP, getting it into linux-next and > > (I guess) ultimately sending Linus a pull request for it during the > > merge window. I just become someone who can put their oar into reviewing > > OMAP patches as and when. > > I don't see things exactly that way. > > linux-next is a fully automated "let's dump everything together and see > what is going to explode" kind of tree. There is no patch review except > from those who see their code being dammaged by the blast. And it is > automated in the sense that git pull operations are done automatically, > even if someone deals with the merge conflicts manually afterwards. My > tree can be pulled into linux-next directly or through your tree, or > even through both paths in parallel and git will deal with it just fine. > And at the end of the day the linux-next tree is tossed in the garbage > bin anyway. > > I think that you, as the ARM maintainer, should continue gathering all > the ARM subarchitectures into a coherent ARM tree and arbitrate > conflicts when they occur. You should especially keep a tight control > on the very core ARM code. But everything under arch/arm/mach-* you > should let people maintaining those have control of that themselves and > free yourself from that responsibility as much as possible. The current > directory structure is quite indicative of where the boundaries are > already. This way, if I make a mess of arch/arm/mach-orion5x/* then you > just need to pass the blame straight to me. This is what I was thinking too. Tony ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 13:37 ` Russell King - ARM Linux 2009-06-11 14:00 ` Tony Lindgren @ 2009-06-11 14:47 ` Pavel Machek 2009-06-11 15:59 ` Russell King - ARM Linux 1 sibling, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-11 14:47 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Tony Lindgren, Alan Cox, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove Hi! > What you apparantly decided (and I'm saying this from how it appeared > on the receiving end and sort-of had it confirmed by Kevin in conference) > is that you'd send a patch set for me to review, I'd review it, and then > you'd merge it within your git tree into a branch for me. You'd then do > the same thing with the next patch set, and so forth. > > Eventually, near the merge window, you sent a pull request for the > entire lot, by which time I looked at the list of changes and wondered > whether that encompassed everything you'd asked me to review, or whether > it contained extra stuff, or whether it was for something quite different, > or what. Well, usually Acked-by: and Reviewed-by: tags solve that, no? If it has my acked-by: it is okay and can be applied. Otherwise I did not review it before and need to check it... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 14:47 ` Pavel Machek @ 2009-06-11 15:59 ` Russell King - ARM Linux 0 siblings, 0 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 15:59 UTC (permalink / raw) To: Pavel Machek Cc: Tony Lindgren, Alan Cox, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 04:47:35PM +0200, Pavel Machek wrote: > Well, usually Acked-by: and Reviewed-by: tags solve that, no? > > If it has my acked-by: it is okay and can be applied. Otherwise I did > not review it before and need to check it... It would be nice if git pull messages included that information, but they don't. The only way to get at that from a pull message is to pull the tree and then check it, or track down whatever random gitweb URL corresponds with the tree and check it there. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:54 ` Alan Cox ` (2 preceding siblings ...) 2009-06-11 13:21 ` Tony Lindgren @ 2009-06-11 13:28 ` Russell King - ARM Linux 2009-06-11 13:32 ` Alan Cox 3 siblings, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 13:28 UTC (permalink / raw) To: Alan Cox Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote: > Leave it to the platform people to push their driver code through the > right channels. I should point out that that has been entirely the case since switching over to BK, and later git. I do not merge other driver code into my tree unless the subsystem maintainer wants me to do so, in which case I do give it a quick review. Sometimes I give people a quick review on the way to directing them to the right places. I do hope you don't think I still run that unmanagable -rmk tree that was around when you did the -ac series kernels. I gave that up as a bad approach a very long time ago. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 13:28 ` Russell King - ARM Linux @ 2009-06-11 13:32 ` Alan Cox 0 siblings, 0 replies; 167+ messages in thread From: Alan Cox @ 2009-06-11 13:32 UTC (permalink / raw) To: Russell King - ARM Linux Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove > I do hope you don't think I still run that unmanagable -rmk tree that > was around when you did the -ac series kernels. I gave that up as a > bad approach a very long time ago. No I didn't think that. You'd either have expired by now or be found screaming in a small room with soft walls if you did ;) ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:38 ` Russell King - ARM Linux 2009-06-11 12:54 ` Alan Cox @ 2009-06-11 13:21 ` Pavel Machek 2009-06-11 15:52 ` Russell King - ARM Linux 2009-06-11 15:15 ` Joe Perches ` (2 subsequent siblings) 4 siblings, 1 reply; 167+ messages in thread From: Pavel Machek @ 2009-06-11 13:21 UTC (permalink / raw) To: Russell King - ARM Linux Cc: David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Thu 2009-06-11 13:38:52, Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > Date: Thu, 11 Jun 2009 12:49:12 +0100 > > > > > I can not keep up with the number of patches that need to be > > > reviewed and ultimately merged. I know this, and I freely admit it, > > > and I have done so on many occasions. > > > > Then split up the responsibilities to other people instead of being > > the choke point. Controlling everything isn't so important. > > Don't you think that I've been trying to get other people to be more > involved? > > - I've been pushing people to send patches to the relevent mailing > list(s) and maintainer(s) for years. The patch system is actively harmful here, because you either send the system for discussion, or for inclusion. Picking the patches from the mailing list when there are no significant comments (as done on lkml) seems to work better. > If patchwork can replace what my patch system does for me (which is > basically to help ensure that patches don't get lost which need > applying - that's different from logging every single patch) then > I'll gladly look at it. It will mean that some of the sanity checks > on the patch content, which happen automatically with the patch system, > will need to be done manually. > > If patchwork just gathers up every patch which has ever been seen on > a mailing list, then stuff will get lost at a higher rate than today > and it will have a negative impact. I believe you are concentrating on "patch loss rate" a bit too much. lkml does have higher "patch loss rate", still it seems better/nicer/easier to work with. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 13:21 ` Pavel Machek @ 2009-06-11 15:52 ` Russell King - ARM Linux 2009-06-12 1:27 ` Jamie Lokier 0 siblings, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 15:52 UTC (permalink / raw) To: Pavel Machek Cc: David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 03:21:17PM +0200, Pavel Machek wrote: > On Thu 2009-06-11 13:38:52, Russell King - ARM Linux wrote: > > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: > > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > > Date: Thu, 11 Jun 2009 12:49:12 +0100 > > > > > > > I can not keep up with the number of patches that need to be > > > > reviewed and ultimately merged. I know this, and I freely admit it, > > > > and I have done so on many occasions. > > > > > > Then split up the responsibilities to other people instead of being > > > the choke point. Controlling everything isn't so important. > > > > Don't you think that I've been trying to get other people to be more > > involved? > > > > - I've been pushing people to send patches to the relevent mailing > > list(s) and maintainer(s) for years. > > The patch system is actively harmful here, because you either send the > system for discussion, or for inclusion. Picking the patches from the > mailing list when there are no significant comments (as done on lkml) > seems to work better. That's your view - I used to do the "picking patches from the mailing list" thing, and the result was that patches got dropped at an alarming rate. That's exactly why I created the patch system - to provide a solution for that problem. That problem still exists today - I still operate with email in a way which means if I don't deal with something as soon as I see it, it gets filed away and almost never looked at again - even if I re-mark the message as 'New'. That means if it's inconvenient to apply a patch (because the machine with the git trees on is powered down) then the patch tends to get lost. Hey, I'm useless with email, there's nothing new there. I know this so I created a way to solve it. With the patch system, it remains visible to me without the clutter of lots of other email, and therefore stands a much better chance of being applied. It is just rather unfortunate that since the patch system was written, a different kind of patch format was invented which isn't compatible with the patch system, and it doesn't cope well with this other format. But hey, if you want me to drop lots of patches, then sure just send them by email. Just expect to nag me a lot more about applying your patch. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 15:52 ` Russell King - ARM Linux @ 2009-06-12 1:27 ` Jamie Lokier 0 siblings, 0 replies; 167+ messages in thread From: Jamie Lokier @ 2009-06-12 1:27 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove Russell King - ARM Linux wrote: > I still operate with email in a way > which means if I don't deal with something as soon as I see it, it gets > filed away and almost never looked at again - even if I re-mark the > message as 'New'. That means if it's inconvenient to apply a patch > (because the machine with the git trees on is powered down) then the > patch tends to get lost. Same here. Can't keep up, never enough time to go back through old 'New' mails. > But hey, if you want me to drop lots of patches, then sure just send > them by email. Just expect to nag me a lot more about applying your > patch. Thanks for mentioning this. With the huge number of patches sent to the mailing list these days, I was getting the impression sending to the list was the thing to do. -- Jamie ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:38 ` Russell King - ARM Linux 2009-06-11 12:54 ` Alan Cox 2009-06-11 13:21 ` Pavel Machek @ 2009-06-11 15:15 ` Joe Perches 2009-06-11 15:39 ` Russell King - ARM Linux 2009-06-11 18:24 ` Sam Ravnborg 2009-06-12 1:33 ` Ryan Mallon 2009-06-14 9:06 ` Jean-Christophe PLAGNIOL-VILLARD 4 siblings, 2 replies; 167+ messages in thread From: Joe Perches @ 2009-06-11 15:15 UTC (permalink / raw) To: Russell King - ARM Linux Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, 2009-06-11 at 13:38 +0100, Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > Date: Thu, 11 Jun 2009 12:49:12 +0100 > > > > > I can not keep up with the number of patches that need to be > > > reviewed and ultimately merged. I know this, and I freely admit it, > > > and I have done so on many occasions. > > > > Then split up the responsibilities to other people instead of being > > the choke point. Controlling everything isn't so important. > > Don't you think that I've been trying to get other people to be more > involved? > > - I've been pushing people to send patches to the relevent mailing > list(s) and maintainer(s) for years. > > - I've been pushing people to send their ARM patches to the ARM > mailing list rather than directly into the patch system for review > (it even has a comment telling people this) so that others can get > involved in reviewing them, and sharing that work load. > > Do you think either have been anywhere near successful? [] > I've been trying to get greater participation > but it's just not happening. I suggest you stop using subscriber-only mailing lists and use linux-arm@vger.kernel.org. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 15:15 ` Joe Perches @ 2009-06-11 15:39 ` Russell King - ARM Linux 2009-06-11 15:53 ` Joe Perches 2009-06-11 18:24 ` Sam Ravnborg 1 sibling, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 15:39 UTC (permalink / raw) To: Joe Perches Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote: > On Thu, 2009-06-11 at 13:38 +0100, Russell King - ARM Linux wrote: > > Don't you think that I've been trying to get other people to be more > > involved? > > > > - I've been pushing people to send patches to the relevent mailing > > list(s) and maintainer(s) for years. > > > > - I've been pushing people to send their ARM patches to the ARM > > mailing list rather than directly into the patch system for review > > (it even has a comment telling people this) so that others can get > > involved in reviewing them, and sharing that work load. > > > > Do you think either have been anywhere near successful? > [] > > I've been trying to get greater participation > > but it's just not happening. > > I suggest you stop using subscriber-only mailing lists and > use linux-arm@vger.kernel.org. It's difficult to see how that helps, given that these lists have 1800+ subscribers already on them. If 1800 subscribers can't do it, are you expecting (maybe) another 100 to magically provide the answer? ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 15:39 ` Russell King - ARM Linux @ 2009-06-11 15:53 ` Joe Perches 2009-06-11 16:08 ` Russell King - ARM Linux 0 siblings, 1 reply; 167+ messages in thread From: Joe Perches @ 2009-06-11 15:53 UTC (permalink / raw) To: Russell King - ARM Linux Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, 2009-06-11 at 16:39 +0100, Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote: > > I suggest you stop using subscriber-only mailing lists and > > use linux-arm@vger.kernel.org. > It's difficult to see how that helps, given that these lists have > 1800+ subscribers already on them. If 1800 subscribers can't do it, > are you expecting (maybe) another 100 to magically provide the answer? There aren't large numbers of ARM posters. You've simply put up an unnecessary roadblock to getting patches for review. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 15:53 ` Joe Perches @ 2009-06-11 16:08 ` Russell King - ARM Linux 2009-06-11 16:37 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 16:08 UTC (permalink / raw) To: Joe Perches Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 08:53:00AM -0700, Joe Perches wrote: > On Thu, 2009-06-11 at 16:39 +0100, Russell King - ARM Linux wrote: > > On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote: > > > I suggest you stop using subscriber-only mailing lists and > > > use linux-arm@vger.kernel.org. > > It's difficult to see how that helps, given that these lists have > > 1800+ subscribers already on them. If 1800 subscribers can't do it, > > are you expecting (maybe) another 100 to magically provide the answer? > > There aren't large numbers of ARM posters. > > You've simply put up an unnecessary roadblock to > getting patches for review. I simply disagree with your assessment of the situation. Yes, there are a few people who refuse to subscribe to such lists, but I maintain that's a fairly small proportion. I'd also point out that most of the people in this thread aren't subscribed to this list, yet they're posting freely to it. Some of the people posting to it will get a moderation message for a couple of times and then no more. As I've said in the past, unlike most subscriber only lists, these lists aren't strictly subscriber only. Eg, Alan has been able to post to the lists for ages without being a subscriber. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 16:08 ` Russell King - ARM Linux @ 2009-06-11 16:37 ` Bartlomiej Zolnierkiewicz 2009-06-11 16:42 ` Russell King - ARM Linux 0 siblings, 1 reply; 167+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2009-06-11 16:37 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Joe Perches, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thursday 11 June 2009 18:08:50 Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 08:53:00AM -0700, Joe Perches wrote: > > On Thu, 2009-06-11 at 16:39 +0100, Russell King - ARM Linux wrote: > > > On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote: > > > > I suggest you stop using subscriber-only mailing lists and > > > > use linux-arm@vger.kernel.org. > > > It's difficult to see how that helps, given that these lists have > > > 1800+ subscribers already on them. If 1800 subscribers can't do it, > > > are you expecting (maybe) another 100 to magically provide the answer? > > > > There aren't large numbers of ARM posters. > > > > You've simply put up an unnecessary roadblock to > > getting patches for review. > > I simply disagree with your assessment of the situation. Yes, there are > a few people who refuse to subscribe to such lists, but I maintain that's > a fairly small proportion. > > I'd also point out that most of the people in this thread aren't > subscribed to this list, yet they're posting freely to it. Some of the > people posting to it will get a moderation message for a couple of times > and then no more. As I've said in the past, unlike most subscriber only Interesting. Here is the typical moderation message I was getting: On Tuesday 17 February 2009 14:08:44 linux-arm-kernel-bounces@lists.arm.linux.org.uk wrote: > Your request to the Linux-arm-kernel mailing list > > Posting of your message titled "Re: [PATCH 3/3 v3] AT91: > initialize Compact Flash on AT91SAM9263 cpu" > > has been rejected by the list moderator. The moderator gave the > following reason for rejecting your request: > > "No reason given" > > Any questions or comments should be directed to the list administrator > at: > > linux-arm-kernel-owner@lists.arm.linux.org.uk "No reason given" part was just lovely.. After getting a couple of such messages I decided to stay as far away from linux-arm-kernel list as possible.. Before interacting with linux-arm-kernel list I really thought that people exaggerated the issue and that their complains were unfounded.. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 16:37 ` Bartlomiej Zolnierkiewicz @ 2009-06-11 16:42 ` Russell King - ARM Linux 2009-06-12 1:14 ` FUJITA Tomonori 2009-06-12 1:23 ` Jamie Lokier 0 siblings, 2 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-11 16:42 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Joe Perches, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 06:37:21PM +0200, Bartlomiej Zolnierkiewicz wrote: > "No reason given" part was just lovely.. > > After getting a couple of such messages I decided to stay as far away from > linux-arm-kernel list as possible.. > > Before interacting with linux-arm-kernel list I really thought that people > exaggerated the issue and that their complains were unfounded.. I wish people told me about this - it's certainly not my policy nor indeed the policy which should be applied to the list. I'll find out what's going on when my co-list admin returns from his vacation. Thanks for bringing it to my attention. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 16:42 ` Russell King - ARM Linux @ 2009-06-12 1:14 ` FUJITA Tomonori 2009-06-12 1:23 ` Jamie Lokier 1 sibling, 0 replies; 167+ messages in thread From: FUJITA Tomonori @ 2009-06-12 1:14 UTC (permalink / raw) To: linux Cc: bzolnier, joe, davem, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, 11 Jun 2009 17:42:18 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Thu, Jun 11, 2009 at 06:37:21PM +0200, Bartlomiej Zolnierkiewicz wrote: > > "No reason given" part was just lovely.. > > > > After getting a couple of such messages I decided to stay as far away from > > linux-arm-kernel list as possible.. > > > > Before interacting with linux-arm-kernel list I really thought that people > > exaggerated the issue and that their complains were unfounded.. > > I wish people told me about this - it's certainly not my policy nor > indeed the policy which should be applied to the list. I'll find out > what's going on when my co-list admin returns from his vacation. > > Thanks for bringing it to my attention. Here's another example that I got (this mail was about a patch that touches arm code): == On Tue, 12 May 2009 09:49:58 +0100 linux-arm-kernel-bounces@lists.arm.linux.org.uk wrote: > Your request to the Linux-arm-kernel mailing list > > Posting of your message titled "Re: [PATCH] remove DMA_nBIT_MASK > macro" > > has been rejected by the list moderator. The moderator gave the > following reason for rejecting your request: > > "Non-members are not allowed to post messages to this list. You have > to subscribe before you're allowed to post. " > > Any questions or comments should be directed to the list administrator > at: > > linux-arm-kernel-owner@lists.arm.linux.org.uk > > ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 16:42 ` Russell King - ARM Linux 2009-06-12 1:14 ` FUJITA Tomonori @ 2009-06-12 1:23 ` Jamie Lokier 2009-06-12 8:39 ` Bartlomiej Zolnierkiewicz 1 sibling, 1 reply; 167+ messages in thread From: Jamie Lokier @ 2009-06-12 1:23 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Bartlomiej Zolnierkiewicz, Joe Perches, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 06:37:21PM +0200, Bartlomiej Zolnierkiewicz wrote: > > "No reason given" part was just lovely.. > > > > After getting a couple of such messages I decided to stay as far away from > > linux-arm-kernel list as possible.. > > > > Before interacting with linux-arm-kernel list I really thought that people > > exaggerated the issue and that their complains were unfounded.. > > I wish people told me about this - it's certainly not my policy nor > indeed the policy which should be applied to the list. I'll find out > what's going on when my co-list admin returns from his vacation. > > Thanks for bringing it to my attention. Before I subscribed to linux-arm-kernel, I had quite a few moderation messages just because I responded to threads which included linux-arm-kernel in the addresses, but were cross-posted (by others) to say linux-kernel, uclinux-dev or linux-embedded. I got moderation messages, and found them slightly annoying because I'd put effort into my replies, and presumed that some people involved in the thread wouldn't see them. Possibly the important people. That's the main reason I subscribed to linux-arm-kernel - just so I know people can see replies to threads that I'm responding to on other lists. I do actually work on ARM kernels too, so don't unsubscribe me for that :-) When I did subscribe to linux-arm-kernel, I got a message telling me I was being considered... Months went by, and it didn't subscribe me. That was annoying. I presumed I'd been rejected. I tried again a few months later, and this time the subscription approval process was relatively quick at a week or so. I was beginning to think I'd be silently rejected again, therefore delighted to be counted among the Special Ones allowed to subscribe :-) Other Linux mailing lists subscribe quickly with an automated confirmation process, which is more useful. -- Jamie ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 1:23 ` Jamie Lokier @ 2009-06-12 8:39 ` Bartlomiej Zolnierkiewicz 2009-06-12 17:44 ` Russell King - ARM Linux 2009-06-12 23:40 ` David Miller 0 siblings, 2 replies; 167+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2009-06-12 8:39 UTC (permalink / raw) To: Jamie Lokier Cc: Russell King - ARM Linux, Joe Perches, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Friday 12 June 2009 03:23:04 Jamie Lokier wrote: > Russell King - ARM Linux wrote: > > On Thu, Jun 11, 2009 at 06:37:21PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > "No reason given" part was just lovely.. > > > > > > After getting a couple of such messages I decided to stay as far away from > > > linux-arm-kernel list as possible.. > > > > > > Before interacting with linux-arm-kernel list I really thought that people > > > exaggerated the issue and that their complains were unfounded.. > > > > I wish people told me about this - it's certainly not my policy nor > > indeed the policy which should be applied to the list. I'll find out > > what's going on when my co-list admin returns from his vacation. > > > > Thanks for bringing it to my attention. > > Before I subscribed to linux-arm-kernel, I had quite a few moderation > messages just because I responded to threads which included > linux-arm-kernel in the addresses, but were cross-posted (by others) > to say linux-kernel, uclinux-dev or linux-embedded. > > I got moderation messages, and found them slightly annoying because > I'd put effort into my replies, and presumed that some people involved > in the thread wouldn't see them. Possibly the important people. > > That's the main reason I subscribed to linux-arm-kernel - just so I > know people can see replies to threads that I'm responding to on other > lists. > > I do actually work on ARM kernels too, so don't unsubscribe me for that :-) > > When I did subscribe to linux-arm-kernel, I got a message telling me I > was being considered... Months went by, and it didn't subscribe me. > That was annoying. I presumed I'd been rejected. > > I tried again a few months later, and this time the subscription > approval process was relatively quick at a week or so. I was > beginning to think I'd be silently rejected again, therefore delighted > to be counted among the Special Ones allowed to subscribe :-) :) Now imagine a new or a seasonal ARM developer waiting a week just to be able to post an obvious bug fix patch. In most other kernel areas such patch would be long applied. The irony of this all is that the same people that complain about lack of time still invest it in such idiotic tasks like approval of subscription requests or moderation of messages.. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 8:39 ` Bartlomiej Zolnierkiewicz @ 2009-06-12 17:44 ` Russell King - ARM Linux 2009-06-12 18:38 ` Bartlomiej Zolnierkiewicz 2009-06-12 23:40 ` David Miller 1 sibling, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-12 17:44 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Jamie Lokier, Joe Perches, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Fri, Jun 12, 2009 at 10:39:43AM +0200, Bartlomiej Zolnierkiewicz wrote: > The irony of this all is that the same people that complain about lack of > time still invest it in such idiotic tasks like approval of subscription > requests or moderation of messages.. There we go again, people making unfounded statements with no basis in reality. It doesn't surprise me that people find me hard to get on with when they go around making such statements without doing the basic research first. At the bottom of the mailing list web pages there is a line which tells you who looks after them. For this list, it says: Linux-arm-kernel list run by rmk+listadmin at arm.linux.org.uk, mouw at nl.linux.org Oh my, two people. Wow. Could it be that I'm not the one who is primerily involved with doing the approval. Now that's a thought. So, next time, do some research before making such incorrect statements. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 17:44 ` Russell King - ARM Linux @ 2009-06-12 18:38 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 167+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2009-06-12 18:38 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Jamie Lokier, Joe Perches, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Friday 12 June 2009 19:44:19 Russell King - ARM Linux wrote: > On Fri, Jun 12, 2009 at 10:39:43AM +0200, Bartlomiej Zolnierkiewicz wrote: > > The irony of this all is that the same people that complain about lack of > > time still invest it in such idiotic tasks like approval of subscription > > requests or moderation of messages.. > > There we go again, people making unfounded statements with no basis > in reality. > > It doesn't surprise me that people find me hard to get on with when > they go around making such statements without doing the basic research > first. > > At the bottom of the mailing list web pages there is a line which tells > you who looks after them. For this list, it says: > > Linux-arm-kernel list run by rmk+listadmin at arm.linux.org.uk, mouw at > nl.linux.org > > Oh my, two people. Wow. Could it be that I'm not the one who is > primerily involved with doing the approval. Now that's a thought. I'm *really* sorry for not having the telepathy skill. I promise to work on it! :) > So, next time, do some research before making such incorrect > statements. Well.. * Erik is not an ARM (co-)maintainer in the first place. * I don't hear him defending the broken-by-design idea of having semi-private mailing list for the second most relevant (IMHO) CPU architecture. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 8:39 ` Bartlomiej Zolnierkiewicz 2009-06-12 17:44 ` Russell King - ARM Linux @ 2009-06-12 23:40 ` David Miller 2009-06-12 23:43 ` David Miller 1 sibling, 1 reply; 167+ messages in thread From: David Miller @ 2009-06-12 23:40 UTC (permalink / raw) To: bzolnier Cc: jamie, linux, joe, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Date: Fri, 12 Jun 2009 10:39:43 +0200 > The irony of this all is that the same people that complain about lack of > time still invest it in such idiotic tasks like approval of subscription > requests or moderation of messages.. It's a control issue. There is no other logical explanation. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 23:40 ` David Miller @ 2009-06-12 23:43 ` David Miller 0 siblings, 0 replies; 167+ messages in thread From: David Miller @ 2009-06-12 23:43 UTC (permalink / raw) To: bzolnier Cc: jamie, linux, joe, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove From: David Miller <davem@davemloft.net> Date: Fri, 12 Jun 2009 16:40:34 -0700 (PDT) > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> > Date: Fri, 12 Jun 2009 10:39:43 +0200 > >> The irony of this all is that the same people that complain about lack of >> time still invest it in such idiotic tasks like approval of subscription >> requests or moderation of messages.. > > It's a control issue. There is no other logical explanation. Just to be clear, I mean not using an open list on vger.kernel.org is the control issue. Not whether RMK does the approvals or not, I have no idea whether he or another person does. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 15:15 ` Joe Perches 2009-06-11 15:39 ` Russell King - ARM Linux @ 2009-06-11 18:24 ` Sam Ravnborg 2009-06-13 0:30 ` Ben Dooks 1 sibling, 1 reply; 167+ messages in thread From: Sam Ravnborg @ 2009-06-11 18:24 UTC (permalink / raw) To: Joe Perches Cc: Russell King - ARM Linux, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote: > On Thu, 2009-06-11 at 13:38 +0100, Russell King - ARM Linux wrote: > > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: > > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > > Date: Thu, 11 Jun 2009 12:49:12 +0100 > > > > > > > I can not keep up with the number of patches that need to be > > > > reviewed and ultimately merged. I know this, and I freely admit it, > > > > and I have done so on many occasions. > > > > > > Then split up the responsibilities to other people instead of being > > > the choke point. Controlling everything isn't so important. > > > > Don't you think that I've been trying to get other people to be more > > involved? > > > > - I've been pushing people to send patches to the relevent mailing > > list(s) and maintainer(s) for years. > > > > - I've been pushing people to send their ARM patches to the ARM > > mailing list rather than directly into the patch system for review > > (it even has a comment telling people this) so that others can get > > involved in reviewing them, and sharing that work load. > > > > Do you think either have been anywhere near successful? > [] > > I've been trying to get greater participation > > but it's just not happening. > > I suggest you stop using subscriber-only mailing lists and > use linux-arm@vger.kernel.org. This is main point here is to offload Russell. One way to offload Russell is to have competent people reviewing platform code for ARM. This is best done by other platform people. Me and you - we can helpt. But the people where we need higher involvement are already on the list. Sam ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 18:24 ` Sam Ravnborg @ 2009-06-13 0:30 ` Ben Dooks 2009-06-13 9:02 ` Pavel Machek 0 siblings, 1 reply; 167+ messages in thread From: Ben Dooks @ 2009-06-13 0:30 UTC (permalink / raw) To: Sam Ravnborg Cc: Joe Perches, Russell King - ARM Linux, David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove On Thu, Jun 11, 2009 at 08:24:45PM +0200, Sam Ravnborg wrote: > On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote: > > On Thu, 2009-06-11 at 13:38 +0100, Russell King - ARM Linux wrote: > > > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: > > > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > > > Date: Thu, 11 Jun 2009 12:49:12 +0100 > > > > > > > > > I can not keep up with the number of patches that need to be > > > > > reviewed and ultimately merged. I know this, and I freely admit it, > > > > > and I have done so on many occasions. > > > > > > > > Then split up the responsibilities to other people instead of being > > > > the choke point. Controlling everything isn't so important. > > > > > > Don't you think that I've been trying to get other people to be more > > > involved? > > > > > > - I've been pushing people to send patches to the relevent mailing > > > list(s) and maintainer(s) for years. > > > > > > - I've been pushing people to send their ARM patches to the ARM > > > mailing list rather than directly into the patch system for review > > > (it even has a comment telling people this) so that others can get > > > involved in reviewing them, and sharing that work load. > > > > > > Do you think either have been anywhere near successful? > > [] > > > I've been trying to get greater participation > > > but it's just not happening. > > > > I suggest you stop using subscriber-only mailing lists and > > use linux-arm@vger.kernel.org. > > This is main point here is to offload Russell. > One way to offload Russell is to have competent people reviewing platform > code for ARM. This is best done by other platform people. > Me and you - we can helpt. But the people where we need higher > involvement are already on the list. Personally, I'm not on linux-arm@vger.kernel.org and don't plan on being there either. If people are too stupid to read the maintainers entry and realise that linux-arm-kernel is moderated and they might thus have to subscribe to post there then they can be safely ignored. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 0:30 ` Ben Dooks @ 2009-06-13 9:02 ` Pavel Machek 2009-06-13 9:13 ` Sam Ravnborg ` (2 more replies) 0 siblings, 3 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-13 9:02 UTC (permalink / raw) To: Ben Dooks Cc: Sam Ravnborg, Joe Perches, Russell King - ARM Linux, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove nOn Sat 2009-06-13 01:30:16, Ben Dooks wrote: > On Thu, Jun 11, 2009 at 08:24:45PM +0200, Sam Ravnborg wrote: > > On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote: > > > On Thu, 2009-06-11 at 13:38 +0100, Russell King - ARM Linux wrote: > > > > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: > > > > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > > > > Date: Thu, 11 Jun 2009 12:49:12 +0100 > > > > > > > > > > > I can not keep up with the number of patches that need to be > > > > > > reviewed and ultimately merged. I know this, and I freely admit it, > > > > > > and I have done so on many occasions. > > > > > > > > > > Then split up the responsibilities to other people instead of being > > > > > the choke point. Controlling everything isn't so important. > > > > > > > > Don't you think that I've been trying to get other people to be more > > > > involved? > > > > > > > > - I've been pushing people to send patches to the relevent mailing > > > > list(s) and maintainer(s) for years. > > > > > > > > - I've been pushing people to send their ARM patches to the ARM > > > > mailing list rather than directly into the patch system for review > > > > (it even has a comment telling people this) so that others can get > > > > involved in reviewing them, and sharing that work load. > > > > > > > > Do you think either have been anywhere near successful? > > > [] > > > > I've been trying to get greater participation > > > > but it's just not happening. > > > > > > I suggest you stop using subscriber-only mailing lists and > > > use linux-arm@vger.kernel.org. > > > > This is main point here is to offload Russell. > > One way to offload Russell is to have competent people reviewing platform > > code for ARM. This is best done by other platform people. > > Me and you - we can helpt. But the people where we need higher > > involvement are already on the list. > > Personally, I'm not on linux-arm@vger.kernel.org and don't plan on > being there either. If people are too stupid to read the maintainers > entry and realise that linux-arm-kernel is moderated and they might > thus have to subscribe to post there then they can be safely ignored. Really? So IDE maintainers have to subscribe before when they want to discuss ARM&CF issues? Sleep maintainers have to subscribe when they want to discuss sleep&ARM? You are offending people by first adding unneccessary & annoying steps to their workflow, and then calling them "too stupid" if they don't follow your stupid rules. (Sometimes subscribing takes _weeks_!) Yes, everyone should just join linux-arm@vger.kernel.org. What is the _advantage_ of heave heavilly moderated mailing list? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 9:02 ` Pavel Machek @ 2009-06-13 9:13 ` Sam Ravnborg 2009-06-13 9:51 ` Russell King - ARM Linux 2009-06-13 10:59 ` Christoph Hellwig 2 siblings, 0 replies; 167+ messages in thread From: Sam Ravnborg @ 2009-06-13 9:13 UTC (permalink / raw) To: Pavel Machek Cc: Ben Dooks, Joe Perches, Russell King - ARM Linux, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove > > Yes, everyone should just join linux-arm@vger.kernel.org. What is the > _advantage_ of heave heavilly moderated mailing list? One of the really big advantages is that this is running on an ARM box, so we get a more stable kernel out of it. Sam ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 9:02 ` Pavel Machek 2009-06-13 9:13 ` Sam Ravnborg @ 2009-06-13 9:51 ` Russell King - ARM Linux 2009-06-13 10:59 ` Christoph Hellwig 2 siblings, 0 replies; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-13 9:51 UTC (permalink / raw) To: Pavel Machek Cc: Ben Dooks, Sam Ravnborg, Joe Perches, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Sat, Jun 13, 2009 at 11:02:40AM +0200, Pavel Machek wrote: > Sometimes subscribing takes _weeks_! Pending subscriptions: pavel@ucw.cz (Pavel Machek) Thu Mar 26 23:01:49 2009 Date: Sun, 29 Mar 2009 12:25:10 +0100 Pavel Machek <pavel@ucw.cz> has been successfully subscribed to Linux-arm-kernel. Yes, this was longer than desirable, but you could only describe it as "weeks" if time passes at a different rate for you. If you want to bash me, do so using facts, not fiction. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 9:02 ` Pavel Machek 2009-06-13 9:13 ` Sam Ravnborg 2009-06-13 9:51 ` Russell King - ARM Linux @ 2009-06-13 10:59 ` Christoph Hellwig 2009-06-13 19:36 ` Russell King - ARM Linux 2 siblings, 1 reply; 167+ messages in thread From: Christoph Hellwig @ 2009-06-13 10:59 UTC (permalink / raw) To: Pavel Machek Cc: Ben Dooks, Sam Ravnborg, Joe Perches, Russell King - ARM Linux, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Sat, Jun 13, 2009 at 11:02:40AM +0200, Pavel Machek wrote: > Really? So IDE maintainers have to subscribe before when they want to > discuss ARM&CF issues? Sleep maintainers have to subscribe when they > want to discuss sleep&ARM? > > You are offending people by first adding unneccessary & annoying steps > to their workflow, and then calling them "too stupid" if they don't > follow your stupid rules. (Sometimes subscribing takes _weeks_!) I'd like to stay out of the other flamewars here, but having a moderated mailinglist for a major architecture or subsystem is a royal pain in the ass. As others here I used to get these stupid rejected without reasons mail a lot (can't remember if it was mostly the arm list or others), and it just freaks me out if I'm supposed to Cc stuff to the relevant mailinglist and can't get through. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 10:59 ` Christoph Hellwig @ 2009-06-13 19:36 ` Russell King - ARM Linux 2009-06-15 9:39 ` Christoph Hellwig 0 siblings, 1 reply; 167+ messages in thread From: Russell King - ARM Linux @ 2009-06-13 19:36 UTC (permalink / raw) To: Christoph Hellwig Cc: Pavel Machek, Ben Dooks, Sam Ravnborg, Joe Perches, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Sat, Jun 13, 2009 at 06:59:06AM -0400, Christoph Hellwig wrote: > On Sat, Jun 13, 2009 at 11:02:40AM +0200, Pavel Machek wrote: > > Really? So IDE maintainers have to subscribe before when they want to > > discuss ARM&CF issues? Sleep maintainers have to subscribe when they > > want to discuss sleep&ARM? > > > > You are offending people by first adding unneccessary & annoying steps > > to their workflow, and then calling them "too stupid" if they don't > > follow your stupid rules. (Sometimes subscribing takes _weeks_!) > > I'd like to stay out of the other flamewars here, but having a moderated > mailinglist for a major architecture or subsystem is a royal pain in the > ass. As others here I used to get these stupid rejected without reasons > mail a lot (can't remember if it was mostly the arm list or others), and > it just freaks me out if I'm supposed to Cc stuff to the relevant > mailinglist and can't get through. I assume you're talking about these messages, which are listed in the archives: http://lists.arm.linux.org.uk/lurker/search/20080207.125824.00000000@ml:linux-arm-kernel,au:hch.en.html http://lists.arm.linux.org.uk/lurker/search/20080207.125824.00000000@ml:linux-arm,au:hch.en.html ? Clearly, if they're in the archives they haven't been rejected. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 19:36 ` Russell King - ARM Linux @ 2009-06-15 9:39 ` Christoph Hellwig 2009-06-15 12:55 ` Pavel Machek ` (2 more replies) 0 siblings, 3 replies; 167+ messages in thread From: Christoph Hellwig @ 2009-06-15 9:39 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Christoph Hellwig, Pavel Machek, Ben Dooks, Sam Ravnborg, Joe Perches, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Sat, Jun 13, 2009 at 08:36:41PM +0100, Russell King - ARM Linux wrote: > I assume you're talking about these messages, which are listed in the > archives: I defintively had tons of posting rejected from moderated mailing lists, and if that happens it's fucking annoying, especially if it's rejected without reason. As I wrote above I can't remember if this actually happened recently for me on the arm list, but having this happen to people who want to contribute patches is just extremly rude and demotivating. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 9:39 ` Christoph Hellwig @ 2009-06-15 12:55 ` Pavel Machek 2009-06-15 15:59 ` Ian Molton 2009-06-16 15:15 ` Jamie Lokier 2 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-15 12:55 UTC (permalink / raw) To: Christoph Hellwig Cc: Russell King - ARM Linux, Ben Dooks, Sam Ravnborg, Joe Perches, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Mon 2009-06-15 05:39:41, Christoph Hellwig wrote: > On Sat, Jun 13, 2009 at 08:36:41PM +0100, Russell King - ARM Linux wrote: > > I assume you're talking about these messages, which are listed in the > > archives: > > I defintively had tons of posting rejected from moderated mailing lists, > and if that happens it's fucking annoying, especially if it's rejected > without reason. > > As I wrote above I can't remember if this actually happened recently for > me on the arm list, but having this happen to people who want to > contribute patches is just extremly rude and demotivating. It happened to me on the arm list, and I don't think it is that long before. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 9:39 ` Christoph Hellwig 2009-06-15 12:55 ` Pavel Machek @ 2009-06-15 15:59 ` Ian Molton 2009-06-16 15:15 ` Jamie Lokier 2 siblings, 0 replies; 167+ messages in thread From: Ian Molton @ 2009-06-15 15:59 UTC (permalink / raw) To: Christoph Hellwig Cc: Russell King - ARM Linux, Pavel Machek, Ben Dooks, Sam Ravnborg, Joe Perches, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove Christoph Hellwig wrote: > On Sat, Jun 13, 2009 at 08:36:41PM +0100, Russell King - ARM Linux wrote: >> I assume you're talking about these messages, which are listed in the >> archives: > > I defintively had tons of posting rejected from moderated mailing lists, > and if that happens it's fucking annoying, Agreed - getting rejects is annoying. > especially if it's rejected without reason. Indeed. > As I wrote above I can't remember if this actually happened recently for > me on the arm list, "I heard that theres a war going on somewhere. I cant remember where, but its a good reason to invade a country halfway round the world anyway..." Nothing to see here. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-15 9:39 ` Christoph Hellwig 2009-06-15 12:55 ` Pavel Machek 2009-06-15 15:59 ` Ian Molton @ 2009-06-16 15:15 ` Jamie Lokier 2 siblings, 0 replies; 167+ messages in thread From: Jamie Lokier @ 2009-06-16 15:15 UTC (permalink / raw) To: Christoph Hellwig Cc: Russell King - ARM Linux, Pavel Machek, Ben Dooks, Sam Ravnborg, Joe Perches, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove Christoph Hellwig wrote: > As I wrote above I can't remember if this actually happened recently for > me on the arm list, but having this happen to people who want to > contribute patches is just extremly rude and demotivating. The main frustration I found, with any list like that, is there's no way at all to submit the message/patch which does not involve a lot of fiddling around and a long memory (if subscription takes time), just to post one message and then unsubscribe. One thing which would soften that, may be the rejection message including a URL or "reply to this rejection to post anyway" option so you can post your message if you really want to by following the URL or replying to the rejection, which spambots and such won't do. -- Jamie ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:38 ` Russell King - ARM Linux ` (2 preceding siblings ...) 2009-06-11 15:15 ` Joe Perches @ 2009-06-12 1:33 ` Ryan Mallon 2009-06-12 12:05 ` Pavel Machek 2009-06-14 9:06 ` Jean-Christophe PLAGNIOL-VILLARD 4 siblings, 1 reply; 167+ messages in thread From: Ryan Mallon @ 2009-06-12 1:33 UTC (permalink / raw) To: Russell King - ARM Linux Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: >> From: Russell King - ARM Linux <linux@arm.linux.org.uk> >> Date: Thu, 11 Jun 2009 12:49:12 +0100 >> >>> I can not keep up with the number of patches that need to be >>> reviewed and ultimately merged. I know this, and I freely admit it, >>> and I have done so on many occasions. >> Then split up the responsibilities to other people instead of being >> the choke point. Controlling everything isn't so important. > > Don't you think that I've been trying to get other people to be more > involved? > > - I've been pushing people to send patches to the relevent mailing > list(s) and maintainer(s) for years. > > - I've been pushing people to send their ARM patches to the ARM > mailing list rather than directly into the patch system for review > (it even has a comment telling people this) so that others can get > involved in reviewing them, and sharing that work load. > > Do you think either have been anywhere near successful? > > For the most part, the answer is no. People concentrate on their own > areas, and won't look at someone with a new class of platforms (eg, > the STMP or W90x900 stuff). > > I'd absolutely love it if the review load could be shared, but for the > most part it just doesn't happen. Everyone's far too busy with their > own stuff to help out (and that's a reason that they'll give if tackled > head on about it.) Question on this: I occasionally review patches where I have the knowledge or interest. Most of the time however, I do not have the hardware needed to actually test the patches, and so my reviews are simply coding style, etc. I don't want to add my acked-by to something I can't test, or am not at reasonably confident is okay (ie haven't tested, but know the hardware well enough to be satisfied the patch is okay by reading it). The problem I see for developers I do reviews for, is that they post a patch, I do a code review, the post an update looking for an acked-by, and the best I can say is "looks okay to me, but get someone else to ack it". Whats the best approach here? Should I just add my Reviewed-by tag, or should can/should I ack patches where I think the code is okay, but can't test. ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon Unit 5, Amuri Park Phone: +64 3 3779127 404 Barbadoes St Fax: +64 3 3779135 PO Box 13 889 Email: ryan@bluewatersys.com Christchurch, 8013 Web: http://www.bluewatersys.com New Zealand Freecall Australia 1800 148 751 USA 1800 261 2934 ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-12 1:33 ` Ryan Mallon @ 2009-06-12 12:05 ` Pavel Machek 0 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-12 12:05 UTC (permalink / raw) To: Ryan Mallon Cc: Russell King - ARM Linux, David Miller, swetland, linux-kernel, linux-arm-kernel, san, rlove On Fri 2009-06-12 13:33:21, Ryan Mallon wrote: > Russell King - ARM Linux wrote: > > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote: > >> From: Russell King - ARM Linux <linux@arm.linux.org.uk> > >> Date: Thu, 11 Jun 2009 12:49:12 +0100 > >> > >>> I can not keep up with the number of patches that need to be > >>> reviewed and ultimately merged. I know this, and I freely admit it, > >>> and I have done so on many occasions. > >> Then split up the responsibilities to other people instead of being > >> the choke point. Controlling everything isn't so important. > > > > Don't you think that I've been trying to get other people to be more > > involved? > > > > - I've been pushing people to send patches to the relevent mailing > > list(s) and maintainer(s) for years. > > > > - I've been pushing people to send their ARM patches to the ARM > > mailing list rather than directly into the patch system for review > > (it even has a comment telling people this) so that others can get > > involved in reviewing them, and sharing that work load. > > > > Do you think either have been anywhere near successful? > > > > For the most part, the answer is no. People concentrate on their own > > areas, and won't look at someone with a new class of platforms (eg, > > the STMP or W90x900 stuff). > > > > I'd absolutely love it if the review load could be shared, but for the > > most part it just doesn't happen. Everyone's far too busy with their > > own stuff to help out (and that's a reason that they'll give if tackled > > head on about it.) > > Question on this: I occasionally review patches where I have the > knowledge or interest. Most of the time however, I do not have the > hardware needed to actually test the patches, and so my reviews are > simply coding style, etc. I don't want to add my acked-by to something I > can't test, or am not at reasonably confident is okay (ie haven't > tested, but know the hardware well enough to be satisfied the patch is > okay by reading it). > > The problem I see for developers I do reviews for, is that they post a > patch, I do a code review, the post an update looking for an acked-by, > and the best I can say is "looks okay to me, but get someone else to ack > it". Whats the best approach here? Should I just add my Reviewed-by tag, > or should can/should I ack patches where I think the code is okay, but > can't test. I believe you have slightly higher standards than neccessary/desirable. I believe it is okay to ack a patch when you don't have a hardware; you can trust original submitter to test it on the hw. As long as the patch is not broken by design, or contain some gross uglyness... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 12:38 ` Russell King - ARM Linux ` (3 preceding siblings ...) 2009-06-12 1:33 ` Ryan Mallon @ 2009-06-14 9:06 ` Jean-Christophe PLAGNIOL-VILLARD 4 siblings, 0 replies; 167+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-06-14 9:06 UTC (permalink / raw) To: Russell King - ARM Linux Cc: David Miller, swetland, pavel, linux-kernel, linux-arm-kernel, san, rlove > For the most part, the answer is no. People concentrate on their own > areas, and won't look at someone with a new class of platforms (eg, > the STMP or W90x900 stuff). Personnaly I do the effort to review other people stuff as I've to do on U-Boot for my Maintainer staff specially when I've to review them also for U-Boot as example the Nomadidk stuff > > I'd absolutely love it if the review load could be shared, but for the > most part it just doesn't happen. Everyone's far too busy with their > own stuff to help out (and that's a reason that they'll give if tackled > head on about it.) > > As I've already said, akpm tried to setup a mutual review between > several ARM folk, but as far as I'm aware, it has so far been > unsuccessful (exactly why I don't know.) > > So to somehow level an accusation at me that I'm tightly controlling this > stuff is way off the mark. I've been trying to get greater participation > but it's just not happening. > > > Or, alternatively, experiment with tools that could potentially make > > you more efficient (patchwork has worked wonders for me). > > If patchwork can replace what my patch system does for me (which is > basically to help ensure that patches don't get lost which need > applying - that's different from logging every single patch) then > I'll gladly look at it. It will mean that some of the sanity checks > on the patch content, which happen automatically with the patch system, > will need to be done manually. > > If patchwork just gathers up every patch which has ever been seen on > a mailing list, then stuff will get lost at a higher rate than today > and it will have a negative impact. I've try the patchwork system for some month and It's for really the same as your patch system but if you configured it correctly it will simplify your life. I've start to develop 2 or 3 scripts that I use with mutt to change the state on a patch and co, to have something near your patch system Best Regards, J. ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 11:18 ` Russell King - ARM Linux 2009-06-11 11:22 ` David Miller @ 2009-06-11 11:42 ` Brian Swetland 1 sibling, 0 replies; 167+ messages in thread From: Brian Swetland @ 2009-06-11 11:42 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, David Miller, linux-kernel, linux-arm-kernel, ibm, san, rlove On Thu, Jun 11, 2009 at 4:18 AM, Russell King - ARM Linux<linux@arm.linux.org.uk> wrote: > On Thu, Jun 11, 2009 at 04:12:39AM -0700, Brian Swetland wrote: >> I think Andrew's idea is a good one, but we just haven't had the time >> to try to sort this out. I'll have to see what we can do here. >> Recently, we've been involved in omap3 work as well and have been >> interacting more with folks in the omap kernel community as a result. > > Brian, > > Can you clear up this thread, which seems to be descending into absurdness. I've been trying to stay out of the non-practical side of things and focus on what can be done to improve the process... > David Miller seems to be of the opinion that I was rude or otherwise > insulting to you. Was this the case? I've never felt that you were being rude or insulting. The quality of the feedback I've gotten on patches from you has been very high. I was a little frustrated with the last round of msm_serial.c review which seemed to involve changing directions a couple times, but these things happen. > Was the only problem you had interacting with me to do with the time it > takes to receive feedback on patches which you'd submitted and getting > them merged? I believe that caused you to question several times whether > you were doing things in the right way. The turnaround time on review is the biggest source of frustration -- I try not to get too bent out of shape about this as it's a lot of code to ask somebody to review and you're obviously pretty busy at the best of times. The last time around I was trying to push out patches in little bursts (5-10 at a time). Not sure if that was too much or too little or so on. Since I tend to have time to work on cleanup for mainline when I get downtime between projects/deadlines, I often end up with a big pile of stuff and a fairly short amount of time in which I can react to review. I try to turn stuff around quickly in the face of feedback. In my ideal world (and I realize this doesn't really fit with the general review model for the kernel), I'd love to get the baseline mach-msm stuff (which doesn't impact stuff outside of that architecture) that is stable and shipping in quite a few devices in without completely gutting and rebuilding it, and then refine it from there. Brian ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 10:34 ` Russell King - ARM Linux 2009-06-11 10:44 ` David Miller 2009-06-11 11:12 ` Brian Swetland @ 2009-06-11 11:18 ` Pavel Machek 2009-06-11 11:34 ` Alan Cox 3 siblings, 0 replies; 167+ messages in thread From: Pavel Machek @ 2009-06-11 11:18 UTC (permalink / raw) To: Russell King - ARM Linux Cc: David Miller, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove On Thu 2009-06-11 11:34:57, Russell King - ARM Linux wrote: > On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote: > > On Thu 2009-06-11 00:02:19, David Miller wrote: > > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > > Date: Wed, 10 Jun 2009 20:48:52 +0100 > > > > > > > In short not as far as I know, and I'm very disappointed with the state > > > > of affairs with google. > > > > > > And of course, this whole android situation has absolutely nothing to > > > do with how much of a pain in that ass you are to deal with as ARM > > > maintainer. > > > > Well, linux-arm-devel being subscribers-only and patch management > > system that needs special headers certainly does not help here :-(. > > That's got nothing to do with it. You're just using that as an excuse > to bash me with. I believe it has something to do with it. linux-arm is effectively a walled garden, away from lkml. Getting patches to linux-arm is more interesting exercise than getting them to linux-i386. For trivial patches, it matters. > However, as a result of the complete lack of effort to update patches > as a result of feedback coupled with my lack of bandwidth to review > complex code implementing things like cross-bridge APIs (eg, ARM <-> > DSP communications channels), Brian basically gave up trying to get > stuff into mainline. > Now, ask yourself this question: why should I have to be the one to > review things like ARM <-> DSP communication channel code? Hint: I > don't want to because I know nothing about the subject. Where should > I send these people to get such code reviewed? No idea, there seems > to be no one _anywhere_ who would seem to be interested in it. I guess the patches should just go to lkml. If 1) they don't mess up common code 2) google is willing to maintain them 3) they look mostly okay to interested parties on lkml ... I guess they should just go in. Maybe they should go into drivers/dsp or drivers/mfd or something if you are not comfortable having them in arch/arm. They can certianly go to drivers/staging... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 10:34 ` Russell King - ARM Linux ` (2 preceding siblings ...) 2009-06-11 11:18 ` Pavel Machek @ 2009-06-11 11:34 ` Alan Cox 3 siblings, 0 replies; 167+ messages in thread From: Alan Cox @ 2009-06-11 11:34 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, David Miller, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove > Now, ask yourself this question: why should I have to be the one to > review things like ARM <-> DSP communication channel code? Hint: I Because you claim to be ARM maintainer and you force all the ARM stuff to go via you ? We have the -next tree these days so if you cut ARM back to common core shared ARM code and all the platform people had their own maintainer (at least those who are competent to do so which is a fair share of them) then you could resolve any collisions in -next. There will probably be a few explosions on the way because code developed under such a tight control model tends to have poor separation in places nobody thought about but they'll fix pretty fast. If you don't want to be reviewing some of the stuff then restructure things so that they don't go through you and you are not the gatekeeper for them. Alan ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 7:37 ` Pavel Machek 2009-06-11 10:00 ` Mark Brown 2009-06-11 10:34 ` Russell King - ARM Linux @ 2009-06-11 17:10 ` Ben Dooks 2 siblings, 0 replies; 167+ messages in thread From: Ben Dooks @ 2009-06-11 17:10 UTC (permalink / raw) To: Pavel Machek Cc: David Miller, linux, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote: > On Thu 2009-06-11 00:02:19, David Miller wrote: > > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > > Date: Wed, 10 Jun 2009 20:48:52 +0100 > > > > > In short not as far as I know, and I'm very disappointed with the state > > > of affairs with google. > > > > And of course, this whole android situation has absolutely nothing to > > do with how much of a pain in that ass you are to deal with as ARM > > maintainer. > > Well, linux-arm-devel being subscribers-only and patch management > system that needs special headers certainly does not help here :-(. And subscribing to a mailing list is so hard to do? I'd point out that the patch tracker has been around for a long time, and has done a great job of keep track of patches. The couple of extra (well documented) lines is worth it to give extra data about how the patch was created. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 7:02 ` David Miller 2009-06-11 7:18 ` Russell King - ARM Linux 2009-06-11 7:37 ` Pavel Machek @ 2009-06-11 17:53 ` Marek Vasut 2009-06-13 0:38 ` Ben Dooks 3 siblings, 0 replies; 167+ messages in thread From: Marek Vasut @ 2009-06-11 17:53 UTC (permalink / raw) To: linux-arm-kernel Cc: David Miller, linux, pavel, linux-kernel, ibm, swetland, san, rlove On Thursday 11 of June 2009 09:02:19 David Miller wrote: > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > Date: Wed, 10 Jun 2009 20:48:52 +0100 > > > In short not as far as I know, and I'm very disappointed with the state > > of affairs with google. > > And of course, this whole android situation has absolutely nothing to > do with how much of a pain in that ass you are to deal with as ARM > maintainer. I had no problems with Russell yet, he always helped me with merging my patches ... hmm > > Absolutely nothing, right? > > :-( > > ------------------------------------------------------------------- > List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel > FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php > Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-11 7:02 ` David Miller ` (2 preceding siblings ...) 2009-06-11 17:53 ` Marek Vasut @ 2009-06-13 0:38 ` Ben Dooks 2009-06-13 2:16 ` David Miller 3 siblings, 1 reply; 167+ messages in thread From: Ben Dooks @ 2009-06-13 0:38 UTC (permalink / raw) To: David Miller Cc: linux, pavel, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove On Thu, Jun 11, 2009 at 12:02:19AM -0700, David Miller wrote: > From: Russell King - ARM Linux <linux@arm.linux.org.uk> > Date: Wed, 10 Jun 2009 20:48:52 +0100 > > > In short not as far as I know, and I'm very disappointed with the state > > of affairs with google. > > And of course, this whole android situation has absolutely nothing to > do with how much of a pain in that ass you are to deal with as ARM > maintainer. If you mean 'pain' as 'having standards', then you're probably right. I bet some of the moaning is coming from the people who seem to expect that since they've written some cess-pool which sort of works for their specific case (a number of vendors fit this category) then they have some right to expect it to be merged into mainline. What's worse is that often trying to convince the vendors that their paritcualy pile of sick is in need of work either gets ignored by the management or if taken in by the techies, is often lost as a these 'porting' teams are often disbanded or moved onto something else by the time the next task comes around. If it wasn't for people with some form of standards devoting their time to trying to keep the tide of evil that some of these companies try to perpetrate out of the kernel, we'd be swimming in an unmanagable mess by now. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' ^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: HTC Dream aka. t-mobile g1 support 2009-06-13 0:38 ` Ben Dooks @ 2009-06-13 2:16 ` David Miller 0 siblings, 0 replies; 167+ messages in thread From: David Miller @ 2009-06-13 2:16 UTC (permalink / raw) To: ben Cc: linux, pavel, linux-kernel, linux-arm-kernel, ibm, swetland, san, rlove From: Ben Dooks <ben@fluff.org> Date: Sat, 13 Jun 2009 01:38:49 +0100 > On Thu, Jun 11, 2009 at 12:02:19AM -0700, David Miller wrote: >> From: Russell King - ARM Linux <linux@arm.linux.org.uk> >> Date: Wed, 10 Jun 2009 20:48:52 +0100 >> >> > In short not as far as I know, and I'm very disappointed with the state >> > of affairs with google. >> >> And of course, this whole android situation has absolutely nothing to >> do with how much of a pain in that ass you are to deal with as ARM >> maintainer. > > If you mean 'pain' as 'having standards', then you're probably right. No, I meant 'pain' as in unnecessarily difficult. ^ permalink raw reply [flat|nested] 167+ messages in thread
end of thread, other threads:[~2009-07-22 20:56 UTC | newest] Thread overview: 167+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-06-10 10:31 HTC Dream aka. t-mobile g1 support Pavel Machek 2009-06-10 11:13 ` Ian Molton 2009-06-10 11:49 ` Pavel Machek 2009-06-10 12:04 ` Ian Molton 2009-06-10 17:43 ` Brian Swetland 2009-06-10 19:47 ` Bob Copeland 2009-06-11 7:24 ` Kalle Valo 2009-06-10 19:58 ` Gary Thomas 2009-06-10 20:09 ` Brian Swetland 2009-06-11 8:10 ` Pavel Machek 2009-06-11 8:27 ` Brian Swetland 2009-06-11 11:09 ` Pavel Machek 2009-06-11 11:24 ` Brian Swetland 2009-06-11 11:48 ` Pavel Machek 2009-06-11 11:53 ` Brian Swetland 2009-06-11 14:57 ` Pavel Machek 2009-06-11 14:58 ` Pavel Machek 2009-06-13 0:41 ` Tim Bird 2009-06-11 12:45 ` Bob Copeland 2009-06-11 13:00 ` Pavel Machek 2009-06-11 15:09 ` Bob Copeland 2009-06-11 14:33 ` Alex Riesen 2009-06-11 14:51 ` Pavel Machek 2009-06-10 19:48 ` Russell King - ARM Linux 2009-06-10 20:24 ` Brian Swetland 2009-06-10 20:47 ` MSM6281 support was: " Stefan Schmidt 2009-06-10 21:08 ` Brian Swetland 2009-06-10 21:28 ` Stefan Schmidt 2009-06-10 21:28 ` Marek Vasut 2009-06-10 21:33 ` Pavel Machek 2009-06-10 22:10 ` Stefan Schmidt 2009-06-10 22:19 ` Pavel Machek 2009-06-11 4:02 ` Valdis.Kletnieks 2009-06-11 7:50 ` Pavel Machek 2009-06-10 21:05 ` Daniel Walker 2009-06-10 21:37 ` Pavel Machek 2009-06-10 21:55 ` Brian Swetland 2009-06-11 8:25 ` Pavel Machek 2009-06-11 8:48 ` Brian Swetland 2009-06-12 15:05 ` Pavel Machek 2009-06-12 15:48 ` David Brown 2009-06-12 16:00 ` David Brown 2009-06-12 16:43 ` Stefan Schmidt 2009-06-12 16:55 ` davidb 2009-06-12 17:35 ` Stefan Schmidt 2009-06-12 20:47 ` HTC Dream compile fixes (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek 2009-06-12 20:50 ` HTC Dream aka. t-mobile g1 support Brian Swetland 2009-06-12 22:02 ` Ian Molton 2009-06-12 22:27 ` Brian Swetland 2009-06-12 22:31 ` Pavel Machek 2009-06-12 22:36 ` Brian Swetland 2009-06-15 17:06 ` Pavel Machek 2009-06-12 22:04 ` Pavel Machek 2009-06-15 17:01 ` Pavel Machek 2009-06-15 17:10 ` Bill Gatliff 2009-06-15 18:32 ` Brian Swetland 2009-06-17 9:11 ` Pavel Machek 2009-06-17 9:40 ` Brian Swetland 2009-06-17 17:16 ` HTC Dream keymap (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek 2009-06-17 21:36 ` HTC Dream aka. t-mobile g1 support Arve Hjønnevåg 2009-06-18 10:13 ` Pavel Machek 2009-06-18 19:33 ` Brian Swetland 2009-06-18 19:38 ` David Miller 2009-06-18 23:07 ` defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support) Pavel Machek 2009-06-22 9:33 ` Jiri Kosina 2009-06-22 17:22 ` Pavel Machek 2009-06-23 13:06 ` HTC Dream in 2.6.31-git? " Pavel Machek 2009-06-23 21:45 ` davidb 2009-06-24 9:10 ` Pavel Machek 2009-06-24 23:37 ` Arve Hjønnevåg 2009-06-25 11:42 ` Pavel Machek 2009-06-26 23:01 ` Pavel Machek 2009-06-11 9:32 ` HTC Dream aka. t-mobile g1 support Mark Brown 2009-06-11 7:02 ` David Miller 2009-06-11 7:18 ` Russell King - ARM Linux 2009-06-11 7:37 ` Pavel Machek 2009-06-11 10:00 ` Mark Brown 2009-06-11 10:34 ` Russell King - ARM Linux 2009-06-11 10:44 ` David Miller 2009-06-11 10:47 ` David Miller 2009-06-11 11:05 ` Russell King - ARM Linux 2009-06-11 11:11 ` David Miller 2009-06-11 10:55 ` Russell King - ARM Linux 2009-06-11 11:04 ` David Miller 2009-06-11 11:12 ` Brian Swetland 2009-06-11 11:18 ` Russell King - ARM Linux 2009-06-11 11:22 ` David Miller 2009-06-11 11:49 ` Russell King - ARM Linux 2009-06-11 12:00 ` David Miller 2009-06-11 12:38 ` Russell King - ARM Linux 2009-06-11 12:54 ` Alan Cox 2009-06-11 13:12 ` Russell King - ARM Linux 2009-06-11 16:26 ` Kevin Hilman 2009-06-11 16:57 ` Nicolas Pitre 2009-07-22 17:54 ` ARM platform trees (was: Re: HTC Dream aka. t-mobile g1 support) Kevin Hilman 2009-07-22 20:55 ` Russell King - ARM Linux 2009-06-11 13:18 ` HTC Dream aka. t-mobile g1 support Brian Swetland 2009-06-11 13:21 ` Tony Lindgren 2009-06-11 13:37 ` Russell King - ARM Linux 2009-06-11 14:00 ` Tony Lindgren 2009-06-11 14:06 ` Russell King - ARM Linux 2009-06-11 15:41 ` Tony Lindgren 2009-06-11 15:51 ` Alan Cox 2009-06-11 17:29 ` Nicolas Pitre 2009-06-11 21:22 ` Ryan Mallon 2009-06-11 21:40 ` H Hartley Sweeten 2009-06-12 1:21 ` Nicolas Pitre 2009-06-12 1:26 ` Ryan Mallon 2009-06-12 1:51 ` Nicolas Pitre 2009-06-12 2:16 ` Brian Swetland 2009-06-12 10:25 ` Ian Molton 2009-06-12 10:35 ` Pavel Machek 2009-06-12 10:40 ` Alan Cox 2009-06-12 10:44 ` Brian Swetland 2009-06-12 11:05 ` Pavel Machek 2009-06-13 7:05 ` Brian Swetland 2009-06-15 16:21 ` davidb 2009-06-15 16:27 ` Pavel Machek 2009-06-15 16:45 ` davidb 2009-06-15 22:25 ` Ben Leslie 2009-06-15 22:39 ` davidb 2009-06-15 23:41 ` Ben Leslie 2009-06-16 6:12 ` davidb 2009-06-15 17:09 ` Pavel Machek 2009-06-12 7:46 ` Alan Cox 2009-06-12 10:26 ` Tony Lindgren 2009-06-11 14:47 ` Pavel Machek 2009-06-11 15:59 ` Russell King - ARM Linux 2009-06-11 13:28 ` Russell King - ARM Linux 2009-06-11 13:32 ` Alan Cox 2009-06-11 13:21 ` Pavel Machek 2009-06-11 15:52 ` Russell King - ARM Linux 2009-06-12 1:27 ` Jamie Lokier 2009-06-11 15:15 ` Joe Perches 2009-06-11 15:39 ` Russell King - ARM Linux 2009-06-11 15:53 ` Joe Perches 2009-06-11 16:08 ` Russell King - ARM Linux 2009-06-11 16:37 ` Bartlomiej Zolnierkiewicz 2009-06-11 16:42 ` Russell King - ARM Linux 2009-06-12 1:14 ` FUJITA Tomonori 2009-06-12 1:23 ` Jamie Lokier 2009-06-12 8:39 ` Bartlomiej Zolnierkiewicz 2009-06-12 17:44 ` Russell King - ARM Linux 2009-06-12 18:38 ` Bartlomiej Zolnierkiewicz 2009-06-12 23:40 ` David Miller 2009-06-12 23:43 ` David Miller 2009-06-11 18:24 ` Sam Ravnborg 2009-06-13 0:30 ` Ben Dooks 2009-06-13 9:02 ` Pavel Machek 2009-06-13 9:13 ` Sam Ravnborg 2009-06-13 9:51 ` Russell King - ARM Linux 2009-06-13 10:59 ` Christoph Hellwig 2009-06-13 19:36 ` Russell King - ARM Linux 2009-06-15 9:39 ` Christoph Hellwig 2009-06-15 12:55 ` Pavel Machek 2009-06-15 15:59 ` Ian Molton 2009-06-16 15:15 ` Jamie Lokier 2009-06-12 1:33 ` Ryan Mallon 2009-06-12 12:05 ` Pavel Machek 2009-06-14 9:06 ` Jean-Christophe PLAGNIOL-VILLARD 2009-06-11 11:42 ` Brian Swetland 2009-06-11 11:18 ` Pavel Machek 2009-06-11 11:34 ` Alan Cox 2009-06-11 17:10 ` Ben Dooks 2009-06-11 17:53 ` Marek Vasut 2009-06-13 0:38 ` Ben Dooks 2009-06-13 2:16 ` David Miller
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.