LinuxLists.cc - HTC Dream aka. t-mobile g1 support

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-10 11:49:53

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-10 12:05:15

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-10 17:44:04

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<[email protected]> 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

2009-06-10 19:47:32

by Bob Copeland

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed, Jun 10, 2009 at 1:43 PM, Brian Swetland<[email protected]> 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 %% http://www.bobcopeland.com

2009-06-10 19:49:19

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-10 20:09:13

by Gary Thomas

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<[email protected]> 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
------------------------------------------------------------

2009-06-10 20:09:30

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed, Jun 10, 2009 at 12:58 PM, Gary Thomas<[email protected]> wrote:
> Brian Swetland wrote:
>> On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<[email protected]> 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

2009-06-10 20:24:51

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed, Jun 10, 2009 at 12:48 PM, Russell King - ARM
Linux<[email protected]> 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

2009-06-10 21:05:58

by Daniel Walker

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-10 21:08:45

[permalink] [raw]

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

On Wed, Jun 10, 2009 at 1:47 PM, Stefan
Schmidt<[email protected]> 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

2009-06-10 21:28:18

[permalink] [raw]

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

Hello.

On Wed, 2009-06-10 at 14:08, Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 1:47 PM, Stefan
> Schmidt<[email protected]> 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

2009-06-10 21:28:50

by Marek Vasut

[permalink] [raw]

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

On Wednesday 10 of June 2009 23:08:36 Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 1:47 PM, Stefan
>
> Schmidt<[email protected]> 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

2009-06-10 21:33:18

[permalink] [raw]

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

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

2009-06-10 21:34:55

[permalink] [raw]

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

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

2009-06-10 21:37:41

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-10 21:56:04

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed, Jun 10, 2009 at 2:37 PM, Pavel Machek<[email protected]> 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

2009-06-10 22:10:54

[permalink] [raw]

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

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

2009-06-10 22:20:32

[permalink] [raw]

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

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

2009-06-11 04:03:35

by Valdis Klētnieks

[permalink] [raw]

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

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

Attachments:

(No filename) (226.00 B)

2009-06-11 07:02:24

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Russell King - ARM Linux <[email protected]>
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?

:-(

2009-06-11 07:19:13

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

2009-06-11 07:25:13

by Kalle Valo

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

Bob Copeland <[email protected]> writes:

> On Wed, Jun 10, 2009 at 1:43 PM, Brian Swetland<[email protected]> 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

2009-06-11 07:37:53

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu 2009-06-11 00:02:19, David Miller wrote:
> From: Russell King - ARM Linux <[email protected]>
> 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

2009-06-11 07:50:59

[permalink] [raw]

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

On Thu 2009-06-11 00:02:07, [email protected] 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

2009-06-11 08:10:34

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed 2009-06-10 10:43:53, Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<[email protected]> 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 <[email protected]>

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

2009-06-11 08:25:57

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed 2009-06-10 14:55:52, Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 2:37 PM, Pavel Machek<[email protected]> 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

2009-06-11 08:28:02

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 1:10 AM, Pavel Machek<[email protected]> 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

2009-06-11 08:49:12

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<[email protected]> 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

2009-06-11 09:32:49

by Mark Brown

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-11 10:00:27

by Mark Brown

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-11 10:35:21

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 <[email protected]>
> > 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.

2009-06-11 10:44:26

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Russell King - ARM Linux <[email protected]>
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.

2009-06-11 10:47:38

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: David Miller <[email protected]>
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.

2009-06-11 10:56:17

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 03:44:21AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <[email protected]>
> 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?

2009-06-11 11:04:21

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Russell King - ARM Linux <[email protected]>
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.

2009-06-11 11:05:56

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 03:47:32AM -0700, David Miller wrote:
> From: David Miller <[email protected]>
> 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.

2009-06-11 11:10:00

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu 2009-06-11 01:27:43, Brian Swetland wrote:
> On Thu, Jun 11, 2009 at 1:10 AM, Pavel Machek<[email protected]> 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

2009-06-11 11:11:18

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Russell King - ARM Linux <[email protected]>
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....

2009-06-11 11:12:48

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 3:34 AM, Russell King - ARM
Linux<[email protected]> 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

2009-06-11 11:18:37

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-11 11:18:49

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-11 11:22:32

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Russell King - ARM Linux <[email protected]>
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.

2009-06-11 11:24:17

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 4:09 AM, Pavel Machek<[email protected]> 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

2009-06-11 11:34:15

by Alan

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

> 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

2009-06-11 11:42:58

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 4:18 AM, Russell King - ARM
Linux<[email protected]> 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

2009-06-11 11:48:41

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu 2009-06-11 04:24:03, Brian Swetland wrote:
> On Thu, Jun 11, 2009 at 4:09 AM, Pavel Machek<[email protected]> 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

2009-06-11 11:49:37

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 04:22:26AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <[email protected]>
> 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.

2009-06-11 11:53:20

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 4:48 AM, Pavel Machek<[email protected]> 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

2009-06-11 12:00:36

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Russell King - ARM Linux <[email protected]>
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...

2009-06-11 12:39:21

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <[email protected]>
> 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.

2009-06-11 12:45:42

by Bob Copeland

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 7:09 AM, Pavel Machek<[email protected]> 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 %% http://www.bobcopeland.com

2009-06-11 12:53:47

by Alan

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

> 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

2009-06-11 13:00:54

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu 2009-06-11 08:45:36, Bob Copeland wrote:
> On Thu, Jun 11, 2009 at 7:09 AM, Pavel Machek<[email protected]> 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

2009-06-11 13:13:20

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-11 13:18:29

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 5:54 AM, Alan Cox<[email protected]> 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

2009-06-11 13:21:43

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-11 13:22:05

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

* Alan Cox <[email protected]> [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

2009-06-11 13:29:18

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-11 13:32:05

by Alan

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-11 13:38:09

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-11 14:01:06

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

* Russell King - ARM Linux <[email protected]> [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

2009-06-11 14:06:58

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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?

2009-06-11 14:33:48

by Alex Riesen

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

2009/6/11 Pavel Machek <[email protected]>:
>
> 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.

2009-06-11 14:47:48

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-11 14:51:46

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu 2009-06-11 16:33:36, Alex Riesen wrote:
> 2009/6/11 Pavel Machek <[email protected]>:
> >
> > 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

2009-06-11 14:57:35

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu 2009-06-11 04:53:10, Brian Swetland wrote:
> On Thu, Jun 11, 2009 at 4:48 AM, Pavel Machek<[email protected]> 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

2009-06-11 14:58:25

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

2009-06-11 15:09:37

by Bob Copeland

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 9:00 AM, Pavel Machek<[email protected]> 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 %% http://www.bobcopeland.com

Attachments:

msm-config (34.09 kB)

2009-06-11 15:15:36

by Joe Perches

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 <[email protected]>
> > 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 [email protected].

2009-06-11 15:39:32

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 [email protected].

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?

2009-06-11 15:50:54

by Alan

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-11 15:53:08

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 <[email protected]>
> > > 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.

2009-06-11 15:53:26

by Joe Perches

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 [email protected].
> 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.

2009-06-11 16:00:06

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-11 16:08:59

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-11 16:09:22

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 [email protected].
> > 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.

2009-06-11 16:26:46

by Kevin Hilman

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

Russell King - ARM Linux <[email protected]> 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

2009-06-11 16:32:38

by Bartlomiej Zolnierkiewicz

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 [email protected].
> > > 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 [email protected] 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:
>
> [email protected]

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

2009-06-11 16:42:50

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-11 16:57:50

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, 11 Jun 2009, Kevin Hilman wrote:

> Russell King - ARM Linux <[email protected]> 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

2009-06-11 17:11:18

by Ben Dooks

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

2009-06-11 17:30:35

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-11 17:54:01

by Marek Vasut

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thursday 11 of June 2009 09:02:19 David Miller wrote:
> From: Russell King - ARM Linux <[email protected]>
> 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

2009-06-11 18:22:37

by Sam Ravnborg

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 <[email protected]>
> > > 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 [email protected].

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

2009-06-11 21:28:39

by Ryan Mallon

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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: [email protected] Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934

2009-06-11 21:40:21

by Hartley Sweeten

[permalink] [raw]

Subject: RE: HTC Dream aka. t-mobile g1 support

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

2009-06-12 01:15:34

by FUJITA Tomonori

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, 11 Jun 2009 17:42:18 +0100
Russell King - ARM Linux <[email protected]> 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
[email protected] 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:
>
> [email protected]
>
>

2009-06-12 01:22:22

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 01:23:19

by Jamie Lokier

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 01:25:43

by Ryan Mallon

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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: [email protected] Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934

2009-06-12 01:27:53

by Jamie Lokier

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 01:32:26

by Ryan Mallon

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

Russell King - ARM Linux wrote:
> On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote:
>> From: Russell King - ARM Linux <[email protected]>
>> 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: [email protected] Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934

2009-06-12 01:52:20

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 02:16:41

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 6:51 PM, Nicolas Pitre<[email protected]> 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

2009-06-12 07:46:10

by Alan

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

> 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

2009-06-12 10:25:32

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 10:27:17

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

* Nicolas Pitre <[email protected]> [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

2009-06-12 10:35:38

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 10:40:25

by Alan

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 10:44:42

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Fri, Jun 12, 2009 at 3:35 AM, Pavel Machek<[email protected]> 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

2009-06-12 11:05:50

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Fri 2009-06-12 03:44:21, Brian Swetland wrote:
> On Fri, Jun 12, 2009 at 3:35 AM, Pavel Machek<[email protected]> 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

2009-06-12 12:05:37

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 12:17:36

by Bartlomiej Zolnierkiewicz

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 15:05:28

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu 2009-06-11 01:48:57, Brian Swetland wrote:
> On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<[email protected]> 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 <[email protected]>

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

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2009-06-12 16:03:26

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 16:05:47

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

2009-06-12 16:43:26

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 17:05:03

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 17:35:29

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

Hello.

On Fri, 2009-06-12 at 09:55, [email protected] 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

2009-06-12 17:45:09

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-12 18:33:46

by Bartlomiej Zolnierkiewicz

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-12 20:47:56

[permalink] [raw]

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

Fix compilation of pwrsink with CONFIG_WAKELOCK disabled.

Signed-off-by: Pavel Machek <[email protected]>

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

2009-06-12 20:50:27

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Fri, Jun 12, 2009 at 8:05 AM, Pavel Machek<[email protected]> wrote:
>> On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<[email protected]> 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

2009-06-12 22:02:49

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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?

2009-06-12 22:04:54

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-12 22:27:17

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Fri, Jun 12, 2009 at 3:02 PM, Ian Molton<[email protected]> 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

2009-06-12 22:31:55

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Fri 2009-06-12 15:27:01, Brian Swetland wrote:
> On Fri, Jun 12, 2009 at 3:02 PM, Ian Molton<[email protected]> 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

2009-06-12 22:36:18

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Fri, Jun 12, 2009 at 3:31 PM, Pavel Machek<[email protected]> 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

2009-06-12 23:40:55

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Bartlomiej Zolnierkiewicz <[email protected]>
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.

2009-06-12 23:43:18

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: David Miller <[email protected]>
Date: Fri, 12 Jun 2009 16:40:34 -0700 (PDT)

> From: Bartlomiej Zolnierkiewicz <[email protected]>
> 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.

2009-06-13 00:31:37

by Ben Dooks

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 <[email protected]>
> > > > 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 [email protected].
>
> 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 [email protected] 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 ([email protected], http://www.fluff.org/)

'a smiley only costs 4 bytes'

2009-06-13 00:39:00

by Ben Dooks

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 12:02:19AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <[email protected]>
> 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 ([email protected], http://www.fluff.org/)

'a smiley only costs 4 bytes'

2009-06-13 00:42:18

by Tim Bird

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

Brian Swetland wrote:
> On Thu, Jun 11, 2009 at 4:09 AM, Pavel Machek<[email protected]> 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
=============================

2009-06-13 02:16:55

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Ben Dooks <[email protected]>
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 <[email protected]>
>> 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.

2009-06-13 07:06:09

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Fri, Jun 12, 2009 at 3:44 AM, Brian Swetland<[email protected]> wrote:
> On Fri, Jun 12, 2009 at 3:35 AM, Pavel Machek<[email protected]> 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

2009-06-13 09:02:56

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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 <[email protected]>
> > > > > 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 [email protected].
> >
> > 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 [email protected] 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 [email protected]. 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

2009-06-13 09:10:56

by Sam Ravnborg

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

>
> Yes, everyone should just join [email protected]. 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

2009-06-13 09:51:59

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Sat, Jun 13, 2009 at 11:02:40AM +0200, Pavel Machek wrote:
> Sometimes subscribing takes _weeks_!

Pending subscriptions:
[email protected] (Pavel Machek) Thu Mar 26 23:01:49 2009

Date: Sun, 29 Mar 2009 12:25:10 +0100
Pavel Machek <[email protected]> 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.

2009-06-13 10:59:30

by Christoph Hellwig

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-13 19:44:53

by Jean-Christophe PLAGNIOL-VILLARD

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-14 09:09:37

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 09:40:05

by Christoph Hellwig

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-15 12:56:35

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 16:00:37

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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.

2009-06-15 16:22:20

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 16:27:58

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 16:45:40

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 17:01:18

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 17:07:14

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 17:09:56

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

> 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

2009-06-15 17:10:59

by Bill Gatliff

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 18:32:32

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Mon, Jun 15, 2009 at 10:01 AM, Pavel Machek<[email protected]> 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

2009-06-15 22:25:43

by Ben Leslie

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Tue, Jun 16, 2009 at 2:21 AM, <[email protected]> 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

2009-06-15 22:39:50

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-15 23:41:21

by Ben Leslie

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Tue, Jun 16, 2009 at 8:39 AM, <[email protected]> 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

2009-06-16 06:13:22

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-16 15:16:22

by Jamie Lokier

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

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

2009-06-17 09:11:54

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

> > ...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 <[email protected]>

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

2009-06-17 09:40:49

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed, Jun 17, 2009 at 2:11 AM, Pavel Machek<[email protected]> 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

2009-06-17 17:16:24

[permalink] [raw]

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

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

---
commit abde64fc50078f6b5fa3773c652eef8d3079225f
tree d2fe81626af1922cff8a924e7e5aa193d817fd7e
parent a7571e0d1492573d67a999efb9acf30781a471e8
author Pavel <[email protected]> Wed, 17 Jun 2009 19:15:29 +0200
committer Pavel <[email protected]> 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 <[email protected]>
+#
+# 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

2009-06-17 21:36:55

by Arve Hjønnevåg

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed, Jun 17, 2009 at 2:40 AM, Brian Swetland<[email protected]> wrote:
> On Wed, Jun 17, 2009 at 2:11 AM, Pavel Machek<[email protected]> 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

2009-06-18 10:13:22

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Wed 2009-06-17 14:36:50, Arve Hj?nnev?g wrote:
> On Wed, Jun 17, 2009 at 2:40 AM, Brian Swetland<[email protected]> wrote:
> > On Wed, Jun 17, 2009 at 2:11 AM, Pavel Machek<[email protected]> 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

2009-06-18 19:34:05

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 18, 2009 at 3:13 AM, Pavel Machek<[email protected]> 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

2009-06-18 19:38:54

[permalink] [raw]

Subject: Re: HTC Dream aka. t-mobile g1 support

From: Brian Swetland <[email protected]>
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.

2009-06-18 23:07:20

[permalink] [raw]

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

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

2009-06-22 09:33:39

by Jiri Kosina

[permalink] [raw]

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

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

2009-06-22 17:22:24

[permalink] [raw]

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

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

2009-06-23 13:06:27

[permalink] [raw]

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

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

2009-06-23 21:45:54

[permalink] [raw]

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

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

2009-06-24 09:10:53

[permalink] [raw]

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

On Tue 2009-06-23 14:45:43, [email protected] 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

2009-06-24 23:37:40

by Arve Hjønnevåg

[permalink] [raw]

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

On Wed, Jun 24, 2009 at 2:10 AM, Pavel Machek<[email protected]> wrote:
> On Tue 2009-06-23 14:45:43, [email protected] 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

2009-06-25 11:42:49

[permalink] [raw]

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

On Wed 2009-06-24 16:37:33, Arve Hj?nnev?g wrote:
> On Wed, Jun 24, 2009 at 2:10 AM, Pavel Machek<[email protected]> wrote:
> > On Tue 2009-06-23 14:45:43, [email protected] 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

2009-06-26 23:02:18

[permalink] [raw]

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

On Wed 2009-06-24 16:37:33, Arve Hj?nnev?g wrote:
> On Wed, Jun 24, 2009 at 2:10 AM, Pavel Machek<[email protected]> wrote:
> > On Tue 2009-06-23 14:45:43, [email protected] 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

Attachments:

(No filename) (1.33 kB)
.config (34.31 kB)
Download all attachments

2009-07-22 17:54:12

by Kevin Hilman

[permalink] [raw]

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

Russell King - ARM Linux <[email protected]> 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

2009-07-22 20:56:14