[GIT PULL] ARM: berlin: Driver changes for v3.18

[GIT PULL] ARM: berlin: Driver changes for v3.18

[Sebastian Hesselbarth]

Guys,

Berlin is a little quiet this time. Antoine is still doing a great job
but ChipIdea USB didn't make it again this time. Let's hope it makes it
next time.

At least we can add the reset driver contained in this PR.

Please pull,

The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:

  Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)

are available in the git repository at:

  git://git.infradead.org/users/hesselba/linux-berlin.git tags/berlin-driver-for-3.18-1

for you to fetch changes up to 72a3643a5f09791a95a85e1ffed6723bafe49a0e:

  reset: add the Berlin reset controller driver (2014-09-11 23:00:48 +0200)

----------------------------------------------------------------
Marvell Berlin SoCs gained a reset driver, which has been
Acked-by Philipp Zabel.

----------------------------------------------------------------
Antoine Tenart (1):
      reset: add the Berlin reset controller driver

 drivers/reset/Makefile       |   1 +
 drivers/reset/reset-berlin.c | 131 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 132 insertions(+)
 create mode 100644 drivers/reset/reset-berlin.c

[GIT PULL] ARM: berlin: SoC changes for v3.18

[Sebastian Hesselbarth]

Nothing scary in here, just select the new reset driver.

Please pull,

The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:

  Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)

are available in the git repository at:

  git://git.infradead.org/users/hesselba/linux-berlin.git tags/berlin-soc-for-3.18-1

for you to fetch changes up to 95ef63ffb4a027a1e74a6225a0feca3c1a6984ec:

  ARM: Berlin: select the reset controller (2014-09-11 23:01:24 +0200)

----------------------------------------------------------------
Just select the new reset driver for Marvell Berlin SoCs.

----------------------------------------------------------------
Antoine Tenart (1):
      ARM: Berlin: select the reset controller

 arch/arm/mach-berlin/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

[GIT PULL] ARM: berlin: DT changes for v3.18

[Sebastian Hesselbarth]

Antoine is still working on GenPHY support for ChipIdea USB, but at least
AHCI support made it in. Also, there is reset bindings and corresponding
changes. Finally, enable a second timer on BG2Q.

Please pull,

The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:

  Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)

are available in the git repository at:

  git://git.infradead.org/users/hesselba/linux-berlin.git tags/berlin-dt-for-3.18-1

for you to fetch changes up to 7e782845040985ab7e431682505ddb419bc1d701:

  ARM: dts: berlin: enable timer 1 for sched_clock (2014-09-11 23:06:29 +0200)

----------------------------------------------------------------
Great work again from Antoine, adding AHCI nodes to BG2Q. This also
contains reset binding docs and corresponding dtsi additions. Last
patch enables a second timer on BG2Q used for sched_clock.

----------------------------------------------------------------
Antoine Tenart (3):
      Documentation: bindings: add reset bindings docs for Marvell Berlin SoCs
      ARM: dts: berlin: add a required reset property in the chip controller node
      ARM: dts: berlin: enable timer 1 for sched_clock

Antoine T?nart (2):
      ARM: berlin: add the AHCI node for the BG2Q
      ARM: berlin: enable the eSATA interface on the BG2Q DMP

 .../devicetree/bindings/arm/marvell,berlin.txt     | 10 ++++++
 arch/arm/boot/dts/berlin2.dtsi                     |  1 +
 arch/arm/boot/dts/berlin2cd.dtsi                   |  1 +
 arch/arm/boot/dts/berlin2q-marvell-dmp.dts         |  8 +++++
 arch/arm/boot/dts/berlin2q.dtsi                    | 41 +++++++++++++++++++++-
 5 files changed, 60 insertions(+), 1 deletion(-)

[GIT PULL] ARM: berlin: Driver changes for v3.18

[Arnd Bergmann]

On Tuesday 23 September 2014, Sebastian Hesselbarth wrote:
> Berlin is a little quiet this time. Antoine is still doing a great job
> but ChipIdea USB didn't make it again this time. Let's hope it makes it
> next time.
> 
> At least we can add the reset driver contained in this PR.

I've pulled all three into the next/late branch, we'll decide next week
whether that makes it into 3.18, based on how things go with the stuff
in the normal branches.

Please try to send stuff earlier next time so it can be part of the
regular submission.

	Arnd

[GIT PULL] ARM: berlin: Driver changes for v3.18

[Sebastian Hesselbarth]

On 01.10.2014 17:03, Arnd Bergmann wrote:
> On Tuesday 23 September 2014, Sebastian Hesselbarth wrote:
>> Berlin is a little quiet this time. Antoine is still doing a great job
>> but ChipIdea USB didn't make it again this time. Let's hope it makes it
>> next time.
>>
>> At least we can add the reset driver contained in this PR.
>
> I've pulled all three into the next/late branch, we'll decide next week
> whether that makes it into 3.18, based on how things go with the stuff
> in the normal branches.
>
> Please try to send stuff earlier next time so it can be part of the
> regular submission.

Hmm, looks like I was really too late this time. Will try to send
earlier PRs next cycle.

Anyway, how should I proceed with this now? Do you want me to reapply
the patches on v3.18-rc1 and proceed with normal for-v3.19 cycle? Or
should I merge arm-soc's next/late into berlin's for-v3.19 branches
to apply new patches on top?

Sebastian

[GIT PULL] ARM: berlin: Driver changes for v3.18

[Arnd Bergmann]

On Monday 20 October 2014 16:34:35 Sebastian Hesselbarth wrote:
> On 01.10.2014 17:03, Arnd Bergmann wrote:
> > On Tuesday 23 September 2014, Sebastian Hesselbarth wrote:
> >> Berlin is a little quiet this time. Antoine is still doing a great job
> >> but ChipIdea USB didn't make it again this time. Let's hope it makes it
> >> next time.
> >>
> >> At least we can add the reset driver contained in this PR.
> >
> > I've pulled all three into the next/late branch, we'll decide next week
> > whether that makes it into 3.18, based on how things go with the stuff
> > in the normal branches.
> >
> > Please try to send stuff earlier next time so it can be part of the
> > regular submission.
> 
> Hmm, looks like I was really too late this time. Will try to send
> earlier PRs next cycle.
> 
> Anyway, how should I proceed with this now? Do you want me to reapply
> the patches on v3.18-rc1 and proceed with normal for-v3.19 cycle? Or
> should I merge arm-soc's next/late into berlin's for-v3.19 branches
> to apply new patches on top?
> 

The former.

We are not going to use the next/late branch this time, and all code
in it will be abandoned, so you should send it again.

Also, you should /never/ base anything on top of any of our next/*
branches. Always use the minimum set of branches as a base instead.

	Arnd

[GIT PULL] ARM: berlin: Driver changes for v3.18

[Sebastian Hesselbarth]

On 20.10.2014 16:36, Arnd Bergmann wrote:
> On Monday 20 October 2014 16:34:35 Sebastian Hesselbarth wrote:
>> On 01.10.2014 17:03, Arnd Bergmann wrote:
>>> On Tuesday 23 September 2014, Sebastian Hesselbarth wrote:
>>>> Berlin is a little quiet this time. Antoine is still doing a great job
>>>> but ChipIdea USB didn't make it again this time. Let's hope it makes it
>>>> next time.
>>>>
>>>> At least we can add the reset driver contained in this PR.
>>>
>>> I've pulled all three into the next/late branch, we'll decide next week
>>> whether that makes it into 3.18, based on how things go with the stuff
>>> in the normal branches.
>>>
>>> Please try to send stuff earlier next time so it can be part of the
>>> regular submission.
>>
>> Hmm, looks like I was really too late this time. Will try to send
>> earlier PRs next cycle.
>>
>> Anyway, how should I proceed with this now? Do you want me to reapply
>> the patches on v3.18-rc1 and proceed with normal for-v3.19 cycle? Or
>> should I merge arm-soc's next/late into berlin's for-v3.19 branches
>> to apply new patches on top?
>>
>
> The former.
>
> We are not going to use the next/late branch this time, and all code
> in it will be abandoned, so you should send it again.

Ok, so I reapply the patches in question on top of v3.18-rc1.

> Also, you should /never/ base anything on top of any of our next/*
> branches. Always use the minimum set of branches as a base instead.

Ok, just wanted to make sure how you planned to deal with the late
branch.

Sebastian