[Gta04-owner] Updates for gta04 DTS file.
Dr. H. Nikolaus Schaller
hns at goldelico.com
Mon Jan 5 23:02:32 CET 2015
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:
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
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.
I understand your urgency but please give us time to do the quality checks your work
>>> 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
>>> or I am happy to post them here.
>> So if easily possible please (re)format them as a patch-set against
>> and submit here.
> That doesn't make any sense. Patches against your tree would not apply
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.
More information about the Gta04-owner