[GIT PULL] ARM: realtek: arm64 for v4.12

[GIT PULL] ARM: realtek: arm64 for v4.12

[Andreas Färber]

Hi Arnd and Olof,

This is the initial arm64 pull for Realtek.

Regards,
Andreas

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://github.com/afaerber/linux.git tags/realtek-arm64-soc-for-4.12

for you to fetch changes up to de9aa5308247160950a3ab6420de79014a040699:

  MAINTAINERS: Add Realtek section (2017-05-25 12:24:12 +0200)

----------------------------------------------------------------
Realtek ARM64 SoC for v4.12

This adds a Kconfig symbol for DTs being added, plus a MAINTAINERS entry.

----------------------------------------------------------------
Andreas F?rber (2):
      ARM64: Prepare Realtek RTD1295
      MAINTAINERS: Add Realtek section

 MAINTAINERS                  | 7 +++++++
 arch/arm64/Kconfig.platforms | 6 ++++++
 2 files changed, 13 insertions(+)

[GIT PULL] ARM: realtek: dt64 for v4.12

[Andreas Färber]

Hi Arnd and Olof,

This is the initial dt64 pull for Realtek.
The Kconfig symbol is introduced in the arm64 pull.

Regards,
Andreas

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://github.com/afaerber/linux.git tags/realtek-arm64-dt-for-4.12

for you to fetch changes up to 72a7786c0a0d6554b1d2bd3c6a0c3589d4904fb3:

  ARM64: dts: Add Realtek RTD1295 and Zidoo X9S (2017-05-25 12:13:58 +0200)

----------------------------------------------------------------
Realtek ARM64 based SoC DT for v4.12

This adds an initial DT for the RTD1295 SoC and a TV box based on it.

----------------------------------------------------------------
Andreas F?rber (3):
      dt-bindings: Add vendor prefix for Zidoo
      dt-bindings: arm: Add Realtek RTD1295 bindings
      ARM64: dts: Add Realtek RTD1295 and Zidoo X9S

 Documentation/devicetree/bindings/arm/realtek.txt  |  20 ++++
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/realtek/Makefile               |   5 +
 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts  |  42 +++++++
 arch/arm64/boot/dts/realtek/rtd1295.dtsi           | 131 +++++++++++++++++++++
 6 files changed, 200 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/realtek.txt
 create mode 100644 arch/arm64/boot/dts/realtek/Makefile
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295.dtsi

[GIT PULL] ARM: realtek: arm64 for v4.12

[Olof Johansson]

On Thu, May 25, 2017 at 02:04:03PM +0200, Andreas F??rber wrote:
> Hi Arnd and Olof,
> 
> This is the initial arm64 pull for Realtek.
> 
> Regards,
> Andreas
> 
> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
> 
>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/afaerber/linux.git tags/realtek-arm64-soc-for-4.12

This is v4.13 material at this point, so I've merged it into next/arm64 for
the next merge window (v4.13). Thanks!


-Olof

[GIT PULL] ARM: realtek: dt64 for v4.12

[Olof Johansson]

On Thu, May 25, 2017 at 02:04:04PM +0200, Andreas F??rber wrote:
> Hi Arnd and Olof,
> 
> This is the initial dt64 pull for Realtek.
> The Kconfig symbol is introduced in the arm64 pull.
> 
> Regards,
> Andreas
> 
> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
> 
>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/afaerber/linux.git tags/realtek-arm64-dt-for-4.12

Merged into next/dt64 for v4.13. Thanks!


-Olof

[GIT PULL] ARM: realtek: arm64 for v4.12

[Andreas Färber]

Hi Olof,

Am 02.06.2017 um 02:28 schrieb Olof Johansson:
> On Thu, May 25, 2017 at 02:04:03PM +0200, Andreas F??rber wrote:
>> Hi Arnd and Olof,
>>
>> This is the initial arm64 pull for Realtek.
>>
>> Regards,
>> Andreas
>>
>> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
>>
>>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
>>
>> are available in the git repository at:
>>
>>   git://github.com/afaerber/linux.git tags/realtek-arm64-soc-for-4.12
> 
> This is v4.13 material at this point, so I've merged it into next/arm64 for
> the next merge window (v4.13). Thanks!

Arnd had told me to rebase onto v4.12-rc1 (from v4.11-rc1) but to not
wait for the 4.13 merge window. Therefore I submitted it for 4.12.
Miscommunication? Either way works for me.

Now that you have merged ARCH_REALTEK here, should we update the arm64
defconfig to enable it? I just verified on arm-soc.git for-next that's
it's disabled by default; the only other disabled ones are ARCH_BRCMSTB
and to-be-dropped ARCH_VULCAN. Question is, should it be useful to users
before we do so, or is build-testing enough of a reason?

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

[GIT PULL] ARM: realtek: arm64 for v4.12

[Arnd Bergmann]

On Fri, Jun 2, 2017 at 2:32 PM, Andreas F?rber <afaerber@suse.de> wrote:
> Hi Olof,
>
> Am 02.06.2017 um 02:28 schrieb Olof Johansson:
>> On Thu, May 25, 2017 at 02:04:03PM +0200, Andreas F??rber wrote:
>>> Hi Arnd and Olof,
>>>
>>> This is the initial arm64 pull for Realtek.
>>>
>>> Regards,
>>> Andreas
>>>
>>> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
>>>
>>>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://github.com/afaerber/linux.git tags/realtek-arm64-soc-for-4.12
>>
>> This is v4.13 material at this point, so I've merged it into next/arm64 for
>> the next merge window (v4.13). Thanks!
>
> Arnd had told me to rebase onto v4.12-rc1 (from v4.11-rc1) but to not
> wait for the 4.13 merge window. Therefore I submitted it for 4.12.
> Miscommunication? Either way works for me.

To clarify: by "4.13 merge window", I meant the time when we send pull
requests to Linus, i.e. the two weeks between the 4.12 release and
4.13-rc1.

Since you want the pull request to be part of 4.13, you need to send it
between 4.12-rc1 and 4.13 (ideally early during that time frame), and
have it based on 4.12-rc1. The patches were based on 4.11-rc before,
so I recommended rebasing to reduce the gap between the base
and the merge commit.

Does it make sense now?

> Now that you have merged ARCH_REALTEK here, should we update the arm64
> defconfig to enable it? I just verified on arm-soc.git for-next that's
> it's disabled by default; the only other disabled ones are ARCH_BRCMSTB
> and to-be-dropped ARCH_VULCAN. Question is, should it be useful to users
> before we do so, or is build-testing enough of a reason?

I'd leave that up to you. Send a patch or pull request when you think it should
be enabled. I'd tend to having it only enabled when it at least boots on some
hardware, but we haven't had strong rules about that so far.

      Arnd

[GIT PULL] ARM: realtek: arm64 for v4.12

[Olof Johansson]

[again in plain text. Grr gmail.]


On Fri, Jun 2, 2017 at 6:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jun 2, 2017 at 2:32 PM, Andreas F?rber <afaerber@suse.de> wrote:
>> Hi Olof,
>>
>> Am 02.06.2017 um 02:28 schrieb Olof Johansson:
>>> On Thu, May 25, 2017 at 02:04:03PM +0200, Andreas F??rber wrote:
>>>> Hi Arnd and Olof,
>>>>
>>>> This is the initial arm64 pull for Realtek.
>>>>
>>>> Regards,
>>>> Andreas
>>>>
>>>> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
>>>>
>>>>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   git://github.com/afaerber/linux.git tags/realtek-arm64-soc-for-4.12
>>>
>>> This is v4.13 material at this point, so I've merged it into next/arm64 for
>>> the next merge window (v4.13). Thanks!
>>
>> Arnd had told me to rebase onto v4.12-rc1 (from v4.11-rc1) but to not
>> wait for the 4.13 merge window. Therefore I submitted it for 4.12.
>> Miscommunication? Either way works for me.
>
> To clarify: by "4.13 merge window", I meant the time when we send pull
> requests to Linus, i.e. the two weeks between the 4.12 release and
> 4.13-rc1.
>
> Since you want the pull request to be part of 4.13, you need to send it
> between 4.12-rc1 and 4.13 (ideally early during that time frame), and
> have it based on 4.12-rc1. The patches were based on 4.11-rc before,
> so I recommended rebasing to reduce the gap between the base
> and the merge commit.
>
> Does it make sense now?

And just to clarify: You did exactly what we want our platform
maintainers to do, Andreas -- the only disconnect seems to be that it
was 4.13 material instead of 4.12 by now.

I.e. timing for sending this is great -- please do it as early as you
can during -rc series, and try to get amount of submissions down to
mostly a trickle towards -rc6 and later, i.e. only smaller incremental
stuff with the bulk landing early.

If you can. :)

>
> > Now that you have merged ARCH_REALTEK here, should we update the arm64
> > defconfig to enable it? I just verified on arm-soc.git for-next that's
> > it's disabled by default; the only other disabled ones are ARCH_BRCMSTB
> > and to-be-dropped ARCH_VULCAN. Question is, should it be useful to users
> > before we do so, or is build-testing enough of a reason?
>
> I'd leave that up to you. Send a patch or pull request when you think it should
> be enabled. I'd tend to having it only enabled when it at least boots on some
> hardware, but we haven't had strong rules about that so far.


Agreed. We can enable now or later, no big deal.

Getting build coverage early doesn't hurt but if it doesn't really
boot anywhere there's not much other use in enabling.


-Olof

[GIT PULL] ARM: realtek: arm64 for v4.12

[Andreas Färber]

Am 02.06.2017 um 21:33 schrieb Olof Johansson:
> On Fri, Jun 2, 2017 at 6:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Fri, Jun 2, 2017 at 2:32 PM, Andreas F?rber <afaerber@suse.de> wrote:
>>> Am 02.06.2017 um 02:28 schrieb Olof Johansson:
>>>> On Thu, May 25, 2017 at 02:04:03PM +0200, Andreas F??rber wrote:
>>>>> Hi Arnd and Olof,
>>>>>
>>>>> This is the initial arm64 pull for Realtek.
>>>>>
>>>>> Regards,
>>>>> Andreas
>>>>>
>>>>> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
>>>>>
>>>>>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>>   git://github.com/afaerber/linux.git tags/realtek-arm64-soc-for-4.12
>>>>
>>>> This is v4.13 material at this point, so I've merged it into next/arm64 for
>>>> the next merge window (v4.13). Thanks!
>>>
>>> Arnd had told me to rebase onto v4.12-rc1 (from v4.11-rc1) but to not
>>> wait for the 4.13 merge window. Therefore I submitted it for 4.12.
>>> Miscommunication? Either way works for me.
>>
>> To clarify: by "4.13 merge window", I meant the time when we send pull
>> requests to Linus, i.e. the two weeks between the 4.12 release and
>> 4.13-rc1.
>>
>> Since you want the pull request to be part of 4.13, you need to send it
>> between 4.12-rc1 and 4.13 (ideally early during that time frame), and
>> have it based on 4.12-rc1. The patches were based on 4.11-rc before,
>> so I recommended rebasing to reduce the gap between the base
>> and the merge commit.
>>
>> Does it make sense now?

Yeah, so it was indeed a miscommunication. With 4.13 merge window I had
mainly meant what to name my branches. I have now renamed them from
realtek/v4.12/foo to realtek/v4.13/foo. Similarly, my tags that you
pulled had the 4.12 version (I could've fixed that in a v2).

> And just to clarify: You did exactly what we want our platform
> maintainers to do, Andreas -- the only disconnect seems to be that it
> was 4.13 material instead of 4.12 by now.
> 
> I.e. timing for sending this is great -- please do it as early as you
> can during -rc series, and try to get amount of submissions down to
> mostly a trickle towards -rc6 and later, i.e. only smaller incremental
> stuff with the bulk landing early.
> 
> If you can. :)

Well, whatever we can sort out with Realtek as example will make the
next ones easier. :)

Actions Semi will need twice the amount of branches and has dependencies
between dt and dt64 bindings, as well as actual C code for mach-actions,
plus tty, clocksource and power domain driver dependencies.

>>> Now that you have merged ARCH_REALTEK here, should we update the arm64
>>> defconfig to enable it? I just verified on arm-soc.git for-next that's
>>> it's disabled by default; the only other disabled ones are ARCH_BRCMSTB
>>> and to-be-dropped ARCH_VULCAN. Question is, should it be useful to users
>>> before we do so, or is build-testing enough of a reason?
>>
>> I'd leave that up to you. Send a patch or pull request when you think it should
>> be enabled. I'd tend to having it only enabled when it at least boots on some
>> hardware, but we haven't had strong rules about that so far.
> 
> Agreed. We can enable now or later, no big deal.
> 
> Getting build coverage early doesn't hurt but if it doesn't really
> boot anywhere there's not much other use in enabling.

Let's wait until we have more than DTs then.

Arnd's QNAP link has code for the "Realtek,rtk-irq-mux" node needed for
serial interrupts in arch/arm/mach-rtk119x/rtk_irq_mux.c - will look
into forward-porting that, for non-earlycon serial output without hacks.

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)