Merging openmoko changes upstream

Arnaud Patard (Rtp) arnaud.patard at rtp-net.org
Fri Apr 6 18:09:54 CEST 2007


Harald Welte <laforge at openmoko.org> writes:

Hi !
> On Wed, Apr 04, 2007 at 11:43:12AM +0200, Pavel Machek wrote:
>> Hi!
>> 
>> Openmoko patch series has some "easy to merge" patches to it. Would it
>> be okay if I just took them, cleaned them up a little bit, and send
>> upstream? That way, we can make the diff between upstream and openmoko
>> smaller...
>
> Mh, Ben Dooks was working on integrating of those patches to some
> degree, so we should coordinate on this.

That's definitively the way to go. I remember some s3c24xx patches being
delayed by rmk because Ben didn't review them or at least been CC:'ed

>
>> Prime candidate would be gta01-backlight patch. #ifdef killing is easy
>> enough to do, and should allow upstream merge. When all the

Needs to be also updated to the current kernels. The gta01bl driver
doesn't build on current -rc kernels due to changes in the backlight
layer.

>> gta01-... are merged, gta01-core can be sent to rmk...
>
> First of all, Ben is still waiting for a reply from rmk on whether GTA01
> can be renamed to 'neo1973'.  This rename would affect all patches, so
> this needs to be first.
>
> Secondly, the gta01bl should be generalized in a s3c2410bl, which

btw, why not using my code ? Maybe this question sounds silly but when
writing code for my h1940, I'm making my best to avoid putting h1940
specific part. So, if there's something wrong, I'd like to know it in
order to avoid the same mistake again.
Of course, if you come with a new s3c24xx generic backlight driver and
merge it in the kernel, I'll use to it. 

> receives a platform_data structure on which timer to use.  This way it
> can be used by all s3c2410 boards that use the internal PWM unit to
> control a backlight.

imho the way to go is to write first a s3c24xx PWM driver and then use
it in the backlight code. (Note: it's on my todo list but I've no code
to show). 

>
> So, generally, I would prefer to
>
> 1) receive and integrate cleanup patches to our tree

I assume that patches should respect Documentation/SubmittingPatches,
right ?

> 2) have ben/you/other developers ask if I am fine with the current state
>    of a driver before submitting it mainline.
>
> Apart from that, I'm all for merging mainline.  Thansk for your interest
> in helping out :)


Arnaud





More information about the openmoko-kernel mailing list