Patchwork arm-soc: Xilinx Zynq DT changes for v3.12

login
register
mail settings
Submitter Michal Simek
Date Aug. 13, 2013, 2:50 p.m.
Message ID <520A47C3.5000106@monstr.eu>
Download mbox
Permalink /patch/266826/
State New
Headers show

Pull-request

git://git.xilinx.com/linux-xlnx.git tags/zynq-dt-for-3.12

Comments

Michal Simek - Aug. 13, 2013, 2:50 p.m.
Hi Arnd and Olof,

please pull this simple DT change to your tree.

Thanks,
Michal

The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:

  Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)

are available in the git repository at:

  git://git.xilinx.com/linux-xlnx.git tags/zynq-dt-for-3.12

for you to fetch changes up to 39c41df9c1950fba0ee6a4e7a63be281e89fe437:

  arm: zynq: dt: Set correct L2 ram latencies (2013-08-13 16:37:35 +0200)

----------------------------------------------------------------
arm: Xilinx Zynq dt changes for v3.12

Fix L2 ram latencies.

----------------------------------------------------------------
Soren Brinkmann (1):
      arm: zynq: dt: Set correct L2 ram latencies

 arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Kevin Hilman - Aug. 13, 2013, 10:46 p.m.
Hi Michal,

Michal Simek <monstr@monstr.eu> writes:

> Hi Arnd and Olof,

I'm now helping out with arm-soc maintenance as well, and am on the
arm@kernel.org alias, so thanks for Cc'ing it.

> please pull this simple DT change to your tree.

Pulled into next/dt.

In the future, it makes things simpler for us if you base on older -rc
releases where possible (c.f. similar request by Olof[1].)  In this
case, it was trivial for me to rebase it onto -rc1 so I've done that
before applying.

Thanks,

Kevin

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/189115.html
Kevin Hilman - Aug. 14, 2013, 12:18 a.m.
Kevin Hilman <khilman@linaro.org> writes:

> Hi Michal,
>
> Michal Simek <monstr@monstr.eu> writes:
>
>> Hi Arnd and Olof,
>
> I'm now helping out with arm-soc maintenance as well, and am on the
> arm@kernel.org alias, so thanks for Cc'ing it.
>
>> please pull this simple DT change to your tree.
>
> Pulled into next/dt.
>
> In the future, it makes things simpler for us if you base on older -rc
> releases where possible (c.f. similar request by Olof[1].)  In this
> case, it was trivial for me to rebase it onto -rc1 so I've done that
> before applying.

Looking closer (thanks to Olof), since your tree is already in
linux-next, my rebasing this would cause problems in -next, so I can't
rebase it.

Either you can rebase it to an earlier -rc (preferred), or I can pull in
-rc5 into next/dt (which is currently causing an unrelated conflict
which I'll have to deal with tomorrow.)

Kevin
Michal Simek - Aug. 14, 2013, 5:50 a.m.
On 08/14/2013 02:18 AM, Kevin Hilman wrote:
> Kevin Hilman <khilman@linaro.org> writes:
> 
>> Hi Michal,
>>
>> Michal Simek <monstr@monstr.eu> writes:
>>
>>> Hi Arnd and Olof,
>>
>> I'm now helping out with arm-soc maintenance as well, and am on the
>> arm@kernel.org alias, so thanks for Cc'ing it.
>>
>>> please pull this simple DT change to your tree.
>>
>> Pulled into next/dt.
>>
>> In the future, it makes things simpler for us if you base on older -rc
>> releases where possible (c.f. similar request by Olof[1].)  In this
>> case, it was trivial for me to rebase it onto -rc1 so I've done that
>> before applying.
> 
> Looking closer (thanks to Olof), since your tree is already in
> linux-next, my rebasing this would cause problems in -next, so I can't
> rebase it.

That's correct but as you probably noticed this branch is not merged
to linux-next. (Only arm-next branch is added there). I want ask Stephen
for removing this branch anyway.

> 
> Either you can rebase it to an earlier -rc (preferred), or I can pull in
> -rc5 into next/dt (which is currently causing an unrelated conflict
> which I'll have to deal with tomorrow.)

I wasn't aware about using earlier -rc. The last information I got
is that these trees should be based on Linux -rc (or tagged if you like) version.
I will keep this in my mind and will use earlier versions in the next pull requests.

It is just one single patch and I believe you have to use rc5
and resolve that all conflicts anyway that's why it is just question
of time when you have to deal with it.

Thanks,
Michal
Olof Johansson - Aug. 14, 2013, 6:17 a.m.
On Tue, Aug 13, 2013 at 10:50 PM, Michal Simek <monstr@monstr.eu> wrote:

> I wasn't aware about using earlier -rc. The last information I got
> is that these trees should be based on Linux -rc (or tagged if you like) version.
> I will keep this in my mind and will use earlier versions in the next pull requests.

Yes, the request to not always go with the latest -rc is new for this
release cycle, so we're generally not pushing back and enforcing it,
just asking nicely :)

However, since Kevin just got up to speed at the same time, he might
have been of the impression that it's something we've been asking for
in the past. :)

The reason for asking is that if we keep getting new and different
-rcs as bases for merge requests, the history starts to look like a
lot of merge-backs from upstream, when there's rarely a real need for
being based on such a new -rc.  Still, it's not a big deal, and we've
been doing it that way now for a couple of years, but I think we could
avoid some of it without causing anyone more work (once they're used
to it :).

> It is just one single patch and I believe you have to use rc5
> and resolve that all conflicts anyway that's why it is just question
> of time when you have to deal with it.

Ah, I saw that there was a branch included from the zynq tree and
figured this was in it. I'll let Kevin handle the merge so it's up to
him if he prefers to rebase back or just merge it in with -rc5.


-Olof
Kevin Hilman - Aug. 14, 2013, 3:20 p.m.
Olof Johansson <olof@lixom.net> writes:

> On Tue, Aug 13, 2013 at 10:50 PM, Michal Simek <monstr@monstr.eu> wrote:
>
>> I wasn't aware about using earlier -rc. The last information I got
>> is that these trees should be based on Linux -rc (or tagged if you like) version.
>> I will keep this in my mind and will use earlier versions in the next pull requests.
>
> Yes, the request to not always go with the latest -rc is new for this
> release cycle, so we're generally not pushing back and enforcing it,
> just asking nicely :)
>
> However, since Kevin just got up to speed at the same time, he might
> have been of the impression that it's something we've been asking for
> in the past. :)
>
> The reason for asking is that if we keep getting new and different
> -rcs as bases for merge requests, the history starts to look like a
> lot of merge-backs from upstream, when there's rarely a real need for
> being based on such a new -rc.  Still, it's not a big deal, and we've
> been doing it that way now for a couple of years, but I think we could
> avoid some of it without causing anyone more work (once they're used
> to it :).
>
>> It is just one single patch and I believe you have to use rc5
>> and resolve that all conflicts anyway that's why it is just question
>> of time when you have to deal with it.
>
> Ah, I saw that there was a branch included from the zynq tree and
> figured this was in it. I'll let Kevin handle the merge so it's up to
> him if he prefers to rebase back or just merge it in with -rc5.

I'll take care of the merge with -rc5 this time.

Kevin