Support for Fujitsu MB86S7X SoCs

---
 Documentation/devicetree/bindings/arm/mb86s7x.txt  |   8 +
 .../devicetree/bindings/soc/mb86s7x/scb_mhu.txt    |  35 ++
 MAINTAINERS                                        |   7 +
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/mach-mb86s7x/Kconfig                      |  19 +
 arch/arm/mach-mb86s7x/Makefile                     |   1 +
 arch/arm/mach-mb86s7x/board.c                      |  23 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/mb86s7x/Makefile                       |   4 +
 drivers/soc/mb86s7x/scb_mhu.c                      | 514 +++++++++++++++++++++
 include/soc/mb86s7x/scb_mhu.h                      |  97 ++++
 12 files changed, 712 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/mb86s7x.txt
 create mode 100644 Documentation/devicetree/bindings/soc/mb86s7x/scb_mhu.txt
 create mode 100644 arch/arm/mach-mb86s7x/Kconfig
 create mode 100644 arch/arm/mach-mb86s7x/Makefile
 create mode 100644 arch/arm/mach-mb86s7x/board.c
 create mode 100644 drivers/soc/mb86s7x/Makefile
 create mode 100644 drivers/soc/mb86s7x/scb_mhu.c
 create mode 100644 include/soc/mb86s7x/scb_mhu.h

Documentation/devicetree/bindings/arm/mb86s7x.txt new file +8 -0

new file mode 100644
index 0000000..fbaad20
@@ -0,0 +1,8 @@
+Fujitsu MB86S7X Device Tree Bindings
+
+Fujitsu has a few closely related platforms that are basically different
+configurations of each others. Like MB86S7{0,1,2,3}.
+
+The EVB boards with S70/S73 have the following property:
+Required root node property:
+	compatible: must contain "fujitsu,mb86s70-evb" or "fujitsu,mb86s73-evb"

Documentation/devicetree/bindings/soc/mb86s7x/scb_mhu.txt new file +35 -0

new file mode 100644
index 0000000..f466a05
@@ -0,0 +1,35 @@
+Fujitsu SCB (Mailbox's Remote Firmware) bindings
+------------------------------------------------
+
+The firmware (running of a remote Cortex-M3 master) on Fujitsu's MB86S7X
+platforms is named SCB. The SCB owns most of core h/w IPs like Clock,
+CPUFreq/DVFS, CPUIdle/SMP, Thermal, a recovery block device and even an
+I2C controller. Linux has to map all of these functionalities on to
+the Mailbox API and get things done by the remote master.
+ Let the current state of SCB firmware be versioned 1.0.
+
+Required properties :
+- compatible : Shall contain "fujitsu,mb86s70-scb-1.0"
+- reg : Point to SharedMemory used for Mailbox protocol.
+- mboxes : phandle to the mailbox controller:channel node.
+
+The consumer specifies the desired clock pointing to its phandle.
+
+Example:
+
+	mhu: mhu0 at 2b1f0000 {
+		#mbox-cells = <1>;
+		compatible = "arm,mhu";
+		reg = <0 0x2b1f0000 0x1000>;
+		interrupts = <0 36 4>, /* LP Non-Sec */
+			     <0 35 4>, /* HP Non-Sec */
+			     <0 37 4>; /* Secure */
+		clocks = <&clk 0 2 1>;
+		clock-names = "apb_pclk";
+	};
+
+	mhu_client: scb at 2e000000 {
+		compatible = "fujitsu,mb86s70-scb-1.0";
+		reg = <0 0x2e000000 0x4000>; /* SHM for IPC */
+		mboxes = <&mhu 1>;
+	};

MAINTAINERS +7 -0

index aaa039d..1436e34 100644
@@ -1111,6 +1111,13 @@ M:	Lennert Buytenhek <[email protected]>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 
+ARM/MB86S7X SOC SUPPORT
+M:	Vincent Yang <[email protected]>
+M:	Tetsuya Nuriya <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Supported
+F:	arch/arm/mach-mb86s7x/
+
 ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
 M:	Santosh Shilimkar <[email protected]>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)

arch/arm/Kconfig +2 -0

index 97d07ed..3c80a9b 100644
@@ -884,6 +884,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-msm/Kconfig"

arch/arm/Makefile +1 -0

index c1785ee..c65aff2 100644
@@ -167,6 +167,7 @@ machine-$(CONFIG_ARCH_IXP4XX)		+= ixp4xx
 machine-$(CONFIG_ARCH_KEYSTONE)		+= keystone
 machine-$(CONFIG_ARCH_KS8695)		+= ks8695
 machine-$(CONFIG_ARCH_LPC32XX)		+= lpc32xx
+machine-$(CONFIG_ARCH_MB86S7X)		+= mb86s7x
 machine-$(CONFIG_ARCH_MESON)		+= meson
 machine-$(CONFIG_ARCH_MMP)		+= mmp
 machine-$(CONFIG_ARCH_MOXART)		+= moxart

arch/arm/mach-mb86s7x/Kconfig new file +19 -0

new file mode 100644
index 0000000..f58b104
@@ -0,0 +1,19 @@
+config ARCH_MB86S7X
+	bool "Fujitsu MB86S7x platforms" if ARCH_MULTI_V7
+	select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
+	select ARCH_HAS_CPUFREQ
+	select ARCH_HAS_OPP
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_AMBA
+	select ARM_CCI
+	select ARM_GIC
+	select ARM_TIMER_SP804
+	select BIG_LITTLE
+	select HAVE_ARM_ARCH_TIMER
+	select MAILBOX
+	select PINCTRL
+	select PINCTRL_MB86S7X
+	select PM_OPP
+	select ZONE_DMA if ARM_LPAE
+	help
+	  Support for Fujitsu MB86S7x based platforms

arch/arm/mach-mb86s7x/Makefile new file +1 -0

new file mode 100644
index 0000000..97640b6
@@ -0,0 +1 @@
+obj-$(CONFIG_ARCH_MB86S7X)	+= board.o

arch/arm/mach-mb86s7x/board.c new file +23 -0

new file mode 100644
index 0000000..222b63f
@@ -0,0 +1,23 @@
+/*
+ * Support for the Fujitsu's MB86S7x based devices.
+ *
+ * Copyright (C) 2015 Linaro, LTD
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ */
+
+#include <linux/of.h>
+#include <asm/mach/arch.h>
+
+static const char *mb86s7x_dt_match[] __initconst = {
+	"fujitsu,mb86s70-evb",
+	"fujitsu,mb86s73-evb",
+	NULL,
+};
+
+DT_MACHINE_START(MB86S7X_DT, "Fujitsu MB86S7X-based board")
+	.dt_compat	= mb86s7x_dt_match,
+MACHINE_END

drivers/soc/Makefile +1 -0

index 063113d..fb64bf2 100644
@@ -2,6 +2,7 @@
 # Makefile for the Linux Kernel SOC specific device drivers.
 #
 
+obj-$(CONFIG_ARCH_MB86S7X)	+= mb86s7x/
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-$(CONFIG_SOC_TI)		+= ti/

drivers/soc/mb86s7x/Makefile new file +4 -0

new file mode 100644
index 0000000..f6b96cf
@@ -0,0 +1,4 @@
+#
+# Fujitsu's MB86S7X drivers
+#
+obj-$(CONFIG_ARCH_MB86S7X)	+= scb_mhu.o

drivers/soc/mb86s7x/scb_mhu.c new file +514 -0

514 lines not on this page · raw message

include/soc/mb86s7x/scb_mhu.h new file +97 -0

97 lines not on this page · raw message

Signature · 1 line

1.9.0

Vincent Yang

author

2015-02-03 09:29 UTC #2 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

From: Jassi Brar <[email protected]>

Add driver for the ARM Primecell Message-Handling-Unit(MHU) controller.

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Andy Green <[email protected]>

In reply to Russell King - ARM Linux

---
 .../devicetree/bindings/mailbox/arm-mhu.txt        |  35 ++++
 drivers/mailbox/Kconfig                            |   7 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/arm_mhu.c                          | 203 +++++++++++++++++++++
 4 files changed, 247 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-mhu.txt
 create mode 100644 drivers/mailbox/arm_mhu.c

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +35 -0

new file mode 100644
index 0000000..986a205
@@ -0,0 +1,35 @@
+ARM MHU Mailbox Driver
+======================
+
+The ARM's Message-Handling-Unit (MHU) is a mailbox controller that has
+3 independent channels/links to communicate with remote processor(s).
+ MHU links are hardwired on a platform. A link raises interrupt for any
+received data. However, there is no specified way of knowing if the sent
+data has been read by the remote. This driver assumes the sender polls
+STAT register and the remote clears it after having read the data.
+
+Mailbox Device Node:
+====================
+
+Required properties:
+--------------------
+- compatible:		Shall be "arm,mhu" & "arm,primecell"
+- reg:			Contains the mailbox register address range (base
+			address and length)
+- #mbox-cells		Shall be 1
+- interrupts:		Contains the interrupt information corresponding to
+			each of the 3 links of MHU.
+
+Example:
+--------
+
+	mhu: mailbox at 2b1f0000 {
+		#mbox-cells = <1>;
+		compatible = "arm,mhu", "arm,primecell";
+		reg = <0 0x2b1f0000 0x1000>;
+		interrupts = <0 36 4>,
+			     <0 35 4>,
+			     <0 37 4>;
+		clocks = <&clock 0 2 1>;
+		clock-names = "apb_pclk";
+	};

drivers/mailbox/Kconfig +7 -0

index c04fed9..9238440 100644
@@ -6,6 +6,13 @@ menuconfig MAILBOX
 	  signals. Say Y if your platform supports hardware mailboxes.
 
 if MAILBOX
+
+config ARM_MHU
+	tristate "ARM MHU Mailbox"
+	depends on ARM
+	help
+	  Say Y here if you want to build the ARM MHU controller driver
+
 config PL320_MBOX
 	bool "ARM PL320 Mailbox"
 	depends on ARM_AMBA

drivers/mailbox/Makefile +2 -0

index dd412c2..c83791d 100644
@@ -2,6 +2,8 @@
 
 obj-$(CONFIG_MAILBOX)		+= mailbox.o
 
+obj-$(CONFIG_ARM_MHU)	+= arm_mhu.o
+
 obj-$(CONFIG_PL320_MBOX)	+= pl320-ipc.o
 
 obj-$(CONFIG_OMAP2PLUS_MBOX)	+= omap-mailbox.o

drivers/mailbox/arm_mhu.c new file +203 -0

203 lines not on this page · raw message

Signature · 1 line

1.9.0

Russell King - ARM Linux

2015-02-03 12:32 UTC #3 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

drivers/mailbox/arm_mhu.c line 83

Quoted 11 lines · Vincent Yang

drivers/mailbox/arm_mhu.c new file +11 -0

+static int mhu_send_data(struct mbox_chan *chan, void *data)
+{
+	struct mhu_link *mlink = chan->con_priv;
+
+	pr_debug("%s:%d\n", __func__, __LINE__);
+	if (!mhu_last_tx_done(chan)) {
+		dev_err(chan->mbox->dev, "Last TX(%d) pending!\n", mlink->irq);
+		return -EBUSY;
+	}
+
+	writel_relaxed((u32)data, mlink->tx_reg + INTR_SET_OFS);

Doesn't that cause a GCC warning?

Quoted 11 lines

drivers/mailbox/arm_mhu.c new file +11 -0

+static int mhu_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	int i, err;
+	struct arm_mhu *mhu;
+	struct device *dev = &adev->dev;
+	int mhu_reg[3] = {0x0, 0x20, 0x200};
+
+	err = amba_request_regions(adev, NULL);
+	if (err)
+		return err;
+

drivers/mailbox/arm_mhu.c line 143

Quoted 10 lines

drivers/mailbox/arm_mhu.c new file +10 -0

+	/* Allocate memory for device */
+	mhu = devm_kzalloc(dev, sizeof(*mhu), GFP_KERNEL);
+	if (!mhu)
+		return -ENOMEM;
+
+	mhu->base = devm_ioremap(dev, adev->res.start,
+				 resource_size(&adev->res));
+	if (!mhu->base) {
+		dev_err(dev, "ioremap failed\n");
+		return -ENXIO;

	mhu->base = devm_ioremap_resource(dev, &adev->res);
	if (IS_ERR(mhu->base)) {
		dev_err(dev, "ioremap failed\n");
		return PTR_ERR(mhu->base);

Quoted 16 lines

drivers/mailbox/arm_mhu.c new file +16 -0

+	}
+
+	for (i = 0; i < 3; i++) {
+		mhu->chan[i].con_priv = &mhu->mlink[i];
+		mhu->mlink[i].irq = adev->irq[i];
+		mhu->mlink[i].rx_reg = mhu->base + mhu_reg[i];
+		mhu->mlink[i].tx_reg = mhu->mlink[i].rx_reg + 0x100;
+	}
+
+	mhu->mbox.dev = dev;
+	mhu->mbox.chans = &mhu->chan[0];
+	mhu->mbox.num_chans = 3;
+	mhu->mbox.ops = &mhu_ops;
+	mhu->mbox.txdone_irq = false;
+	mhu->mbox.txdone_poll = true;
+	mhu->mbox.txpoll_period = 10;

drivers/mailbox/arm_mhu.c line 169

Quoted 10 lines

drivers/mailbox/arm_mhu.c new file +10 -0

+
+	amba_set_drvdata(adev, mhu);
+
+	err = mbox_controller_register(&mhu->mbox);
+	if (err) {
+		dev_err(dev, "Failed to register mailboxes %d\n", err);
+		return err;
+	}
+
+	dev_err(dev, "ARM MHU Mailbox registered\n");

Why is this an error?

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Jassi Brar

2015-02-03 14:39 UTC #4 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 15 lines · Russell King - ARM Linux

drivers/mailbox/arm_mhu.c line 83

Quoted 11 lines · Vincent Yang

drivers/mailbox/arm_mhu.c new file +11 -0

+static int mhu_send_data(struct mbox_chan *chan, void *data)
+{
+     struct mhu_link *mlink = chan->con_priv;
+
+     pr_debug("%s:%d\n", __func__, __LINE__);
+     if (!mhu_last_tx_done(chan)) {
+             dev_err(chan->mbox->dev, "Last TX(%d) pending!\n", mlink->irq);
+             return -EBUSY;
+     }
+
+     writel_relaxed((u32)data, mlink->tx_reg + INTR_SET_OFS);

Doesn't that cause a GCC warning?

I don't see any, but I'll drop the cast.

Quoted 18 lines

drivers/mailbox/arm_mhu.c new file +18 -0

+static int mhu_probe(struct amba_device *adev, const struct amba_id *id)
+{
+     int i, err;
+     struct arm_mhu *mhu;
+     struct device *dev = &adev->dev;
+     int mhu_reg[3] = {0x0, 0x20, 0x200};
+
+     err = amba_request_regions(adev, NULL);
+     if (err)
+             return err;
+
+     /* Allocate memory for device */
+     mhu = devm_kzalloc(dev, sizeof(*mhu), GFP_KERNEL);
+     if (!mhu)
+             return -ENOMEM;
+
+     mhu->base = devm_ioremap(dev, adev->res.start,
+                              resource_size(&adev->res));

Quoted 9 lines

drivers/mailbox/arm_mhu.c line 143

Quoted 3 lines

drivers/mailbox/arm_mhu.c new file +3 -0

+     if (!mhu->base) {
+             dev_err(dev, "ioremap failed\n");
+             return -ENXIO;

        mhu->base = devm_ioremap_resource(dev, &adev->res);
        if (IS_ERR(mhu->base)) {
                dev_err(dev, "ioremap failed\n");
                return PTR_ERR(mhu->base);

Quoted 11 lines

drivers/mailbox/arm_mhu.c line 169

Quoted 8 lines

drivers/mailbox/arm_mhu.c new file +8 -0

+
+     err = mbox_controller_register(&mhu->mbox);
+     if (err) {
+             dev_err(dev, "Failed to register mailboxes %d\n", err);
+             return err;
+     }
+
+     dev_err(dev, "ARM MHU Mailbox registered\n");

Why is this an error?

ouch! this sneaked in from debugging code. Will make it info.

Thanks.

Russell King - ARM Linux

2015-02-03 14:46 UTC #5 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 17 lines · Jassi Brar

Quoted 15 lines · Russell King - ARM Linux

drivers/mailbox/arm_mhu.c line 83

Quoted 11 lines · Vincent Yang

drivers/mailbox/arm_mhu.c new file +11 -0

+static int mhu_send_data(struct mbox_chan *chan, void *data)
+{
+     struct mhu_link *mlink = chan->con_priv;
+
+     pr_debug("%s:%d\n", __func__, __LINE__);
+     if (!mhu_last_tx_done(chan)) {
+             dev_err(chan->mbox->dev, "Last TX(%d) pending!\n", mlink->irq);
+             return -EBUSY;
+     }
+
+     writel_relaxed((u32)data, mlink->tx_reg + INTR_SET_OFS);

Doesn't that cause a GCC warning?

Quoted 1 line

I don't see any, but I'll drop the cast.

A cast is probably needed. You're right that GCC no longer warns about this - I'm pretty sure it used to complain about casting pointers to ints, and we used to need to cast to "unsigned long" first.

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Arnd Bergmann

maintainer

2015-02-03 15:25 UTC #6 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 18 lines · On Tuesday 03 February 2015 14:46:11 Russell King - ARM Linux wrote:

Quoted 17 lines · Jassi Brar

Quoted 15 lines · Russell King - ARM Linux

drivers/mailbox/arm_mhu.c line 83

Quoted 11 lines · Vincent Yang

drivers/mailbox/arm_mhu.c new file +11 -0

+static int mhu_send_data(struct mbox_chan *chan, void *data)
+{
+     struct mhu_link *mlink = chan->con_priv;
+
+     pr_debug("%s:%d\n", __func__, __LINE__);
+     if (!mhu_last_tx_done(chan)) {
+             dev_err(chan->mbox->dev, "Last TX(%d) pending!\n", mlink->irq);
+             return -EBUSY;
+     }
+
+     writel_relaxed((u32)data, mlink->tx_reg + INTR_SET_OFS);

Doesn't that cause a GCC warning?

Quoted 5 lines

Quoted 1 line
I don't see any, but I'll drop the cast.
A cast is probably needed. You're right that GCC no longer warns about this - I'm pretty sure it used to complain about casting pointers to ints, and we used to need to cast to "unsigned long" first.

It definitely warns about converting an u64 to pointer or back, and it warns on 64-bit machines about this conversion.

On a related note, I wonder why the driver actually converts a pointer to int. I believe we have discussed this in the past but don't remember the outcome. I had expected to see here something like:

static int mhu_send_data(struct mbox_chan *chan, void *data)

{
	struct mhu_link *mlink = chan->con_priv;
	u32 *arg = data;

	writel_relaxed(*arg, mlink->tx_reg + INTR_SET_OFS);
}

i.e. dereferencing the pointer instead of using the actual value.

Arnd

Jassi Brar

2015-02-04 03:27 UTC #7 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 25 lines · Arnd Bergmann

Quoted 18 lines · On Tuesday 03 February 2015 14:46:11 Russell King - ARM Linux wrote:
Quoted 17 lines · Jassi Brar
Quoted 15 lines · Russell King - ARM Linux
drivers/mailbox/arm_mhu.c line 83
Quoted 11 lines · Vincent Yang
drivers/mailbox/arm_mhu.c new file +11 -0
+static int mhu_send_data(struct mbox_chan *chan, void *data)
+{
+     struct mhu_link *mlink = chan->con_priv;
+
+     pr_debug("%s:%d\n", __func__, __LINE__);
+     if (!mhu_last_tx_done(chan)) {
+             dev_err(chan->mbox->dev, "Last TX(%d) pending!\n", mlink->irq);
+             return -EBUSY;
+     }
+
+     writel_relaxed((u32)data, mlink->tx_reg + INTR_SET_OFS);
Doesn't that cause a GCC warning?
Quoted 5 lines
Quoted 1 line
I don't see any, but I'll drop the cast.
A cast is probably needed. You're right that GCC no longer warns about this - I'm pretty sure it used to complain about casting pointers to ints, and we used to need to cast to "unsigned long" first.

Quoted 6 lines

It definitely warns about converting an u64 to pointer or back, and it warns on 64-bit machines about this conversion.
On a related note, I wonder why the driver actually converts a pointer to int. I believe we have discussed this in the past but don't remember the outcome.

We never discussed this (MHU) driver. It was the generic mailbox API where, IIRC, I did take into account all your comments. The API does do what you had asked.

Quoted 12 lines

I had expected to see here something like:
static int mhu_send_data(struct mbox_chan *chan, void *data)
{
        struct mhu_link *mlink = chan->con_priv;
        u32 *arg = data;

        writel_relaxed(*arg, mlink->tx_reg + INTR_SET_OFS);
}
i.e. dereferencing the pointer instead of using the actual value.

OK, just curious how is this (dereferencing to the u32 variable on stack of the client driver) better?

Thanks.

Arnd Bergmann

maintainer

2015-02-04 10:29 UTC #8 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 11 lines · On Wednesday 04 February 2015 08:57:43 Jassi Brar wrote:

Quoted 10 lines · Arnd Bergmann
Quoted 1 line · On Tuesday 03 February 2015 14:46:11 Russell King - ARM Linux wrote:
On Tue, Feb 03, 2015 at 08:09:34PM +0530, Jassi Brar wrote:
I had expected to see here something like:
static int mhu_send_data(struct mbox_chan *chan, void *data)
{
        struct mhu_link *mlink = chan->con_priv;
        u32 *arg = data;

Quoted 7 lines

Quoted 5 lines
        writel_relaxed(*arg, mlink->tx_reg + INTR_SET_OFS);
}
i.e. dereferencing the pointer instead of using the actual value.
OK, just curious how is this (dereferencing to the u32 variable on stack of the client driver) better?

The API as I understand is defined to use the pointer to point to a chunk of data of fixed size, with the size being known to both the client driver and the mailbox driver. This is the reason for having a pointer in the first place.

Using the bits of the pointer as the message instead of pointing to the message feels like an abuse of the API.

Maybe it would have been better to pass the size explictly as a third argument in the API to make that clear.

Arnd

Jassi Brar

2015-02-04 14:34 UTC #9 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 17 lines · Arnd Bergmann

Quoted 16 lines · On Wednesday 04 February 2015 08:57:43 Jassi Brar wrote:
Quoted 15 lines · Arnd Bergmann
Quoted 1 line · On Tuesday 03 February 2015 14:46:11 Russell King - ARM Linux wrote:
On Tue, Feb 03, 2015 at 08:09:34PM +0530, Jassi Brar wrote:
I had expected to see here something like:
static int mhu_send_data(struct mbox_chan *chan, void *data)
{
        struct mhu_link *mlink = chan->con_priv;
        u32 *arg = data;

        writel_relaxed(*arg, mlink->tx_reg + INTR_SET_OFS);
}
i.e. dereferencing the pointer instead of using the actual value.

Quoted 8 lines

Quoted 2 lines
OK, just curious how is this (dereferencing to the u32 variable on stack of the client driver) better?
The API as I understand is defined to use the pointer to point to a chunk of data of fixed size, with the size being known to both the client driver and the mailbox driver. This is the reason for having a pointer in the first place.

Yes, we are on the same page. I just have a slightly more liberal view about the usage of 'void* data'.

Quoted 3 lines

Using the bits of the pointer as the message instead of pointing to the message feels like an abuse of the API.

I can see your POV.
Now consider a client, like mine, that sends a u32 value as the data. But unlike me, the client uses the mailbox api in 'async' mode i.e, register a callback function, submit a 32bit message and move on. It is perfectly doable, but doesn't kalloc'ing a u32 for each submission, seem overkill? Lets say what the client and controller drivers do in their bedroom is none of the API's business.

Quoted 3 lines

Maybe it would have been better to pass the size explictly as a third argument in the API to make that clear.

Actually that did come up for consideration. But since the structure of 'data' packet is already known to the controller driver, having to also tell the size of that structure seems redundant.

Thanks.

Arnd Bergmann

maintainer

2015-02-04 14:48 UTC #10 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 10 lines · On Wednesday 04 February 2015 20:04:21 Jassi Brar wrote:

Quoted 4 lines
Using the bits of the pointer as the message instead of pointing to the message feels like an abuse of the API.
I can see your POV.
Now consider a client, like mine, that sends a u32 value as the data. But unlike me, the client uses the mailbox api in 'async' mode i.e, register a callback function, submit a 32bit message and move on. It is perfectly doable, but doesn't kalloc'ing a u32 for each submission, seem overkill?

That could easily be done by dereferencing the message data in the function that queues the asynchronous message: instead of queuing the pointer, you queue the data in the driver.

Arnd

Jassi Brar

2015-02-04 15:33 UTC #11 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 12 lines · Arnd Bergmann

Quoted 10 lines · On Wednesday 04 February 2015 20:04:21 Jassi Brar wrote:
Quoted 4 lines
Using the bits of the pointer as the message instead of pointing to the message feels like an abuse of the API.
I can see your POV.
Now consider a client, like mine, that sends a u32 value as the data. But unlike me, the client uses the mailbox api in 'async' mode i.e, register a callback function, submit a 32bit message and move on. It is perfectly doable, but doesn't kalloc'ing a u32 for each submission, seem overkill?

Quoted 4 lines

That could easily be done by dereferencing the message data in the function that queues the asynchronous message: instead of queuing the pointer, you queue the data in the driver.

The 'void *data' is not queued in the driver, but in the API code. Or do I not get your point?

Thanks.

Arnd Bergmann

maintainer

2015-02-04 16:42 UTC #12 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 13 lines · On Wednesday 04 February 2015 21:03:50 Jassi Brar wrote:

Quoted 12 lines · Arnd Bergmann
Quoted 10 lines · On Wednesday 04 February 2015 20:04:21 Jassi Brar wrote:
Quoted 4 lines
Using the bits of the pointer as the message instead of pointing to the message feels like an abuse of the API.
I can see your POV.
Now consider a client, like mine, that sends a u32 value as the data. But unlike me, the client uses the mailbox api in 'async' mode i.e, register a callback function, submit a 32bit message and move on. It is perfectly doable, but doesn't kalloc'ing a u32 for each submission, seem overkill?

Quoted 6 lines

Quoted 4 lines
That could easily be done by dereferencing the message data in the function that queues the asynchronous message: instead of queuing the pointer, you queue the data in the driver.
The 'void *data' is not queued in the driver, but in the API code. Or do I not get your point?

My mistake. If the API keeps that pointer after returning to the caller here, this is indeed a problem for callers that have the message on the stack.

The solution of storing the message in a circular buffer (in the API) would in turn require knowing the length of the data.

Another option would be to require that the asynchronous version of the interface cannot be used with on-stack data and requires the object lifetime to be managed by the caller, which seems reasonable to me since you already need the completion callback.

Arnd

Jassi Brar

2015-02-05 05:08 UTC #13 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 25 lines · Arnd Bergmann

Quoted 13 lines · On Wednesday 04 February 2015 21:03:50 Jassi Brar wrote:
Quoted 12 lines · Arnd Bergmann
Quoted 10 lines · On Wednesday 04 February 2015 20:04:21 Jassi Brar wrote:
Quoted 4 lines
Using the bits of the pointer as the message instead of pointing to the message feels like an abuse of the API.
I can see your POV.
Now consider a client, like mine, that sends a u32 value as the data. But unlike me, the client uses the mailbox api in 'async' mode i.e, register a callback function, submit a 32bit message and move on. It is perfectly doable, but doesn't kalloc'ing a u32 for each submission, seem overkill?
Quoted 6 lines
Quoted 4 lines
That could easily be done by dereferencing the message data in the function that queues the asynchronous message: instead of queuing the pointer, you queue the data in the driver.
The 'void *data' is not queued in the driver, but in the API code. Or do I not get your point?
My mistake. If the API keeps that pointer after returning to the caller here, this is indeed a problem for callers that have the message on the stack.

Quoted 8 lines

The solution of storing the message in a circular buffer (in the API) would in turn require knowing the length of the data.
Another option would be to require that the asynchronous version of the interface cannot be used with on-stack data and requires the object lifetime to be managed by the caller, which seems reasonable to me since you already need the completion callback.

Passing pointer to a structure on stack will be automatically punished as a random crash/behavior.
We just need to make sure no client passes a value directly in 'void *data', right?

I know typedef's are frowned upon, but how bad is the following option?
typedef void* mbox_data_info
int mbox_send_message(struct mbox_chan *chan, mbox_data_info data);

Thanks
Jassi

Arnd Bergmann

maintainer

2015-02-05 11:43 UTC #14 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 4 lines · On Thursday 05 February 2015 10:38:16 Jassi Brar wrote:

Passing pointer to a structure on stack will be automatically punished as a random crash/behavior.
We just need to make sure no client passes a value directly in 'void *data', right?

Yes.

Quoted 4 lines

I know typedef's are frowned upon, but how bad is the following option?
typedef void* mbox_data_info
int mbox_send_message(struct mbox_chan *chan, mbox_data_info data);

I don't see how that would help. I believe typedefs for pointer types are particularly bad because they hide what is going on. If we want to enforce the use of pointers to point to data, having the pointer in the function prototype should be enough as a hint to driver developers ;-)

Arnd

Jassi Brar

2015-02-05 12:02 UTC #15 lore raw

Re: [PATCH v5 2/7] mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 5 lines · Arnd Bergmann

Quoted 5 lines
I know typedef's are frowned upon, but how bad is the following option?
typedef void* mbox_data_info
int mbox_send_message(struct mbox_chan *chan, mbox_data_info

data);

Quoted 3 lines

I don't see how that would help.

If it's abuse because the argument is a void*... What if we called it mbox_data_info? To say platforms are free to pass data as a pointer or a value :)

Jassi

Russell King - ARM Linux

2015-02-05 12:08 UTC #16 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 6 lines · Jassi Brar

Quoted 5 lines · Arnd Bergmann
Quoted 5 lines
I know typedef's are frowned upon, but how bad is the following option?
typedef void* mbox_data_info
int mbox_send_message(struct mbox_chan *chan, mbox_data_info

Quoted 7 lines

data);
Quoted 3 lines
I don't see how that would help.
If it's abuse because the argument is a void*... What if we called it mbox_data_info? To say platforms are free to pass data as a pointer or a value :)

Using a typedef really doesn't change anything. If you read the kernel coding style, you'll realise that typedefs are a reason to reject patches - especially to use them in the way you are proposing.

Try the solution I suggested (which I notice was seemingly totally ignored.)

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Arnd Bergmann

maintainer

2015-02-05 12:31 UTC #17 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 7 lines · On Thursday 05 February 2015 12:08:29 Russell King - ARM Linux wrote:

Quoted 6 lines · Jassi Brar
Quoted 5 lines · Arnd Bergmann
Quoted 5 lines
I know typedef's are frowned upon, but how bad is the following option?
typedef void* mbox_data_info
int mbox_send_message(struct mbox_chan *chan, mbox_data_info

Quoted 7 lines

Quoted 7 lines
data);
Quoted 3 lines
I don't see how that would help.
If it's abuse because the argument is a void*... What if we called it mbox_data_info? To say platforms are free to pass data as a pointer or a value

I misunderstood then, I thought you were trying to enforce that people use a proper pointer.

Quoted 3 lines

Using a typedef really doesn't change anything. If you read the kernel coding style, you'll realise that typedefs are a reason to reject patches - especially to use them in the way you are proposing.

Agreed, using a typedef here would add an extra problem rather than solve the one we already have.

Quoted 2 lines

Try the solution I suggested (which I notice was seemingly totally ignored.)

As I understood, Jassi doesn't even have this problem, because his driver uses a synchronous call rather than an asynchronous one and he can just pass the data on the stack.

Arnd

Jassi Brar

2015-02-05 14:50 UTC #18 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

Quoted 11 lines · Russell King - ARM Linux

Quoted 10 lines · Jassi Brar
Quoted 5 lines · Arnd Bergmann
Quoted 5 lines
I know typedef's are frowned upon, but how bad is the following option?
typedef void* mbox_data_info
int mbox_send_message(struct mbox_chan *chan, mbox_data_info
data);
Quoted 3 lines
I don't see how that would help.

Quoted 8 lines

Quoted 3 lines
If it's abuse because the argument is a void*... What if we called it mbox_data_info? To say platforms are free to pass data as a pointer or a value :)
Using a typedef really doesn't change anything. If you read the kernel coding style, you'll realise that typedefs are a reason to reject patches - especially to use them in the way you are proposing.

I started with "I know typedef's are frowned upon". But thanks for reminding me.

Instead of a void*, we could say a client passes data to the controller via an argument that is sizeof(void *) big, so we facilitate both usages. Anyways, I get the message that that is not acceptable.

Quoted 3 lines

Try the solution I suggested (which I notice was seemingly totally ignored.)

My client drivers work in blocking mode, so I don't suffer. For the platform that passes u32 in async mode, we'll let it manage its own circular buffer scheme as you suggested.

Thanks.

Russell King - ARM Linux

2015-02-04 15:09 UTC #19 lore raw

PATCH v5 2/7 mailbox: arm_mhu: add driver for ARM MHU controller

In reply to Arnd Bergmann

Quoted 20 lines · Arnd Bergmann

Quoted 11 lines · On Wednesday 04 February 2015 08:57:43 Jassi Brar wrote:
Quoted 10 lines · Arnd Bergmann
Quoted 1 line · On Tuesday 03 February 2015 14:46:11 Russell King - ARM Linux wrote:
On Tue, Feb 03, 2015 at 08:09:34PM +0530, Jassi Brar wrote:
I had expected to see here something like:
static int mhu_send_data(struct mbox_chan *chan, void *data)
{
        struct mhu_link *mlink = chan->con_priv;
        u32 *arg = data;
Quoted 7 lines
Quoted 5 lines
        writel_relaxed(*arg, mlink->tx_reg + INTR_SET_OFS);
}
i.e. dereferencing the pointer instead of using the actual value.
OK, just curious how is this (dereferencing to the u32 variable on stack of the client driver) better?

Quoted 7 lines

The API as I understand is defined to use the pointer to point to a chunk of data of fixed size, with the size being known to both the client driver and the mailbox driver. This is the reason for having a pointer in the first place.
Using the bits of the pointer as the message instead of pointing to the message feels like an abuse of the API.

I agree on those two points. However, passing the address of something on the stack to mbox_send_message() is also not particularly on - it may save the pointer to use later on if its operating on non-blocking mode.

A possible alternative would be if the user of mbox_send_message() stored the message in an array, operated as a circular buffer, and passed the address of the word to send. That would avoid the need to repeatedly allocate and free memory (which would be expensive for the sake of a u32.)

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Vincent Yang

author

2015-02-03 09:30 UTC #20 lore raw

PATCH v5 3/7 ARM: MB86S7X: Add MCPM support

From: Jassi Brar <[email protected]>

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Andy Green <[email protected]>

Reviewed-by Nicolas Pitre <[email protected]>

---
 arch/arm/mach-mb86s7x/Makefile |   4 +-
 arch/arm/mach-mb86s7x/mcpm.c   | 318 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mb86s7x/smc.S    |  27 ++++
 drivers/soc/mb86s7x/scb_mhu.c  |  14 ++
 include/soc/mb86s7x/scb_mhu.h  |   8 ++
 5 files changed, 370 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
 create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +3 -1

index 97640b6..00e843c 100644
@@ -1 +1,3 @@
-obj-$(CONFIG_ARCH_MB86S7X)	+= board.o
+obj-$(CONFIG_ARCH_MB86S7X)	+= board.o mcpm.o smc.o
+CFLAGS_smc.o			+= -march=armv7-a
+CFLAGS_mcpm.o			+= -march=armv7-a

arch/arm/mach-mb86s7x/mcpm.c new file +318 -0

318 lines not on this page · raw message

arch/arm/mach-mb86s7x/smc.S new file +27 -0

new file mode 100644
index 0000000..3ffe4f7
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2015 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+.arch_extension sec
+
+/* void mb86s7x_cpu_entry(unsigned long secondary_entry); */
+ENTRY(mb86s7x_cpu_entry)
+	stmfd   sp!, {r1-r11, lr}
+	mov r1, r0
+	ldr r0, =1
+	mrc p15, 0, r3, c1, c0, 0
+	mov r4, r3
+	and r3, #0xbfffffff
+	mcr p15, 0, r3, c1, c0, 0
+	smc #0
+	mcr p15, 0, r4, c1, c0, 0
+	ldmfd   sp!, {r1-r11, pc}
+ENDPROC(mb86s7x_cpu_entry)

drivers/soc/mb86s7x/scb_mhu.c +14 -0

index 2fe59c2..b5dd603 100644
@@ -89,6 +89,20 @@ static struct mhu_xfer {
 	struct list_head node;
 } *ax; /* stages of xfer */
 
+#define WFI_COLOR_OFFSET	0x3f00
+
+void mb86s7x_set_wficolor(unsigned clstr, unsigned cpu, unsigned clr)
+{
+	u8 val;
+
+	val = readb_relaxed(mb86s7x_shm_base
+			    + WFI_COLOR_OFFSET + clstr * 2 + cpu);
+	val &= ~AT_WFI_COLOR_MASK;
+	val |= clr;
+	writeb_relaxed(val, mb86s7x_shm_base
+		       + WFI_COLOR_OFFSET + clstr * 2 + cpu);
+}
+
 static int mhu_alloc_xfers(int n, struct list_head *list)
 {
 	struct mhu_xfer *x = kcalloc(n, sizeof(struct mhu_xfer), GFP_ATOMIC);

include/soc/mb86s7x/scb_mhu.h +8 -0

index 334fa9f..f792950 100644
@@ -87,6 +87,14 @@ enum {
 #define CMD_POWERDOMAIN_SET_REP		ENC_REP(CMD_POWERDOMAIN_SET_REQ)
 #define CMD_STG_BLOCK_ERASE_REP		ENC_REP(CMD_STG_BLOCK_ERASE_REQ)
 
+#define AT_WFI_DO_NOTHING	0x0
+#define AT_WFI_DO_SUSPEND	0x1
+#define AT_WFI_DO_POWEROFF	0x2
+#define AT_WFI_COLOR_MASK	0x3
+
+void mb86s7x_set_wficolor(unsigned clstr, unsigned cpu, unsigned clr);
+void mb86s7x_cpu_entry(unsigned long secondary_entry);
+
 /* Helper functions to talk to remote */
 int mb86s7x_send_packet(int cmd, void *buf, int len);

Signature · 1 line

1.9.0

Vincent Yang

author

2015-02-03 09:31 UTC #21 lore raw

PATCH v5 4/7 clk: Add clock driver for mb86s7x

From: Jassi Brar <[email protected]>

The CRG11 clock controller is managed by remote f/w.
This driver simply maps Linux CLK ops onto mailbox api.

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Andy Green <[email protected]>

---
 .../bindings/clock/fujitsu,mb86s70-crg11.txt       |  26 ++
 drivers/clk/Makefile                               |   1 +
 drivers/clk/clk-mb86s7x.c                          | 386 +++++++++++++++++++++
 3 files changed, 413 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt
 create mode 100644 drivers/clk/clk-mb86s7x.c

Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt new file +26 -0

new file mode 100644
index 0000000..3323962
@@ -0,0 +1,26 @@
+Fujitsu CRG11 clock driver bindings
+-----------------------------------
+
+Required properties :
+- compatible : Shall contain "fujitsu,mb86s70-crg11"
+- #clock-cells : Shall be 3 {cntrlr domain port}
+
+The consumer specifies the desired clock pointing to its phandle.
+
+Example:
+
+	clock: crg11 {
+		compatible = "fujitsu,mb86s70-crg11";
+		#clock-cells = <3>;
+	};
+
+	mhu: mhu0 at 2b1f0000 {
+		#mbox-cells = <1>;
+		compatible = "arm,mhu";
+		reg = <0 0x2B1F0000 0x1000>;
+		interrupts = <0 36 4>, /* LP Non-Sec */
+			     <0 35 4>, /* HP Non-Sec */
+			     <0 37 4>; /* Secure */
+		clocks = <&clock 0 2 1>; /* Cntrlr:0 Domain:2 Port:1 */
+		clock-names = "clk";
+	};

drivers/clk/Makefile +1 -0

index d5fba5b..19d73a1 100644
@@ -26,6 +26,7 @@ obj-$(CONFIG_MACH_LOONGSON1)		+= clk-ls1x.o
 obj-$(CONFIG_COMMON_CLK_MAX_GEN)	+= clk-max-gen.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)	+= clk-max77686.o
 obj-$(CONFIG_COMMON_CLK_MAX77802)	+= clk-max77802.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

drivers/clk/clk-mb86s7x.c new file +386 -0

386 lines not on this page · raw message

Signature · 1 line

1.9.0

Vincent Yang

author

2015-02-03 09:32 UTC #22 lore raw

PATCH v5 5/7 dt: mb86s7x: add dt files for MB86S7x evbs

From: Jassi Brar <[email protected]>

Add dt files for MB86S7x evb.

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Andy Green <[email protected]>

---
 arch/arm/boot/dts/Makefile      |   1 +
 arch/arm/boot/dts/mb86s70.dtsi  |  91 +++++++++++++++++++++++++
 arch/arm/boot/dts/mb86s70eb.dts |  57 ++++++++++++++++
 arch/arm/boot/dts/mb86s73.dtsi  |  63 ++++++++++++++++++
 arch/arm/boot/dts/mb86s73eb.dts |  44 +++++++++++++
 arch/arm/boot/dts/mb86s7x.dtsi  | 142 ++++++++++++++++++++++++++++++++++++++++
 6 files changed, 398 insertions(+)
 create mode 100644 arch/arm/boot/dts/mb86s70.dtsi
 create mode 100644 arch/arm/boot/dts/mb86s70eb.dts
 create mode 100644 arch/arm/boot/dts/mb86s73.dtsi
 create mode 100644 arch/arm/boot/dts/mb86s73eb.dts
 create mode 100644 arch/arm/boot/dts/mb86s7x.dtsi

arch/arm/boot/dts/Makefile +1 -0

index 91bd5bd..43b091b 100644
@@ -176,6 +176,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += kirkwood-b3.dtb \
 	kirkwood-ts419-6282.dtb
 dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
 dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
+dtb-$(CONFIG_ARCH_MB86S7X) += mb86s70eb.dtb mb86s73eb.dtb
 dtb-$(CONFIG_MACH_MESON6) += meson6-atv1200.dtb
 dtb-$(CONFIG_ARCH_MMP) += pxa168-aspenite.dtb \
 	pxa910-dkb.dtb \

arch/arm/boot/dts/mb86s70.dtsi new file +91 -0

91 lines not on this page · raw message

arch/arm/boot/dts/mb86s70eb.dts new file +57 -0

57 lines not on this page · raw message

arch/arm/boot/dts/mb86s73.dtsi new file +63 -0

63 lines not on this page · raw message

arch/arm/boot/dts/mb86s73eb.dts new file +44 -0

44 lines not on this page · raw message

arch/arm/boot/dts/mb86s7x.dtsi new file +142 -0

142 lines not on this page · raw message

Signature · 1 line

1.9.0

Vincent Yang

author

2015-02-03 09:34 UTC #23 lore raw

PATCH v5 6/7 of: add Fujitsu vendor prefix

From: Jassi Brar <[email protected]>

Add 'fujitsu' as the vendor prefix for Fujitsu Semiconductor Ltd.

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Andy Green <[email protected]>

Acked-by Rob Herring <[email protected]>

---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

Documentation/devicetree/bindings/vendor-prefixes.txt +1 -0

index d443279..e0ac020 100644
@@ -59,6 +59,7 @@ everest	Everest Semiconductor Co. Ltd.
 excito	Excito
 fcs	Fairchild Semiconductor
 fsl	Freescale Semiconductor
+fujitsu Fujitsu Semiconductor Ltd.
 GEFanuc	GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gef	GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 geniatech	Geniatech, Inc.

Signature · 1 line

1.9.0

Vincent Yang

author

2015-02-03 09:35 UTC #24 lore raw

PATCH v5 7/7 ARM: MB86S7x: Add configs

From: Jassi Brar <[email protected]>

Fujitsu's ARCH_MB86S7X is multi_v7 compatible, so add options to multi_v7_defconfig. Also add a new defconfig for MB86S7X for those who want the kernel built specifically for ARCH_MB86S7X.

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Andy Green <[email protected]>