[Gta04-owner] Updates for gta04 DTS file.

Dr. H. Nikolaus Schaller hns at goldelico.com
Mon Jan 5 23:20:48 CET 2015


Am 05.01.2015 um 23:02 schrieb Dr. H. Nikolaus Schaller <hns at goldelico.com>:

> Hi,
> 
> Am 05.01.2015 um 21:01 schrieb NeilBrown <neilb at suse.de>:
> 
>> On Sun, 4 Jan 2015 12:23:38 +0100 "Dr. H. Nikolaus Schaller"
>> <hns at goldelico.com> wrote:
>> 
>>> Hi Neil,
>>> 
>>> Am 03.01.2015 um 20:27 schrieb NeilBrown <neilb at suse.de>:
>>> 
>>>> 
>>>> Hi Marek, Nikolaus,
>>>> 
>>>> I'm wondering what your plans are for pushing more updates for the gta04 dts
>>>> file upstream?
>>> 
>>> The plan: as fast as we can with our small team. Rome wasn’t built in a day :)
>> 
>> Understood.  So I would like to help build Rome and am trying to find the
>> easiest way to collaborate on this.
> 
> That is welcome.
> 
>> 
>>> 
>>>> There are quite a few fixes that both of us have in our
>>>> different trees and I'm hoping they can go upstream soon.
>>> 
>>> Well, we could think about having one tree to avoid this situation...
>> 
>> We have one tree - Linus maintains it for us.  
> 
> No, I see three trees:
> * Linus'
> * yours
> * gta04-kernel
> 
> which are not in sync and both, the second and third, are almost independently developed and
> have the goal to get merged into Linus'. The question is how (by which collaboration model) things
> are synced.
> 
> At the moment I think they are synced through Linus. I.e. the one who is faster in submitting and
> convincing Linus (and his submaintainers) wins. And the second one was waste of energy (because
> there was no discussion during development - just about the results).
> 
> Is such a competition approach efficient? Is this producing good solutions? I don’t know myself
> and would be interested in opinions of other gta04-owners how they would like to see the gta04
> kernel development been done: competitive or cooperatively?
> 
> 
>> As soon as patches land there
>> they are equally available to everyone.
> 
> which is too late for doing coordinated work upfront to shape what is being upstreamed…
> 
> I mean: we (the gta04 users and project) should have only one tree where we
> develop things until they are mature to hand them over to Linus for maintaining.
> 
>> 
>> 
>>> 
>>>> 
>>>> I have the following 11 patches which I could send upstream with your
>>>> Acked-by, or which I could send you to be forwarded to Tony, or which could
>>>> simply become irrelevant if you'll be sending your own patches upstream soon.
>>> 
>>> Marek as the DT maintainer should send them to lkml adding his ack and proper
>>> attribution of the original author(s).
>> 
>> OK, I'll send him the patches, though as your small team is apparently short
>> of time it might be easier for him to just Ack the patches and then I can
>> send them upstream - there is  plenty of precedent for maintainers not
>> actually handing the patches, just Acking them.
> 
> Acking is the critical piece of work. Not formatting and sending patches. So your offer
> does not reduce significant work.

And, I would like to check and find out who the original author of the changes was
since they are in both trees.

If it was in our gta04-kernel tree and you have just copied it from there or were the
second to reinvent it, it should honestly be signed off by the original author (even
if Marek ack’s and you submit).

Let me show in an example what I mean:

$ git blame arch/arm/boot/dts/omap3-gta04.dtsi (on gta04-kernel.git)

061f0323 arch/arm/boot/dts/omap3-gta04.dts  (H. Nikolaus Schaller 2014-04-09 21:23:38 +0200 588) 		twl_audio: audio {
061f0323 arch/arm/boot/dts/omap3-gta04.dts  (H. Nikolaus Schaller 2014-04-09 21:23:38 +0200 589) 			compatible = "ti,twl4030-audio";
ee07f4f1 arch/arm/boot/dts/omap3-gta04.dts  (H. Nikolaus Schaller 2014-04-08 16:56:42 +0200 590) 
061f0323 arch/arm/boot/dts/omap3-gta04.dts  (H. Nikolaus Schaller 2014-04-09 21:23:38 +0200 591) 			ti,enable-vibra = <1>;
ee07f4f1 arch/arm/boot/dts/omap3-gta04.dts  (H. Nikolaus Schaller 2014-04-08 16:56:42 +0200 592) 
061f0323 arch/arm/boot/dts/omap3-gta04.dts  (H. Nikolaus Schaller 2014-04-09 21:23:38 +0200 593) 			codec {
061f0323 arch/arm/boot/dts/omap3-gta04.dts  (H. Nikolaus Schaller 2014-04-09 21:23:38 +0200 594) 				ti,ramp_delay_value = <3>;
061f0323 arch/arm/boot/dts/omap3-gta04.dts  (H. Nikolaus Schaller 2014-04-09 21:23:38 +0200 595) 			};
6764f648 arch/arm/boot/dts/omap3-gta04.dts  (NeilBrown            2014-03-01 14:58:52 +0100 596) 		};

vs.

From: NeilBrown <neil at brown.name>

Signed-off-by: NeilBrown <neil at brown.name>
---
arch/arm/boot/dts/omap3-gta04.dtsi |    1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 803be76746e0..33a7535afef4 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -225,6 +225,7 @@

		twl_audio: audio {
			compatible = "ti,twl4030-audio";
+			ti,enable-vibra = <1>;
			codec {
			};
		};

In other words: where is documented that it was *my* finding and solution how to enable the vibra back in April 2014?

This is the information that is lost by your process of sending new patches directly to LKML instead
of contributing to the gta04-kernel.git. It overwrites history and authorship information.

For the sdio irg patch it is clear since you were the first to spot the new feature but for
the others it isn’t at first glance.

BR,
Nikolaus

> 
> I understand your urgency but please give us time to do the quality checks your work
> deserves.
> 
>> 
>>> 
>>>> 
>>>> I've included the list of patch titles and the combined diff below.  The
>>>> individual patches are in
>>>> git://neil.brown.name/gta04 dts
>>>> or at
>>>> http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/dts
>>>> 
>>>> or I am happy to post them here.
>>> 
>>> So if easily possible please (re)format them as a patch-set against
>>> 
>>> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/3.19-rc2
>>> 
>>> and submit here.
>> 
>> That doesn't make any sense.  Patches against your tree would not apply
>> upstream,
> 
> Why not? We are based on top of upstream. Just some patches ahead. The 3-way
> git merge should resolve them.
> 
>> so Marek would not be able to send them upstream without
>> re-formatting them to apply to upstream.  So it would be a waste of
>> everyone's time.
> 
> But how do you expect that we test the patches? Just from looking at them?
> 
>> 
>> 
>>> 
>>>> 
>>>> Please let me know how you would like to proceed.
>>> 
>>> Marek will go through them and check if anything is missing/problematic and we
>>> will discuss here (if necessary). Finally he submits it upstream and we all will see
>>> what we get as a response.
>>> 
>>> I have only one diff in doubt (without cross-checking with code): the patch for mmc2
>>> appears to assume driver-features that are not yet in mainline. Or are these new
>>> features of 3.19-rc2?
>> 
>> I assume you are referring to the declaration of a second interrupt line
>> and the pinctrl settings?  This enables the SDIO card to interrupt the CPU.
>> 
>> Support for this went upstream in v3.17:
>> 
>> commit 2cd3a2a54656f9c480b1c7272fc07635d575841b
>> Author: Andreas Fenkart <afenkart at gmail.com>
>> Date:   Thu May 29 10:28:00 2014 +0200
>> 
>>   mmc: omap_hsmmc: Enable SDIO interrupt
> 
> Ah, thanks. We have not noticed this nice sdio feature. There are so many changes in
> upstream hidden in tons of commit messages so that you don’t find all the gold nuggets…
> 
>> 
>> 
>> 
>>> 
>>> What we have learned is that the policy by Tony (and others) is that they reject
>>> DT patches where the driver is not yet capable of using the attributes (and they
>>> expect a bindings document as well).
>> 
>> Of course.  I kept back all the patches which use features that aren't
>> upstream yet.
>> 
>> Thanks,
>> NeilBrown
> 
> BR,
> Nikolaus

BR,
Nikolaus



More information about the Gta04-owner mailing list