HTC Dream aka. t-mobile g1 support

HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Ian Molton]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Ian Molton]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Bob Copeland]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Gary Thomas]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Stefan Schmidt]

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

Re: HTC Dream aka. t-mobile g1 support

[Daniel Walker]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Stefan Schmidt]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Marek Vasut]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Stefan Schmidt]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Valdis.Kletnieks]

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

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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?

:-(

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Kalle Valo]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: MSM6281 support was: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Mark Brown]

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.

Re: HTC Dream aka. t-mobile g1 support

[Mark Brown]

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.

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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.

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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.

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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?

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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.

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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.

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Alan Cox]

> 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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Bob Copeland]

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

Re: HTC Dream aka. t-mobile g1 support

[Alan Cox]

> 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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Tony Lindgren]

* 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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Alan Cox]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Tony Lindgren]

* 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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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?

Re: HTC Dream aka. t-mobile g1 support

[Alex Riesen]

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.

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Bob Copeland]

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

Re: HTC Dream aka. t-mobile g1 support

[Joe Perches]

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.

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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?

Re: HTC Dream aka. t-mobile g1 support

[Tony Lindgren]

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

Re: HTC Dream aka. t-mobile g1 support

[Alan Cox]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Joe Perches]

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.

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Kevin Hilman]

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

Re: HTC Dream aka. t-mobile g1 support

[Bartlomiej Zolnierkiewicz]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Nicolas Pitre]

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

Re: HTC Dream aka. t-mobile g1 support

[Ben Dooks]

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'

Re: HTC Dream aka. t-mobile g1 support

[Nicolas Pitre]

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

Re: HTC Dream aka. t-mobile g1 support

[Marek Vasut]

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

Re: HTC Dream aka. t-mobile g1 support

[Sam Ravnborg]

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

Re: HTC Dream aka. t-mobile g1 support

[Ryan Mallon]

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

RE: HTC Dream aka. t-mobile g1 support

[H Hartley Sweeten]

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

Re: HTC Dream aka. t-mobile g1 support

[FUJITA Tomonori]

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

Re: HTC Dream aka. t-mobile g1 support

[Nicolas Pitre]

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

Re: HTC Dream aka. t-mobile g1 support

[Jamie Lokier]

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

Re: HTC Dream aka. t-mobile g1 support

[Ryan Mallon]

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

Re: HTC Dream aka. t-mobile g1 support

[Jamie Lokier]

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

Re: HTC Dream aka. t-mobile g1 support

[Ryan Mallon]

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

Re: HTC Dream aka. t-mobile g1 support

[Nicolas Pitre]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Alan Cox]

> 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

Re: HTC Dream aka. t-mobile g1 support

[Bartlomiej Zolnierkiewicz]

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

Re: HTC Dream aka. t-mobile g1 support

[Ian Molton]

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

Re: HTC Dream aka. t-mobile g1 support

[Tony Lindgren]

* 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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Alan Cox]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[David Brown]

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

Re: HTC Dream aka. t-mobile g1 support

[David Brown]

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

Re: HTC Dream aka. t-mobile g1 support

[Stefan Schmidt]

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

Re: HTC Dream aka. t-mobile g1 support

[davidb]

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

Re: HTC Dream aka. t-mobile g1 support

[Stefan Schmidt]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Bartlomiej Zolnierkiewicz]

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.

HTC Dream compile fixes (was Re: HTC Dream aka. t-mobile g1 support)

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Ian Molton]

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?

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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.

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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.

Re: HTC Dream aka. t-mobile g1 support

[Ben Dooks]

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'

Re: HTC Dream aka. t-mobile g1 support

[Ben Dooks]

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'

Re: HTC Dream aka. t-mobile g1 support

[Tim Bird]

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

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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.

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Sam Ravnborg]

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

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Christoph Hellwig]

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.

Re: HTC Dream aka. t-mobile g1 support

[Russell King - ARM Linux]

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.

Re: HTC Dream aka. t-mobile g1 support

[Jean-Christophe PLAGNIOL-VILLARD]

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

Re: HTC Dream aka. t-mobile g1 support

[Christoph Hellwig]

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.

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Ian Molton]

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.

Re: HTC Dream aka. t-mobile g1 support

[davidb]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[davidb]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

> 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

Re: HTC Dream aka. t-mobile g1 support

[Bill Gatliff]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[Ben Leslie]

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

Re: HTC Dream aka. t-mobile g1 support

[davidb]

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

Re: HTC Dream aka. t-mobile g1 support

[Ben Leslie]

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

Re: HTC Dream aka. t-mobile g1 support

[davidb]

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

Re: HTC Dream aka. t-mobile g1 support

[Jamie Lokier]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

HTC Dream keymap (was Re: HTC Dream aka. t-mobile g1 support)

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Arve Hjønnevåg]

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

Re: HTC Dream aka. t-mobile g1 support

[Pavel Machek]

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

Re: HTC Dream aka. t-mobile g1 support

[Brian Swetland]

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

Re: HTC Dream aka. t-mobile g1 support

[David Miller]

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.

defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support)

[Pavel Machek]

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

Re: defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support)

[Jiri Kosina]

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

Re: defkeymap making machine useless (was Re: HTC Dream aka. t-mobile g1 support)

[Pavel Machek]

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

HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support)

[Pavel Machek]

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

Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support)

[davidb]

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

Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support)

[Pavel Machek]

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

Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support)

[Arve Hjønnevåg]

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

Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support)

[Pavel Machek]

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

Re: HTC Dream in 2.6.31-git? (was Re: HTC Dream aka. t-mobile g1 support)

[Pavel Machek]

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

ARM platform trees (was: Re: HTC Dream aka. t-mobile g1 support)

[Kevin Hilman]

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

Re: ARM platform trees (was: Re: HTC Dream aka. t-mobile g1 support)

[Russell King - ARM Linux]

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.