Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1674253 > unrolled thread

[PATCH 0/5] ARM: Socionext MB86S71 and Fujitsu F-Cue enablement

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/5] ARM: Socionext MB86S71 and Fujitsu F-Cue enablement Andreas Färber <afaerber@suse.de> - 2017-06-25 19:10 +0200
    [PATCH 5/5] ARM: dts: mb86s71-f-cue: Add fake UART0 clock Andreas Färber <afaerber@suse.de> - 2017-06-25 19:10 +0200
    [PATCH 1/5] clk: mb86s7x: Suppress build Andreas Färber <afaerber@suse.de> - 2017-06-25 19:10 +0200
      Re: [PATCH 1/5] clk: mb86s7x: Suppress build Stephen Boyd <sboyd@codeaurora.org> - 2017-06-28 20:00 +0200
        Re: [PATCH 1/5] clk: mb86s7x: Suppress build Jassi Brar <jaswinder.singh@linaro.org> - 2017-06-28 20:00 +0200
          Re: [PATCH 1/5] clk: mb86s7x: Suppress build Stephen Boyd <sboyd@codeaurora.org> - 2017-06-29 00:30 +0200
            Re: [PATCH 1/5] clk: mb86s7x: Suppress build Andreas Färber <afaerber@suse.de> - 2017-06-29 13:20 +0200
    [PATCH 4/5] ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue Andreas Färber <afaerber@suse.de> - 2017-06-25 19:10 +0200
    [PATCH 2/5] ARM: Prepare Socionext MB86S71 Andreas Färber <afaerber@suse.de> - 2017-06-25 19:10 +0200
    [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue Andreas Färber <afaerber@suse.de> - 2017-06-25 19:10 +0200
      Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and  Fujitsu F-Cue Rob Herring <robh@kernel.org> - 2017-06-28 20:00 +0200
        Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and  Fujitsu F-Cue Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-06-29 14:20 +0200
          Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and  Fujitsu F-Cue Andreas Färber <afaerber@suse.de> - 2017-06-29 15:00 +0200
            Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and  Fujitsu F-Cue Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-06-29 19:20 +0200

#1674253 — [PATCH 0/5] ARM: Socionext MB86S71 and Fujitsu F-Cue enablement

Hello,

This mini-series adds initial Device Trees for the Socionext MB86S71 SoC and
the Fujitsu F-Cue board. A clk driver and a gpio driver are already merged,
although the clk driver does not build for lack of an scb mailbox driver.
I am not familiar with the circumstances of those older efforts.

My proposal is to disable the build of the clk driver for now. This allows
to introduce the Kconfig symbol without breaking the build.

With the Device Tree added here it is possible to boot into an initrd,
with one CPU core up.

Cf. https://en.opensuse.org/HCL:F-Cue

More experimental patches at:
https://github.com/afaerber/linux/commits/f-cue-next

Have a lot of fun!

Cheers,
Andreas

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Satoru OKAMOTO <okamoto.satoru@socionext.com>
Cc: devicetree@vger.kernel.org

Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Andy Green <andy.green@linaro.org>
Cc: Vincent Yang <vincent.yang@socionext.com>
Cc: Tetsuya Nuriya <nuriya.tetsuya@socionext.com>
Cc: Michael Turquette <mturquette@linaro.org>
Cc: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>

Andreas Färber (5):
  clk: mb86s7x: Suppress build
  ARM: Prepare Socionext MB86S71
  dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue
  ARM: dts: mb86s71-f-cue: Add fake UART0 clock

 .../devicetree/bindings/arm/socionext.txt          |  17 ++
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts                |  46 ++++++
 arch/arm/boot/dts/mb86s71.dtsi                     | 178 +++++++++++++++++++++
 arch/arm/mach-mb86s7x/Kconfig                      |  10 ++
 arch/arm/mach-mb86s7x/Makefile                     |   1 +
 drivers/clk/Makefile                               |   2 +-
 9 files changed, 258 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

-- 
2.12.3

[toc] | [next] | [standalone]

#1674254 — [PATCH 5/5] ARM: dts: mb86s71-f-cue: Add fake UART0 clock

As long as the clk driver is not building, use a fixed-clock for the UART.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 arch/arm/boot/dts/mb86s71-f-cue.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/mb86s71-f-cue.dts b/arch/arm/boot/dts/mb86s71-f-cue.dts
index 148d1aee11a6..726bf189e8e7 100644
--- a/arch/arm/boot/dts/mb86s71-f-cue.dts
+++ b/arch/arm/boot/dts/mb86s71-f-cue.dts
@@ -27,6 +27,12 @@
 		device_type = "memory";
 		reg = <0x80000000 0x80000000>;
 	};
+
+	uart0_clk: uart0-clk {
+		compatible = "fixed-clock";
+		clock-frequency = <7813000>;
+		#clock-cells = <0>;
+	};
 };
 
 &arch_timer {
@@ -35,4 +41,6 @@
 
 &uart0 {
 	status = "okay";
+	clocks = <&uart0_clk>;
+	clock-names = "apb_pclk";
 };
-- 
2.12.3

[toc] | [prev] | [next] | [standalone]

#1674255 — [PATCH 1/5] clk: mb86s7x: Suppress build

It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:

  drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
   #include <soc/mb86s7x/scb_mhu.h>
            ^~~~~~~~~~~~~~~~~~~~~~~
  compilation terminated.

And when commenting out that line, we get:

  drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
  drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
    ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
          ^~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
    ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
  drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
  drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
     code = CMD_PERI_CLOCK_RATE_SET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
     code = CMD_PERI_CLOCK_RATE_GET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
            CMD_PERI_CLOCK_RATE_SET_REQ
  drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
  drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
     code = CMD_CPU_CLOCK_RATE_GET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
     code = CMD_CPU_CLOCK_RATE_SET_REQ;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
            CMD_CPU_CLOCK_RATE_GET_REQ
  cc1: some warnings being treated as errors
  scripts/Makefile.build:302: recipe for target
  'drivers/clk/clk-mb86s7x.o' failed
  make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1

Comment it out in the Makefile for now.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4f6a812342ed..0f0ab6f03ccd 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_ARCH_EFM32)		+= clk-efm32gg.o
 obj-$(CONFIG_COMMON_CLK_GEMINI)		+= clk-gemini.o
 obj-$(CONFIG_ARCH_HIGHBANK)		+= clk-highbank.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)	+= clk-max77686.o
-obj-$(CONFIG_ARCH_MB86S7X)		+= clk-mb86s7x.o
+#obj-$(CONFIG_ARCH_MB86S7X)		+= clk-mb86s7x.o
 obj-$(CONFIG_ARCH_MOXART)		+= clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK)		+= clk-nomadik.o
 obj-$(CONFIG_ARCH_NSPIRE)		+= clk-nspire.o
-- 
2.12.3

[toc] | [prev] | [next] | [standalone]

#1676964 — Re: [PATCH 1/5] clk: mb86s7x: Suppress build

On 06/25, Andreas Färber wrote:
> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
> 
>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>    #include <soc/mb86s7x/scb_mhu.h>
>             ^~~~~~~~~~~~~~~~~~~~~~~
>   compilation terminated.
> 
> And when commenting out that line, we get:
> 
>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>           ^~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>             CMD_PERI_CLOCK_RATE_SET_REQ
>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>             CMD_CPU_CLOCK_RATE_GET_REQ
>   cc1: some warnings being treated as errors
>   scripts/Makefile.build:302: recipe for target
>   'drivers/clk/clk-mb86s7x.o' failed
>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
> 
> Comment it out in the Makefile for now.
> 

Why not delete the whole driver instead? It's been two years and
the driver has never compiled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1676985 — Re: [PATCH 1/5] clk: mb86s7x: Suppress build

On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 06/25, Andreas Färber wrote:
>> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
>>
>>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>>    #include <soc/mb86s7x/scb_mhu.h>
>>             ^~~~~~~~~~~~~~~~~~~~~~~
>>   compilation terminated.
>>
>> And when commenting out that line, we get:
>>
>>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
>>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
>>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>>           ^~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
>>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
>>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
>>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
>>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
>>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
>>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>             CMD_PERI_CLOCK_RATE_SET_REQ
>>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
>>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
>>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
>>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
>>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>             CMD_CPU_CLOCK_RATE_GET_REQ
>>   cc1: some warnings being treated as errors
>>   scripts/Makefile.build:302: recipe for target
>>   'drivers/clk/clk-mb86s7x.o' failed
>>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
>>
>> Comment it out in the Makefile for now.
>>
>
> Why not delete the whole driver instead? It's been two years and
> the driver has never compiled.
>
I won't complain. The interest of moving powers evaporated in the
midst of upstreaming. Though some next platform is supposed to reuse
the IPs, but I can't say when will that be upstreamed and by whom.

Regards.

[toc] | [prev] | [next] | [standalone]

#1677241 — Re: [PATCH 1/5] clk: mb86s7x: Suppress build

On 06/28, Jassi Brar wrote:
> On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 06/25, Andreas Färber wrote:
> >> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
> >>
> >>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
> >>    #include <soc/mb86s7x/scb_mhu.h>
> >>             ^~~~~~~~~~~~~~~~~~~~~~~
> >>   compilation terminated.
> >>
> >> And when commenting out that line, we get:
> >>
> >>   drivers/clk/clk-mb86s7x.c: In function 'crg_gate_control':
> >>   drivers/clk/clk-mb86s7x.c:72:8: error: implicit declaration of function 'mb86s7x_send_packet' [-Werror=implicit-function-declaration]
> >>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
> >>           ^~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:72:28: error: 'CMD_PERI_CLOCK_GATE_SET_REQ' undeclared (first use in this function)
> >>     ret = mb86s7x_send_packet(CMD_PERI_CLOCK_GATE_SET_REQ,
> >>                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:72:28: note: each undeclared identifier is reported only once for each function it appears in
> >>   drivers/clk/clk-mb86s7x.c: In function 'crg_rate_control':
> >>   drivers/clk/clk-mb86s7x.c:116:10: error: 'CMD_PERI_CLOCK_RATE_SET_REQ' undeclared (first use in this function)
> >>      code = CMD_PERI_CLOCK_RATE_SET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:121:10: error: 'CMD_PERI_CLOCK_RATE_GET_REQ' undeclared (first use in this function); did you mean 'CMD_PERI_CLOCK_RATE_SET_REQ'?
> >>      code = CMD_PERI_CLOCK_RATE_GET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>             CMD_PERI_CLOCK_RATE_SET_REQ
> >>   drivers/clk/clk-mb86s7x.c: In function 'mhu_cluster_rate':
> >>   drivers/clk/clk-mb86s7x.c:276:10: error: 'CMD_CPU_CLOCK_RATE_GET_REQ' undeclared (first use in this function)
> >>      code = CMD_CPU_CLOCK_RATE_GET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >>   drivers/clk/clk-mb86s7x.c:278:10: error: 'CMD_CPU_CLOCK_RATE_SET_REQ' undeclared (first use in this function); did you mean 'CMD_CPU_CLOCK_RATE_GET_REQ'?
> >>      code = CMD_CPU_CLOCK_RATE_SET_REQ;
> >>             ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >>             CMD_CPU_CLOCK_RATE_GET_REQ
> >>   cc1: some warnings being treated as errors
> >>   scripts/Makefile.build:302: recipe for target
> >>   'drivers/clk/clk-mb86s7x.o' failed
> >>   make[2]: *** [drivers/clk/clk-mb86s7x.o] Error 1
> >>
> >> Comment it out in the Makefile for now.
> >>
> >
> > Why not delete the whole driver instead? It's been two years and
> > the driver has never compiled.
> >
> I won't complain. The interest of moving powers evaporated in the
> midst of upstreaming. Though some next platform is supposed to reuse
> the IPs, but I can't say when will that be upstreamed and by whom.
> 

Thanks for the info.

Andreas, can you send a deletion patch instead?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1677617 — Re: [PATCH 1/5] clk: mb86s7x: Suppress build

Am 29.06.2017 um 00:29 schrieb Stephen Boyd:
> On 06/28, Jassi Brar wrote:
>> On 28 June 2017 at 21:43, Stephen Boyd <sboyd@codeaurora.org> wrote:
>>> On 06/25, Andreas Färber wrote:
>>>> It fails to build once we introduce the ARCH_MB86S7X Kconfig symbol:
>>>>
>>>>   drivers/clk/clk-mb86s7x.c:27:10: fatal error: soc/mb86s7x/scb_mhu.h: No such file or directory
>>>>    #include <soc/mb86s7x/scb_mhu.h>
>>>>             ^~~~~~~~~~~~~~~~~~~~~~~
>>>>   compilation terminated.
[...]
>>>> Comment it out in the Makefile for now.
>>>>
>>>
>>> Why not delete the whole driver instead? It's been two years and
>>> the driver has never compiled.
>>>
>> I won't complain. The interest of moving powers evaporated in the
>> midst of upstreaming. Though some next platform is supposed to reuse
>> the IPs, but I can't say when will that be upstreamed and by whom.

Satoru-san is in CC to comment on that aspect. :)

> Thanks for the info.
> 
> Andreas, can you send a deletion patch instead?

I can.

But obviously the idea is to follow-up on this initial series with an
scb mailbox driver (which is blocking both clk and PM domains drivers)
and to either resolve the compilation failure by adding the expected
symbols or to update the clk driver to build against a new driver.

Regards,
Andreas

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

[toc] | [prev] | [next] | [standalone]

#1674256 — [PATCH 4/5] ARM: dts: Add Socionext MB86S71 and Fujitsu F-Cue

Add Device Trees for Socionext MB86S71 SoC and Fujitsu F-Cue board.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 arch/arm/boot/dts/Makefile          |   2 +
 arch/arm/boot/dts/mb86s71-f-cue.dts |  38 ++++++++
 arch/arm/boot/dts/mb86s71.dtsi      | 178 ++++++++++++++++++++++++++++++++++++
 3 files changed, 218 insertions(+)
 create mode 100644 arch/arm/boot/dts/mb86s71-f-cue.dts
 create mode 100644 arch/arm/boot/dts/mb86s71.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35dc9a7..48dda2de0a3d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -526,6 +526,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
 	imx28-m28evk.dtb \
 	imx28-sps1.dtb \
 	imx28-tx28.dtb
+dtb-$(CONFIG_ARCH_MB86S7X) += \
+	mb86s71-f-cue.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
 	ste-nomadik-s8815.dtb \
 	ste-nomadik-nhk15.dtb
diff --git a/arch/arm/boot/dts/mb86s71-f-cue.dts b/arch/arm/boot/dts/mb86s71-f-cue.dts
new file mode 100644
index 000000000000..148d1aee11a6
--- /dev/null
+++ b/arch/arm/boot/dts/mb86s71-f-cue.dts
@@ -0,0 +1,38 @@
+/*
+ * Fujitsu F-Cue board
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "mb86s71.dtsi"
+
+/ {
+	compatible = "fujitsu,f-cue", "fujitsu,mb86s71";
+	model = "Fujitsu F-Cue";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	/* vendor U-Boot looks for /memory */
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+};
+
+&arch_timer {
+	clock-frequency = <125000000>;
+};
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/mb86s71.dtsi b/arch/arm/boot/dts/mb86s71.dtsi
new file mode 100644
index 000000000000..154f1ab89f0a
--- /dev/null
+++ b/arch/arm/boot/dts/mb86s71.dtsi
@@ -0,0 +1,178 @@
+/*
+ * Socionext MB86S71 SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "fujitsu,mb86s71";
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x0>;
+			cci-control-port = <&cci_control4>;
+			next-level-cache = <&l2_big>;
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x1>;
+			cci-control-port = <&cci_control4>;
+			next-level-cache = <&l2_big>;
+		};
+
+		cpu2: cpu@100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x100>;
+			cci-control-port = <&cci_control3>;
+			next-level-cache = <&l2_little>;
+		};
+
+		cpu3: cpu@101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x101>;
+			cci-control-port = <&cci_control3>;
+			next-level-cache = <&l2_little>;
+		};
+
+		l2_big: l2-cache-big {
+			compatible = "cache";
+		};
+
+		l2_little: l2-cache-little {
+			compatible = "cache";
+		};
+	};
+
+	arch_timer: timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+		             <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	pmu-big {
+		compatible = "arm,cortex-a15-pmu";
+		interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+		             <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>;
+	};
+
+	pmu-little {
+		compatible = "arm,cortex-a7-pmu";
+		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+		             <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu2>, <&cpu3>;
+	};
+
+	cci@2c090000 {
+		compatible = "arm,cci-400";
+		reg = <0x2c090000 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x2c090000 0x10000>;
+
+		cci_control0: slave-if@1000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x1000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control1: slave-if@2000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x2000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control2: slave-if@3000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x3000 0x1000>;
+			interface-type = "ace-lite";
+		};
+
+		cci_control3: slave-if@4000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x4000 0x1000>;
+			interface-type = "ace";
+		};
+
+		cci_control4: slave-if@5000 {
+			compatible = "arm,cci-400-ctrl-if";
+			reg = <0x5000 0x1000>;
+			interface-type = "ace";
+		};
+
+		pmu@9000 {
+			compatible = "arm,cci-400-pmu,r0";
+			reg = <0x9000 0x5000>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0x80000000>;
+
+		gic: interrupt-controller@2c001000 {
+			compatible = "arm,cortex-a15-gic";
+			reg = <0x2c001000 0x1000>,
+			      <0x2c002000 0x2000>,
+			      <0x2c004000 0x2000>,
+			      <0x2c006000 0x2000>;
+			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+
+		uart0: serial@31040000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31040000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart1: serial@31050000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31050000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		uart2: serial@31060000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x31060000 0x100>;
+			arm,primecell-periphid = <0x00341011>;
+			interrupts = <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		timer@31080000 {
+			compatible = "arm,sp804";
+			reg = <0x31080000 0x10000>;
+			interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
+			             <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+};
-- 
2.12.3

[toc] | [prev] | [next] | [standalone]

#1674264 — [PATCH 2/5] ARM: Prepare Socionext MB86S71

Introduce CONFIG_ARCH_MB86S7X, which was already being used.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 arch/arm/Kconfig               |  2 ++
 arch/arm/Makefile              |  1 +
 arch/arm/mach-mb86s7x/Kconfig  | 10 ++++++++++
 arch/arm/mach-mb86s7x/Makefile |  1 +
 4 files changed, 14 insertions(+)
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f77c77556..cbf56aa0a9e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -763,6 +763,8 @@ source "arch/arm/mach-keystone/Kconfig"
 
 source "arch/arm/mach-ks8695/Kconfig"
 
+source "arch/arm/mach-mb86s7x/Kconfig"
+
 source "arch/arm/mach-meson/Kconfig"
 
 source "arch/arm/mach-moxart/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..d728548e0e59 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -180,6 +180,7 @@ machine-$(CONFIG_ARCH_KEYSTONE)		+= keystone
 machine-$(CONFIG_ARCH_KS8695)		+= ks8695
 machine-$(CONFIG_ARCH_LPC18XX)		+= lpc18xx
 machine-$(CONFIG_ARCH_LPC32XX)		+= lpc32xx
+machine-$(CONFIG_ARCH_MB86S7X)		+= mb86s7x
 machine-$(CONFIG_ARCH_MESON)		+= meson
 machine-$(CONFIG_ARCH_MMP)		+= mmp
 machine-$(CONFIG_ARCH_MPS2)		+= vexpress
diff --git a/arch/arm/mach-mb86s7x/Kconfig b/arch/arm/mach-mb86s7x/Kconfig
new file mode 100644
index 000000000000..8fe81bb7da0d
--- /dev/null
+++ b/arch/arm/mach-mb86s7x/Kconfig
@@ -0,0 +1,10 @@
+config ARCH_MB86S7X
+	bool "Socionext MB86S7x SoCs"
+	depends on ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GLOBAL_TIMER
+	select ARM_GIC
+	select HAVE_ARM_SCU
+	select HAVE_ARM_TWD if SMP
+	help
+	  Support for MB86S71 SoC family developed by Socionext Inc.
diff --git a/arch/arm/mach-mb86s7x/Makefile b/arch/arm/mach-mb86s7x/Makefile
new file mode 100644
index 000000000000..6bea3d3a2dd7
--- /dev/null
+++ b/arch/arm/mach-mb86s7x/Makefile
@@ -0,0 +1 @@
+obj- += dummy.o
-- 
2.12.3

[toc] | [prev] | [next] | [standalone]

#1674265 — [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
socionext.txt.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

diff --git a/Documentation/devicetree/bindings/arm/socionext.txt b/Documentation/devicetree/bindings/arm/socionext.txt
new file mode 100644
index 000000000000..63227fe7b773
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext.txt
@@ -0,0 +1,17 @@
+Socionext platforms device tree bindings
+----------------------------------------
+
+
+MB86S7x SoC
+===========
+
+Required root node properties:
+
+ - compatible :  must contain "fujitsu,mb86s71" for MB86S71
+
+
+Boards:
+
+Root node property compatible must contain, depending on board:
+
+ - Fujitsu F-Cue: "fujitsu,f-cue"
-- 
2.12.3

[toc] | [prev] | [next] | [standalone]

#1676936 — Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
> socionext.txt.
> 
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt

Acked-by: Rob Herring <robh@kernel.org>

[toc] | [prev] | [next] | [standalone]

#1677685 — Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>> socionext.txt.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>
> Acked-by: Rob Herring <robh@kernel.org>
> --

I do not mind this, but
please note there are multiple product lines in Socionext
because Socionext merged LSI divisions from Panasonic and Fujitsu.

I maintain documents for Socionext UniPhier SoC family
(which inherits SoC architecture of Panasonic)
in Documentation/devicetree/bindings/arm/uniphier/.





-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [next] | [standalone]

#1677726 — Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

Hi Masahiro-san,

Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>> socionext.txt.
>>>
>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>> ---
>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>  1 file changed, 17 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>> --
> 
> I do not mind this, but
> please note there are multiple product lines in Socionext
> because Socionext merged LSI divisions from Panasonic and Fujitsu.
> 
> I maintain documents for Socionext UniPhier SoC family
> (which inherits SoC architecture of Panasonic)
> in Documentation/devicetree/bindings/arm/uniphier/.

Actually you seemed to be lacking bindings beyond the cache controller
for Uniphier:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier

The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
somewhere too, as done here. A git-grep for that particular compatible
only finds derived clk and reset bindings.

Using socionext.txt allows you to add those bindings to a shared file;
if you prefer to host them separately below uniphier/ or as uniphier.txt
do you have a better name suggestion for this one? I was trying to keep
our options open to later add SC2A11 in socionext.txt, and I also saw
some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
don't know a good common name for the non-Panasonic parts. And if we
take fujitsu.txt for MB86S7x to match the vendor prefix then we will
need a separate file for the new SC2A11 IIUC.

Also if you can tell us where the cut between Fujitsu and Socionext
should be done, we can certainly adapt. NXP is still adding all their
new SoCs in fsl.txt, it seems.
(A similar naming issue exists for my not-yet-submitted FM4 patches,
where it changed owners from Fujitsu to Spansion and then to Cypress.)

Best regards,
Andreas

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

[toc] | [prev] | [next] | [standalone]

#1677974 — Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

Hi Andreas,


2017-06-29 21:53 GMT+09:00 Andreas Färber <afaerber@suse.de>:
> Hi Masahiro-san,
>
> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas Färber wrote:
>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>> socionext.txt.
>>>>
>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>  1 file changed, 17 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> --
>>
>> I do not mind this, but
>> please note there are multiple product lines in Socionext
>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>
>> I maintain documents for Socionext UniPhier SoC family
>> (which inherits SoC architecture of Panasonic)
>> in Documentation/devicetree/bindings/arm/uniphier/.
>
> Actually you seemed to be lacking bindings beyond the cache controller
> for Uniphier:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>
> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
> somewhere too, as done here. A git-grep for that particular compatible
> only finds derived clk and reset bindings.

I can care to send a patch later, but it is off-topic here.


> Using socionext.txt allows you to add those bindings to a shared file;
> if you prefer to host them separately below uniphier/ or as uniphier.txt

I was thinking of this way.

For example, TI has omap/, keystone/, davinci.txt, etc.
in this directory level.


> do you have a better name suggestion for this one? I was trying to keep
> our options open to later add SC2A11 in socionext.txt, and I also saw
> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
> don't know a good common name for the non-Panasonic parts. And if we
> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
> need a separate file for the new SC2A11 IIUC.

I have no idea.
Actually, I am not familiar with those SoCs.

I am not sure if there exists a common name for those Fujitsu-derived SoCs.
I think a SoC family name will be helpful to avoid proliferating
arch/arm/mach-{mb86s7x,mb8ac300, ...}.

I see some Socionext guys CC'ed in this mail,
somebody might have information about this.

As I said before, I do not mind adding socionext.txt
and it seems reasonable enough
if there is no common name for those SoCs.



> Also if you can tell us where the cut between Fujitsu and Socionext
> should be done, we can certainly adapt. NXP is still adding all their
> new SoCs in fsl.txt, it seems.
> (A similar naming issue exists for my not-yet-submitted FM4 patches,
> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>

Right, vendor names are not future-proof in some cases.

We use "uniphier" because it is convenient to
make a group of SoCs with similar architecture,
and it will work even if UniPhier product lines are sold again in the
future.  :-)



-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web