This adds a prefix for MStar and thingy.jp and then defines compatible
strings for the first MStar based board.
Signed-off-by: Daniel Palmer <[email protected]>
---
.../devicetree/bindings/arm/mstar.yaml | 22 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 4 ++++
MAINTAINERS | 6 +++++
3 files changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
diff --git a/Documentation/devicetree/bindings/arm/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar.yaml
new file mode 100644
index 000000000000..0ea5b2b9387f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mstar.yaml
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mstar.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar platforms device tree bindings
+
+maintainers:
+ - Daniel Palmer <[email protected]>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+
+ - description: thingy.jp BreadBee
+ items:
+ - const: thingyjp,breadbee
+ - const: mstar,infinity
+ - const: mstar,infinity3
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 967e78c5ec0a..1425468188da 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -617,6 +617,8 @@ patternProperties:
description: Microsemi Corporation
"^msi,.*":
description: Micro-Star International Co. Ltd.
+ "^mstar,.*":
+ description: MStar Semiconductor, Inc.
"^mti,.*":
description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
"^multi-inno,.*":
@@ -943,6 +945,8 @@ patternProperties:
description: Three Five Corp
"^thine,.*":
description: THine Electronics, Inc.
+ "^thingyjp,.*":
+ description: thingy.jp
"^ti,.*":
description: Texas Instruments
"^tianma,.*":
diff --git a/MAINTAINERS b/MAINTAINERS
index a69e6db80c79..8b7913c13f9a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1981,6 +1981,12 @@ L: [email protected] (moderated for non-subscribers)
F: arch/arm/mach-pxa/mioa701.c
S: Maintained
+ARM/MStar SoC support
+M: Daniel Palmer <[email protected]>
+L: [email protected] (moderated for non-subscribers)
+F: Documentation/devicetree/bindings/arm/mstar.yaml
+S: Maintained
+
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
M: Michael Petchkovsky <[email protected]>
S: Maintained
--
2.23.0
Initial support for the MStar infinity/infinity3 series of Cortex A7
based IP camera SoCs.
These chips are interesting in that they contain a Cortex A7,
peripherals and system memory in a single tiny QFN package that
can be hand soldered allowing almost anyone to embed Linux
in their projects.
Signed-off-by: Daniel Palmer <[email protected]>
---
MAINTAINERS | 1 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-mstar/Kconfig | 15 ++++++
arch/arm/mach-mstar/Makefile | 1 +
arch/arm/mach-mstar/infinity.c | 96 ++++++++++++++++++++++++++++++++++
6 files changed, 116 insertions(+)
create mode 100644 arch/arm/mach-mstar/Kconfig
create mode 100644 arch/arm/mach-mstar/Makefile
create mode 100644 arch/arm/mach-mstar/infinity.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 8b7913c13f9a..e35c3eb2b680 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1985,6 +1985,7 @@ ARM/MStar SoC support
M: Daniel Palmer <[email protected]>
L: [email protected] (moderated for non-subscribers)
F: Documentation/devicetree/bindings/arm/mstar.yaml
+F: arch/arm/mach-mstar/
S: Maintained
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8a50efb559f3..b8450ed8d946 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -667,6 +667,8 @@ source "arch/arm/mach-mmp/Kconfig"
source "arch/arm/mach-moxart/Kconfig"
+source "arch/arm/mach-mstar/Kconfig"
+
source "arch/arm/mach-mv78xx0/Kconfig"
source "arch/arm/mach-mvebu/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index db857d07114f..2a3c127cd243 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -196,6 +196,7 @@ machine-$(CONFIG_ARCH_MXC) += imx
machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
machine-$(CONFIG_ARCH_MILBEAUT) += milbeaut
machine-$(CONFIG_ARCH_MXS) += mxs
+machine-$(CONFIG_ARCH_MSTAR) += mstar
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
machine-$(CONFIG_ARCH_NPCM) += npcm
machine-$(CONFIG_ARCH_NSPIRE) += nspire
diff --git a/arch/arm/mach-mstar/Kconfig b/arch/arm/mach-mstar/Kconfig
new file mode 100644
index 000000000000..7bc79c296ebb
--- /dev/null
+++ b/arch/arm/mach-mstar/Kconfig
@@ -0,0 +1,15 @@
+menuconfig ARCH_MSTAR
+ bool "MStar SoC Support"
+ depends on ARCH_MULTI_V7
+ select ARM_GIC
+ help
+ Support for MStar ARMv7 SoCs
+
+if ARCH_MSTAR
+
+config MACH_INFINITY
+ bool "MStar infinity SoC support"
+ default ARCH_INFINITY
+ help
+ Support for MStar infinity(1/3) IP camera SoCs
+endif
diff --git a/arch/arm/mach-mstar/Makefile b/arch/arm/mach-mstar/Makefile
new file mode 100644
index 000000000000..144b58b189e3
--- /dev/null
+++ b/arch/arm/mach-mstar/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MACH_INFINITY) += infinity.o
diff --git a/arch/arm/mach-mstar/infinity.c b/arch/arm/mach-mstar/infinity.c
new file mode 100644
index 000000000000..520581660bef
--- /dev/null
+++ b/arch/arm/mach-mstar/infinity.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree support for MStar Infinity SoCs
+ *
+ * Copyright (c) 2019 thingy.jp
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include <linux/init.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <linux/of.h>
+#include <linux/io.h>
+
+/*
+ * The IO space is remapped to the same place
+ * the vendor kernel does so that the hardcoded
+ * addresses all over the vendor drivers line up.
+ */
+
+#define INFINITY_IO_PHYS 0x1f000000
+#define INFINITY_IO_OFFSET 0xde000000
+#define INFINITY_IO_VIRT (INFINITY_IO_PHYS + INFINITY_IO_OFFSET)
+#define INFINITY_IO_SIZE 0x00400000
+
+/*
+ * In the u-boot code the area these registers are in is
+ * called "L3 bridge".
+ *
+ * It's not exactly known what is the L3 bridge is but
+ * the vendor code for both u-boot and linux share calls
+ * to "flush the miu pipe". This seems to be to force pending
+ * CPU writes to memory so that the state is right before
+ * DMA capable devices try to read descriptors and data
+ * the CPU has prepared. Without doing this ethernet doesn't
+ * work reliably for example.
+ */
+
+#define INFINITY_L3BRIDGE_FLUSH 0x204414
+#define INFINITY_L3BRIDGE_STATUS 0x204440
+#define INFINITY_L3BRIDGE_FLUSH_TRIGGER BIT(0)
+#define INFINITY_L3BRIDGE_STATUS_DONE BIT(12)
+
+static void __iomem *miu_status;
+static void __iomem *miu_flush;
+
+static struct map_desc infinity_io_desc[] __initdata = {
+ {INFINITY_IO_VIRT, __phys_to_pfn(INFINITY_IO_PHYS),
+ INFINITY_IO_SIZE, MT_DEVICE},
+};
+
+static void __init infinity_map_io(void)
+{
+ iotable_init(infinity_io_desc, ARRAY_SIZE(infinity_io_desc));
+ miu_flush = (void __iomem *)(infinity_io_desc[0].virtual
+ + INFINITY_L3BRIDGE_FLUSH);
+ miu_status = (void __iomem *)(infinity_io_desc[0].virtual
+ + INFINITY_L3BRIDGE_STATUS);
+}
+
+static const char * const infinity_board_dt_compat[] = {
+ "mstar,infinity",
+ NULL,
+};
+
+static DEFINE_SPINLOCK(infinity_mb_lock);
+
+static void infinity_mb(void)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&infinity_mb_lock, flags);
+ /* toggle the flush miu pipe fire bit */
+ writel_relaxed(0, miu_flush);
+ writel_relaxed(INFINITY_L3BRIDGE_FLUSH_TRIGGER, miu_flush);
+ while (!(readl_relaxed(miu_status) & INFINITY_L3BRIDGE_STATUS_DONE)) {
+ /* wait for flush to complete */
+ }
+ spin_unlock_irqrestore(&infinity_mb_lock, flags);
+}
+
+static void __init infinity_barriers_init(void)
+{
+ soc_mb = infinity_mb;
+}
+
+static void __init infinity_init(void)
+{
+ infinity_barriers_init();
+}
+
+DT_MACHINE_START(INFINITY_DT, "MStar Infinity (Device Tree)")
+ .dt_compat = infinity_board_dt_compat,
+ .init_machine = infinity_init,
+ .map_io = infinity_map_io,
+MACHINE_END
--
2.23.0
BreadBee is an opensource development board based on the
MStar msc313e SoC.
Hardware details, schematics and so on can be found at:
https://github.com/breadbee/breadbee
Signed-off-by: Daniel Palmer <[email protected]>
---
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/infinity3-msc313e-breadbee.dts | 26 +++++++++++++++++++
2 files changed, 27 insertions(+)
create mode 100644 arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bf0aa53d3a13..e546dfafef55 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1276,6 +1276,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8127-moose.dtb \
mt8135-evbp1.dtb
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
+dtb-$(CONFIG_ARCH_MSTAR) += infinity3-msc313e-breadbee.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
new file mode 100644
index 000000000000..cf185878c412
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+/dts-v1/;
+#include "infinity3-msc313e.dtsi"
+
+/ {
+ model = "thingy.jp breadbee";
+ compatible = "thingyjp,breadbee", "mstar,infinity3", "mstar,infinity";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ console = &pm_uart;
+ };
+};
+
+&pm_uart {
+ status = "okay";
+};
--
2.23.0
On Mon, Oct 14, 2019 at 8:21 AM Daniel Palmer <[email protected]> wrote:
>
> Initial support for the MStar infinity/infinity3 series of Cortex A7
> based IP camera SoCs.
>
> These chips are interesting in that they contain a Cortex A7,
> peripherals and system memory in a single tiny QFN package that
> can be hand soldered allowing almost anyone to embed Linux
> in their projects.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> +
> +static void __init infinity_map_io(void)
> +{
> + iotable_init(infinity_io_desc, ARRAY_SIZE(infinity_io_desc));
> + miu_flush = (void __iomem *)(infinity_io_desc[0].virtual
> + + INFINITY_L3BRIDGE_FLUSH);
> + miu_status = (void __iomem *)(infinity_io_desc[0].virtual
> + + INFINITY_L3BRIDGE_STATUS);
> +}
If you do this a little later in .init_machine, you can use a simple ioremap()
rather than picking a hardcoded physical address. It looks like nothing
uses the mapping before you set soc_mb anyway.
> +static DEFINE_SPINLOCK(infinity_mb_lock);
> +
> +static void infinity_mb(void)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&infinity_mb_lock, flags);
> + /* toggle the flush miu pipe fire bit */
> + writel_relaxed(0, miu_flush);
> + writel_relaxed(INFINITY_L3BRIDGE_FLUSH_TRIGGER, miu_flush);
> + while (!(readl_relaxed(miu_status) & INFINITY_L3BRIDGE_STATUS_DONE)) {
> + /* wait for flush to complete */
> + }
> + spin_unlock_irqrestore(&infinity_mb_lock, flags);
> +}
Wow, this is a heavy barrier. From your description it doesn't sound like
there is anything to be done about it unfortunately.
Two possible issues I see here:
* It looks like it relies on CONFIG_ARM_HEAVY_BARRIER, but your Kconfig
entry does not select that. In many configurations, CACHE_L2X0 would
be set, but there is no need for yours on the Cortex-A7.
* You might get into a deadlock if you get an FIQ (NMI) interrupt while
holding the infinity_mb_lock, and then issue another memory barrier
from that handler, so you might need to use
local_irq_disable()+local_fiq_disable()+raw_spin_lock() here, making
it even more expensive.
Not sure if it matters in practice, as almost nothing uses fiq any more.
OTOH, maybe the lock is not needed at all? AFAICT if the sequence
gets interrupted by a handler that also calls mb(), you would still
continue in the original thread while observing a full l3 barrier. ;-)
Arnd
> > +
> > +static void __init infinity_map_io(void)
> > +{
> > + iotable_init(infinity_io_desc, ARRAY_SIZE(infinity_io_desc));
> > + miu_flush = (void __iomem *)(infinity_io_desc[0].virtual
> > + + INFINITY_L3BRIDGE_FLUSH);
> > + miu_status = (void __iomem *)(infinity_io_desc[0].virtual
> > + + INFINITY_L3BRIDGE_STATUS);
> > +}
>
> If you do this a little later in .init_machine, you can use a simple ioremap()
> rather than picking a hardcoded physical address. It looks like nothing
> uses the mapping before you set soc_mb anyway.
I've moved this into infinity_barriers_init() using ioremap() as suggested.
I'd like to keep the fixed remap address for now as there are some
drivers in the vendor code that might be useful until rewrites are done but
are littered with hard coded addresses.
> > +static DEFINE_SPINLOCK(infinity_mb_lock);
> > +
> > +static void infinity_mb(void)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&infinity_mb_lock, flags);
> > + /* toggle the flush miu pipe fire bit */
> > + writel_relaxed(0, miu_flush);
> > + writel_relaxed(INFINITY_L3BRIDGE_FLUSH_TRIGGER, miu_flush);
> > + while (!(readl_relaxed(miu_status) & INFINITY_L3BRIDGE_STATUS_DONE)) {
> > + /* wait for flush to complete */
> > + }
> > + spin_unlock_irqrestore(&infinity_mb_lock, flags);
> > +}
>
> Wow, this is a heavy barrier. From your description it doesn't sound like
> there is anything to be done about it unfortunately.
It's possible there is a better way once I can find out what the L3 bridge
actually is. There is a small amount of documentation for the miu (DDR
controller) that says it has an 8 or 4 operation configurable pipeline but
this flushing bit is in a totally different area that's only documented
by the comment about it in u-boot.
> Two possible issues I see here:
>
> * It looks like it relies on CONFIG_ARM_HEAVY_BARRIER, but your Kconfig
> entry does not select that. In many configurations, CACHE_L2X0 would
> be set, but there is no need for yours on the Cortex-A7.
Fixed.
> Not sure if it matters in practice, as almost nothing uses fiq any more.
> OTOH, maybe the lock is not needed at all? AFAICT if the sequence
> gets interrupted by a handler that also calls mb(), you would still
> continue in the original thread while observing a full l3 barrier. ;-)
I've taken the lock out and tested that the ethernet isn't sending garbage
and everything looks good.
I'm still hoping for some feedback on the other parts of the series.
I'll post a v2 series in a few days.
Thanks!
Daniel
On Wed, Oct 16, 2019 at 10:32 PM Daniel Palmer <[email protected]> wrote:
>
> > > +
> > > +static void __init infinity_map_io(void)
> > > +{
> > > + iotable_init(infinity_io_desc, ARRAY_SIZE(infinity_io_desc));
> > > + miu_flush = (void __iomem *)(infinity_io_desc[0].virtual
> > > + + INFINITY_L3BRIDGE_FLUSH);
> > > + miu_status = (void __iomem *)(infinity_io_desc[0].virtual
> > > + + INFINITY_L3BRIDGE_STATUS);
> > > +}
> >
> > If you do this a little later in .init_machine, you can use a simple ioremap()
> > rather than picking a hardcoded physical address. It looks like nothing
> > uses the mapping before you set soc_mb anyway.
>
> I've moved this into infinity_barriers_init() using ioremap() as suggested.
> I'd like to keep the fixed remap address for now as there are some
> drivers in the vendor code that might be useful until rewrites are done but
> are littered with hard coded addresses.
Maybe keep the infinity_io_desc as an out-of-tree patch then? You can
simply do both, and ioremap() will return the hardcoded address.
> > Not sure if it matters in practice, as almost nothing uses fiq any more.
> > OTOH, maybe the lock is not needed at all? AFAICT if the sequence
> > gets interrupted by a handler that also calls mb(), you would still
> > continue in the original thread while observing a full l3 barrier. ;-)
>
> I've taken the lock out and tested that the ethernet isn't sending garbage
> and everything looks good.
I would not expect a missing spinlock to have an observable effect, the
question is more whether it's correct in all rare corner cases where
the barrier is interrupted and the interrupt handler uses another barrier.
I think it is, but I would recommend adding a comment to explain this if
you drop the spinlock. (or a comment about why this works with fiq if you
keep the lock).
Arnd
On Thu, Oct 17, 2019 at 03:02:22PM +0200, Arnd Bergmann wrote:
> > I've moved this into infinity_barriers_init() using ioremap() as suggested.
> > I'd like to keep the fixed remap address for now as there are some
> > drivers in the vendor code that might be useful until rewrites are done but
> > are littered with hard coded addresses.
>
> Maybe keep the infinity_io_desc as an out-of-tree patch then? You can
> simply do both, and ioremap() will return the hardcoded address.
That makes sense.
> > I've taken the lock out and tested that the ethernet isn't sending garbage
> > and everything looks good.
>
> I would not expect a missing spinlock to have an observable effect, the
> question is more whether it's correct in all rare corner cases where
> the barrier is interrupted and the interrupt handler uses another barrier.
>
> I think it is, but I would recommend adding a comment to explain this if
> you drop the spinlock. (or a comment about why this works with fiq if you
> keep the lock).
I think I'll drop the lock for now and add it back if it becomes apparent
it's needed. I suspect it was added in the vendor code out of habit instead
of need.
Thanks for the input.
Daniel
On Wed, Oct 23, 2019 at 5:44 PM Daniel Palmer <[email protected]> wrote:
>
> On Wed, Oct 23, 2019 at 03:02:28PM -0500, Rob Herring wrote:
> > > +# SPDX-License-Identifier: (GPL-2.0+ OR X11)
> >
> > (GPL-2.0-only OR BSD-2-Clause) is preferred. Any reason to differ?
>
> I used the sunxi file as a template and thought they had some
> reason to do that. I'll change it to just GPL-2.0.
That wasn't a choice, but dual license it please.
> > > + - description: thingy.jp BreadBee
> > > + items:
> > > + - const: thingyjp,breadbee
> > > + - const: mstar,infinity
> > > + - const: mstar,infinity3
> >
> > infinity vs. infinity3? What's the difference? It's generally sufficient
> > to just list a board compatible and a SoC compatible.
>
> Apart from some very slight differences (max clock speed, different PWM block)
> they are the same and the PCB for the BreadBee can take either the msc313(i1) or
> msc313e(i3). My v2 patch will remove the mstar,infinity line from there and move
> it to a second board called the breadbee-crust to handle the i1 configuration.
Sounds like you want:
items:
- const: thingyjp,breadbee
- enum:
- mstar,infinity
- mstar,infinity3
If one board can do both chips. Though if the same PCB is populated
differently beyond the SoC, then maybe 2 board compatibles makes
sense.
Why not use the part numbers (msc313...)?
Rob
On Mon, Oct 14, 2019 at 03:15:56PM +0900, Daniel Palmer wrote:
> This adds a prefix for MStar and thingy.jp and then defines compatible
> strings for the first MStar based board.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> ---
> .../devicetree/bindings/arm/mstar.yaml | 22 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 4 ++++
> MAINTAINERS | 6 +++++
> 3 files changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar.yaml
> new file mode 100644
> index 000000000000..0ea5b2b9387f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mstar.yaml
> @@ -0,0 +1,22 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR X11)
(GPL-2.0-only OR BSD-2-Clause) is preferred. Any reason to differ?
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mstar.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MStar platforms device tree bindings
> +
> +maintainers:
> + - Daniel Palmer <[email protected]>
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> +
Drop the blank line.
> + - description: thingy.jp BreadBee
> + items:
> + - const: thingyjp,breadbee
> + - const: mstar,infinity
> + - const: mstar,infinity3
infinity vs. infinity3? What's the difference? It's generally sufficient
to just list a board compatible and a SoC compatible.
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 967e78c5ec0a..1425468188da 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -617,6 +617,8 @@ patternProperties:
> description: Microsemi Corporation
> "^msi,.*":
> description: Micro-Star International Co. Ltd.
> + "^mstar,.*":
> + description: MStar Semiconductor, Inc.
> "^mti,.*":
> description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
> "^multi-inno,.*":
> @@ -943,6 +945,8 @@ patternProperties:
> description: Three Five Corp
> "^thine,.*":
> description: THine Electronics, Inc.
> + "^thingyjp,.*":
> + description: thingy.jp
> "^ti,.*":
> description: Texas Instruments
> "^tianma,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a69e6db80c79..8b7913c13f9a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1981,6 +1981,12 @@ L: [email protected] (moderated for non-subscribers)
> F: arch/arm/mach-pxa/mioa701.c
> S: Maintained
>
> +ARM/MStar SoC support
> +M: Daniel Palmer <[email protected]>
> +L: [email protected] (moderated for non-subscribers)
> +F: Documentation/devicetree/bindings/arm/mstar.yaml
> +S: Maintained
> +
> ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
> M: Michael Petchkovsky <[email protected]>
> S: Maintained
> --
> 2.23.0
>
On Wed, Oct 23, 2019 at 03:02:28PM -0500, Rob Herring wrote:
> > +# SPDX-License-Identifier: (GPL-2.0+ OR X11)
>
> (GPL-2.0-only OR BSD-2-Clause) is preferred. Any reason to differ?
I used the sunxi file as a template and thought they had some
reason to do that. I'll change it to just GPL-2.0.
> > + - description: thingy.jp BreadBee
> > + items:
> > + - const: thingyjp,breadbee
> > + - const: mstar,infinity
> > + - const: mstar,infinity3
>
> infinity vs. infinity3? What's the difference? It's generally sufficient
> to just list a board compatible and a SoC compatible.
Apart from some very slight differences (max clock speed, different PWM block)
they are the same and the PCB for the BreadBee can take either the msc313(i1) or
msc313e(i3). My v2 patch will remove the mstar,infinity line from there and move
it to a second board called the breadbee-crust to handle the i1 configuration.
Thanks,
Daniel
On Wed, Oct 23, 2019 at 06:45:29PM -0500, Rob Herring wrote:
> > I used the sunxi file as a template and thought they had some
> > reason to do that. I'll change it to just GPL-2.0.
>
> That wasn't a choice, but dual license it please.
Will do.
> Sounds like you want:
>
> items:
> - const: thingyjp,breadbee
> - enum:
> - mstar,infinity
> - mstar,infinity3
>
> If one board can do both chips. Though if the same PCB is populated
> differently beyond the SoC, then maybe 2 board compatibles makes
> sense.
You can take one chip off and swap it with the other without any PCB/component
changes but as I've been working on both chips there are a few differences
coming up that means you can't use the same DT for both configurations.
For example the ethernet phy needs to be configured differently, the i1
SoC has less instances of the DMA controller blocks and so on.
The version of the chip can be detected from a register and I had considered
patching over the differences based on that but I couldn't find an example
of doing it within the kernel. So I'm detecting the chip version in u-boot and
loading the right DT there.
> Why not use the part numbers (msc313...)?
I had initially done that when I thought i1 was the msc31e and i3 was the
msc313e. For the i1 the only part I have found so far is the msc313 but
the i3 is a series of around 4 or 5 different configurations of the same SoC
with differing amounts of DDR and pins. This is like the AllWinner V3S and
S3/S3L where the same V3 SoC is packaged differently. As there is no source
of this information that appears on a google search I've started documenting
it at http://linux-chenxing.org/
I think the only place the actual chip model will need to be used will be a
compatible string for the pinctrl driver to setup the right pin numbers.
Thanks,
Daniel
This patch set adds initial support for MStar/Sigmastar's
ARMv7 based SoCs. There is just enough here to get to a shell
with an initramfs but support for a lot of the hardware is
in progress and will follow.
MStar also shipped chips with MIPS cores and ARM9 etc which
are incompatible so I've tried to make the distinction in the
code that this is strictly for the ARMv7 based chips.
Differences from v1:
1. v1 only really supported two specific chips that were known
at the time of submitting that patch series. Since then it's
become apparent that there are a few families of SoCs based
on the same ARMv7 core, clk blocks, interrupt controllers etc
and this v2 attempts to make support more generic so in the future
more SoCs from this lineage can be added. Support for some other
chips is already in progress and will follow.
2. v1 only added support for the BreadBee boards that I have been
working on. v2 also adds support for a readily available car dash
camera.
3. Support for the BreadBee board has been split into two top level
dts to cleanly support if either the msc313 or msc313e is mounted on
the board. The chips are pin compatible but some of the internal
hardware is different. The u-boot port for these SoCs can detect
which chip it is running on and select the right dts so the user
doesn't have to care which chip is mounted on their board.
Daniel Palmer (5):
dt-bindings: arm: Initial MStar vendor prefixes and compatible strings
ARM: mstar: Add machine for MStar/Sigmastar infinity/mercury family
ARMv7 SoCs
ARM: mstar: Add infinity/mercury series dtsi
ARM: mstar: Add dts for msc313(e) based BreadBee boards
ARM: mstar: Add dts for 70mai midrive d08
.../devicetree/bindings/arm/mstar.yaml | 30 ++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 6 ++
MAINTAINERS | 10 +++
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 4 ++
.../dts/infinity-msc313-breadbee_crust.dts | 25 +++++++
arch/arm/boot/dts/infinity-msc313.dtsi | 14 ++++
arch/arm/boot/dts/infinity.dtsi | 10 +++
.../boot/dts/infinity3-msc313e-breadbee.dts | 25 +++++++
arch/arm/boot/dts/infinity3-msc313e.dtsi | 14 ++++
arch/arm/boot/dts/infinity3.dtsi | 10 +++
.../boot/dts/mercury5-ssc8336n-midrive08.dts | 25 +++++++
arch/arm/boot/dts/mercury5-ssc8336n.dtsi | 14 ++++
arch/arm/boot/dts/mercury5.dtsi | 10 +++
arch/arm/boot/dts/mstar-v7.dtsi | 71 ++++++++++++++++++
arch/arm/mach-mstar/Kconfig | 26 +++++++
arch/arm/mach-mstar/Makefile | 1 +
arch/arm/mach-mstar/mstarv7.c | 72 +++++++++++++++++++
19 files changed, 370 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
create mode 100644 arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
create mode 100644 arch/arm/boot/dts/infinity-msc313.dtsi
create mode 100644 arch/arm/boot/dts/infinity.dtsi
create mode 100644 arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
create mode 100644 arch/arm/boot/dts/infinity3-msc313e.dtsi
create mode 100644 arch/arm/boot/dts/infinity3.dtsi
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n.dtsi
create mode 100644 arch/arm/boot/dts/mercury5.dtsi
create mode 100644 arch/arm/boot/dts/mstar-v7.dtsi
create mode 100644 arch/arm/mach-mstar/Kconfig
create mode 100644 arch/arm/mach-mstar/Makefile
create mode 100644 arch/arm/mach-mstar/mstarv7.c
--
2.27.0.rc0
Adds a prefixes for MStar, thingy.jp, 70mai and then defines compatible
strings for the first MStar based boards.
Signed-off-by: Daniel Palmer <[email protected]>
---
.../devicetree/bindings/arm/mstar.yaml | 30 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 6 ++++
MAINTAINERS | 6 ++++
3 files changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
diff --git a/Documentation/devicetree/bindings/arm/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar.yaml
new file mode 100644
index 000000000000..09e87cf6d6f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mstar.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mstar.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar platforms device tree bindings
+
+maintainers:
+ - Daniel Palmer <[email protected]>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: thingy.jp BreadBee
+ items:
+ - const: thingyjp,breadbee
+ - const: mstar,infinity3
+
+ - description: thingy.jp BreadBee Crust
+ items:
+ - const: thingyjp,breadbee-crust
+ - const: mstar,infinity
+
+ - description: 70mai midrive d08
+ items:
+ - const: 70mai,midrived08
+ - const: mstar,mercury5
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index ef6d75b9113a..1770fc794027 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -23,6 +23,8 @@ patternProperties:
"^(simple-audio-card|simple-graph-card|st-plgpio|st-spics|ts),.*": true
# Keep list in alphabetical order.
+ "^70mai,.*":
+ description: 70mai
"^abilis,.*":
description: Abilis Systems
"^abracon,.*":
@@ -678,6 +680,8 @@ patternProperties:
description: Microsemi Corporation
"^msi,.*":
description: Micro-Star International Co. Ltd.
+ "^mstar,.*":
+ description: MStar Semiconductor, Inc.
"^mti,.*":
description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
"^multi-inno,.*":
@@ -1030,6 +1034,8 @@ patternProperties:
description: Three Five Corp
"^thine,.*":
description: THine Electronics, Inc.
+ "^thingyjp,.*":
+ description: thingy.jp
"^ti,.*":
description: Texas Instruments
"^tianma,.*":
diff --git a/MAINTAINERS b/MAINTAINERS
index 77a3fa5e3edd..1ca77f97b8ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2110,6 +2110,12 @@ L: [email protected] (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-pxa/mioa701.c
+ARM/MStar/Sigmastar ARMv7 SoC support
+M: Daniel Palmer <[email protected]>
+L: [email protected] (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/mstar.yaml
+
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
M: Michael Petchkovsky <[email protected]>
S: Maintained
--
2.27.0.rc0
Initial support for the MStar/Sigmastar infinity/mercury series of ARMv7
based IP camera and dashcam SoCs.
These chips are interesting in that they contain a Cortex A7,
peripherals and system memory in a single tiny QFN package that
can be hand soldered allowing almost anyone to embed Linux
in their projects.
Signed-off-by: Daniel Palmer <[email protected]>
---
MAINTAINERS | 1 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-mstar/Kconfig | 26 +++++++++++++
arch/arm/mach-mstar/Makefile | 1 +
arch/arm/mach-mstar/mstarv7.c | 72 +++++++++++++++++++++++++++++++++++
6 files changed, 103 insertions(+)
create mode 100644 arch/arm/mach-mstar/Kconfig
create mode 100644 arch/arm/mach-mstar/Makefile
create mode 100644 arch/arm/mach-mstar/mstarv7.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1ca77f97b8ee..754521938303 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2114,6 +2114,7 @@ ARM/MStar/Sigmastar ARMv7 SoC support
M: Daniel Palmer <[email protected]>
L: [email protected] (moderated for non-subscribers)
S: Maintained
+F: arch/arm/mach-mstar/
F: Documentation/devicetree/bindings/arm/mstar.yaml
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fb6c85c5d344..e466694f8486 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -669,6 +669,8 @@ source "arch/arm/mach-mmp/Kconfig"
source "arch/arm/mach-moxart/Kconfig"
+source "arch/arm/mach-mstar/Kconfig"
+
source "arch/arm/mach-mv78xx0/Kconfig"
source "arch/arm/mach-mvebu/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 59fde2d598d8..e7f4ca060c0f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -197,6 +197,7 @@ machine-$(CONFIG_ARCH_MXC) += imx
machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
machine-$(CONFIG_ARCH_MILBEAUT) += milbeaut
machine-$(CONFIG_ARCH_MXS) += mxs
+machine-$(CONFIG_ARCH_MSTARV7) += mstar
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
machine-$(CONFIG_ARCH_NPCM) += npcm
machine-$(CONFIG_ARCH_NSPIRE) += nspire
diff --git a/arch/arm/mach-mstar/Kconfig b/arch/arm/mach-mstar/Kconfig
new file mode 100644
index 000000000000..6235d0a7860a
--- /dev/null
+++ b/arch/arm/mach-mstar/Kconfig
@@ -0,0 +1,26 @@
+menuconfig ARCH_MSTARV7
+ bool "MStar/Sigmastar ARMv7 SoC Support"
+ depends on ARCH_MULTI_V7
+ select ARM_GIC
+ select ARM_HEAVY_MB
+ help
+ Support for newer MStar/Sigmastar SoC families that are
+ based on ARMv7 cores like the Cortex A7 and share the same
+ basic hardware like the infinity and mercury series.
+
+if ARCH_MSTARV7
+
+config MACH_INFINITY
+ bool "MStar/Sigmastar infinity SoC support"
+ default ARCH_MSTARV7
+ help
+ Support for MStar/Sigmastar infinity IP camera SoCs.
+
+config MACH_MERCURY
+ bool "MStar/Sigmastar mercury SoC support"
+ default ARCH_MSTARV7
+ help
+ Support for MStar/Sigmastar mercury dash camera SoCs.
+ Note that older Mercury2 SoCs are ARM9 based and not supported.
+
+endif
diff --git a/arch/arm/mach-mstar/Makefile b/arch/arm/mach-mstar/Makefile
new file mode 100644
index 000000000000..93b0391ede7e
--- /dev/null
+++ b/arch/arm/mach-mstar/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARCH_MSTARV7) += mstarv7.o
diff --git a/arch/arm/mach-mstar/mstarv7.c b/arch/arm/mach-mstar/mstarv7.c
new file mode 100644
index 000000000000..ee96ce46cbbc
--- /dev/null
+++ b/arch/arm/mach-mstar/mstarv7.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree support for MStar/Sigmastar ARMv7 SoCs
+ *
+ * Copyright (c) 2019 thingy.jp
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include <linux/init.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <linux/of.h>
+#include <linux/io.h>
+
+/*
+ * In the u-boot code the area these registers are in is
+ * called "L3 bridge" and there are register descriptions
+ * for something in the same area called "AXI".
+ *
+ * It's not exactly known what this is but the vendor code
+ * for both u-boot and linux share calls to "flush the miu pipe".
+ * This seems to be to force pending CPU writes to memory so that
+ * the state is right before DMA capable devices try to read
+ * descriptors and data the CPU has prepared. Without doing this
+ * ethernet doesn't work reliably for example.
+ */
+
+#define MSTARV7_L3BRIDGE_FLUSH 0x1f204414
+#define MSTARV7_L3BRIDGE_STATUS 0x1f204440
+#define MSTARV7_L3BRIDGE_FLUSH_TRIGGER BIT(0)
+#define MSTARV7_L3BRIDGE_STATUS_DONE BIT(12)
+
+static u32 __iomem *miu_status;
+static u32 __iomem *miu_flush;
+
+static const char * const mstarv7_board_dt_compat[] __initconst = {
+ "mstar,infinity",
+ "mstar,infinity3",
+ "mstar,mercury5",
+ NULL,
+};
+
+/*
+ * This may need locking to deal with situations where an interrupt
+ * happens while we are in here and mb() gets called by the interrupt handler.
+ */
+static void mstarv7_mb(void)
+{
+ /* toggle the flush miu pipe fire bit */
+ writel_relaxed(0, miu_flush);
+ writel_relaxed(MSTARV7_L3BRIDGE_FLUSH_TRIGGER, miu_flush);
+ while (!(readl_relaxed(miu_status) & MSTARV7_L3BRIDGE_STATUS_DONE)) {
+ /* wait for flush to complete */
+ }
+}
+
+static void __init mstarv7_barriers_init(void)
+{
+ miu_flush = ioremap(MSTARV7_L3BRIDGE_FLUSH, sizeof(*miu_flush));
+ miu_status = ioremap(MSTARV7_L3BRIDGE_STATUS, sizeof(*miu_status));
+ soc_mb = mstarv7_mb;
+}
+
+static void __init mstarv7_init(void)
+{
+ mstarv7_barriers_init();
+}
+
+DT_MACHINE_START(MSTARV7_DT, "MStar/Sigmastar ARMv7 (Device Tree)")
+ .dt_compat = mstarv7_board_dt_compat,
+ .init_machine = mstarv7_init,
+MACHINE_END
--
2.27.0.rc0
BreadBee is an opensource development board based on the
MStar msc313(e) SoC.
Hardware details, schematics and so on can be found at:
https://github.com/breadbee/breadbee
Signed-off-by: Daniel Palmer <[email protected]>
---
arch/arm/boot/dts/Makefile | 3 +++
.../dts/infinity-msc313-breadbee_crust.dts | 25 +++++++++++++++++++
.../boot/dts/infinity3-msc313e-breadbee.dts | 25 +++++++++++++++++++
3 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
create mode 100644 arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..4a5f8075a4f6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1342,6 +1342,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8127-moose.dtb \
mt8135-evbp1.dtb
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
+dtb-$(CONFIG_ARCH_MSTARV7) += \
+ infinity-msc313-breadbee_crust.dtb \
+ infinity3-msc313e-breadbee.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts b/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
new file mode 100644
index 000000000000..8a827c8fd8b2
--- /dev/null
+++ b/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+/dts-v1/;
+#include "infinity-msc313.dtsi"
+
+/ {
+ model = "breadbee-crust";
+ compatible = "thingyjp,breadbee-crust", "mstar,infinity";
+
+ aliases {
+ serial0 = &pm_uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&pm_uart {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
new file mode 100644
index 000000000000..423bb32e6b74
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+/dts-v1/;
+#include "infinity3-msc313e.dtsi"
+
+/ {
+ model = "breadbee";
+ compatible = "thingyjp,breadbee", "mstar,infinity3";
+
+ aliases {
+ serial0 = &pm_uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&pm_uart {
+ status = "okay";
+};
--
2.27.0.rc0
Adds inital support for the 70mai midrive d08 dash camera.
Signed-off-by: Daniel Palmer <[email protected]>
---
arch/arm/boot/dts/Makefile | 3 ++-
.../boot/dts/mercury5-ssc8336n-midrive08.dts | 25 +++++++++++++++++++
2 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4a5f8075a4f6..35c7ecc52c60 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1344,7 +1344,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
dtb-$(CONFIG_ARCH_MSTARV7) += \
infinity-msc313-breadbee_crust.dtb \
- infinity3-msc313e-breadbee.dtb
+ infinity3-msc313e-breadbee.dtb \
+ mercury5-ssc8336n-midrive08.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
new file mode 100644
index 000000000000..4ee50ecf6ab1
--- /dev/null
+++ b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+/dts-v1/;
+#include "mercury5-ssc8336n.dtsi"
+
+/ {
+ model = "midrive d08";
+ compatible = "70mai,midrived08", "mstar,mercury5";
+
+ aliases {
+ serial0 = &pm_uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&pm_uart {
+ status = "okay";
+};
--
2.27.0.rc0
Hi Daniel,
Am 10.06.20 um 11:03 schrieb Daniel Palmer:
> Adds a prefixes for MStar, thingy.jp, 70mai and then defines compatible
> strings for the first MStar based boards.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> ---
> .../devicetree/bindings/arm/mstar.yaml | 30 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 6 ++++
> MAINTAINERS | 6 ++++
> 3 files changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar.yaml
> new file mode 100644
> index 000000000000..09e87cf6d6f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mstar.yaml
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mstar.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MStar platforms device tree bindings
> +
> +maintainers:
> + - Daniel Palmer <[email protected]>
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> + - description: thingy.jp BreadBee
> + items:
> + - const: thingyjp,breadbee
> + - const: mstar,infinity3
> +
> + - description: thingy.jp BreadBee Crust
> + items:
> + - const: thingyjp,breadbee-crust
> + - const: mstar,infinity
> +
> + - description: 70mai midrive d08
> + items:
> + - const: 70mai,midrived08
> + - const: mstar,mercury5
I would advise to restructure these three for forward planning:
Use const only for the SoC compatible.
For the boards use an enum with (for now) only the one entry. This
affects the description, which may mislead people to duplicate these
blocks for each board rather than just for each SoC family. Take a look
at other existing files (e.g., my realtek.yaml and actions.yaml, but
note they don't have the new-style description line yet - I assume it'll
work the same in enum as in your oneOf).
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index ef6d75b9113a..1770fc794027 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -23,6 +23,8 @@ patternProperties:
> "^(simple-audio-card|simple-graph-card|st-plgpio|st-spics|ts),.*": true
>
> # Keep list in alphabetical order.
> + "^70mai,.*":
> + description: 70mai
"70mai Co., Ltd." please - don't just repeat the prefix.
> "^abilis,.*":
> description: Abilis Systems
> "^abracon,.*":
> @@ -678,6 +680,8 @@ patternProperties:
> description: Microsemi Corporation
> "^msi,.*":
> description: Micro-Star International Co. Ltd.
> + "^mstar,.*":
> + description: MStar Semiconductor, Inc.
> "^mti,.*":
> description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
> "^multi-inno,.*":
> @@ -1030,6 +1034,8 @@ patternProperties:
> description: Three Five Corp
> "^thine,.*":
> description: THine Electronics, Inc.
> + "^thingyjp,.*":
> + description: thingy.jp
> "^ti,.*":
> description: Texas Instruments
> "^tianma,.*":
If you split the vendor prefixes to a preceding patch, they have a
chance of getting Reviewed-bys more quickly. You can then also CC the
vendors on the prefixes you're assigning for them.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 77a3fa5e3edd..1ca77f97b8ee 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2110,6 +2110,12 @@ L: [email protected] (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/mach-pxa/mioa701.c
>
> +ARM/MStar/Sigmastar ARMv7 SoC support
> +M: Daniel Palmer <[email protected]>
> +L: [email protected] (moderated for non-subscribers)
> +S: Maintained
> +F: Documentation/devicetree/bindings/arm/mstar.yaml
> +
> ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
> M: Michael Petchkovsky <[email protected]>
> S: Maintained
In theory it's spelled Armv7 since 2017, but MAINTAINERS, subject prefix
conventions and many other places in Linux still use the old upper-case
spelling, too...
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
On Wed, Jun 10, 2020 at 11:08 AM Daniel Palmer <[email protected]> wrote:
> +/*
> + * This may need locking to deal with situations where an interrupt
> + * happens while we are in here and mb() gets called by the interrupt handler.
> + */
I would suspect that you don't need locking here, and locking would likely
make it worse.
From what I can tell, an interrupt happening anywhere inside of mstarv7_mb()
would still result in the function completing (as miu_status still has the
MSTARV7_L3BRIDGE_STATUS_DONE bit set) and nothing that could
happen inside the irq would make the barrier weaker, only stronger.
> +static void mstarv7_mb(void)
> +{
> + /* toggle the flush miu pipe fire bit */
> + writel_relaxed(0, miu_flush);
> + writel_relaxed(MSTARV7_L3BRIDGE_FLUSH_TRIGGER, miu_flush);
> + while (!(readl_relaxed(miu_status) & MSTARV7_L3BRIDGE_STATUS_DONE)) {
> + /* wait for flush to complete */
> + }
> +}
This is a heavy memory barrier indeed.
The use of _relaxed() accessors is normally a bad idea and should be
avoided, but
this is one of the places where it is necessary because the normal
writel()/readl()
would recurse into arm_heavy_barrier(). Can you add a comment explaining this
for the next reviewer?
> +static void __init mstarv7_barriers_init(void)
> +{
> + miu_flush = ioremap(MSTARV7_L3BRIDGE_FLUSH, sizeof(*miu_flush));
> + miu_status = ioremap(MSTARV7_L3BRIDGE_STATUS, sizeof(*miu_status));
> + soc_mb = mstarv7_mb;
> +}
Hardcoding physical addresses is generally considered bad style,
even if you know the address in advance. Can you change this to get
the address of the L3BRIDGE from DT instead and just hardcode the
offsets? Note that they are in the same physical page, so you only
need a single of_iomap().
> +static void __init mstarv7_init(void)
> +{
> + mstarv7_barriers_init();
> +}
I think you can fold this into a single function.
Arnd
> > +
> > +properties:
> > + $nodename:
> > + const: '/'
> > + compatible:
> > + oneOf:
> > + - description: thingy.jp BreadBee
> > + items:
> > + - const: thingyjp,breadbee
> > + - const: mstar,infinity3
> > +
> > + - description: thingy.jp BreadBee Crust
> > + items:
> > + - const: thingyjp,breadbee-crust
> > + - const: mstar,infinity
> > +
> > + - description: 70mai midrive d08
> > + items:
> > + - const: 70mai,midrived08
> > + - const: mstar,mercury5
>
> I would advise to restructure these three for forward planning:
That makes a lot of sense. To be honest I basically copied something
that was in-tree to come up with something that would make checkpatch
happy and didn't think too much about it.
> > # Keep list in alphabetical order.
> > + "^70mai,.*":
> > + description: 70mai
>
> "70mai Co., Ltd." please - don't just repeat the prefix.
Understood.
> If you split the vendor prefixes to a preceding patch, they have a
> chance of getting Reviewed-bys more quickly. You can then also CC the
> vendors on the prefixes you're assigning for them.
thingy.jp is the vendor I'm using for the breadbee project. As for
70mai and MStar/Sigmastar I have
tried reaching out to them in the past and they don't respond. In
70mai's case their camera doesn't
run Linux by default so I don't think they will care much.
If it helps I can split them out but I'm not sure if it'll be possible
to ever get the ok from the other vendors.
For what it's worth the "mstar" prefix is what was being used in their
kernels up until very recently when
they switched everything to using "sstar" for SigmaStar. I considered
using the sstar prefix but went
with mstar because SigmaStar is totally unknown whereas MStar is
slightly known, would be more
recognisable, most of the chips still have mstar written on them and so on.
> > +ARM/MStar/Sigmastar ARMv7 SoC support
> > +M: Daniel Palmer <[email protected]>
> > +L: [email protected] (moderated for non-subscribers)
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/arm/mstar.yaml
> > +
> > ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
> > M: Michael Petchkovsky <[email protected]>
> > S: Maintained
>
> In theory it's spelled Armv7 since 2017, but MAINTAINERS, subject prefix
> conventions and many other places in Linux still use the old upper-case
> spelling, too...
Understood. I'll fix that up.
Thankyou for your input,
Daniel
Adds initial dtsi for the base MStar ARMv7 SoCs, family dtsis for infinity
and mercury families, and then some chip level dtsis for chips in those
families.
Signed-off-by: Daniel Palmer <[email protected]>
---
MAINTAINERS | 3 +
arch/arm/boot/dts/infinity-msc313.dtsi | 14 +++++
arch/arm/boot/dts/infinity.dtsi | 10 ++++
arch/arm/boot/dts/infinity3-msc313e.dtsi | 14 +++++
arch/arm/boot/dts/infinity3.dtsi | 10 ++++
arch/arm/boot/dts/mercury5-ssc8336n.dtsi | 14 +++++
arch/arm/boot/dts/mercury5.dtsi | 10 ++++
arch/arm/boot/dts/mstar-v7.dtsi | 71 ++++++++++++++++++++++++
8 files changed, 146 insertions(+)
create mode 100644 arch/arm/boot/dts/infinity-msc313.dtsi
create mode 100644 arch/arm/boot/dts/infinity.dtsi
create mode 100644 arch/arm/boot/dts/infinity3-msc313e.dtsi
create mode 100644 arch/arm/boot/dts/infinity3.dtsi
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n.dtsi
create mode 100644 arch/arm/boot/dts/mercury5.dtsi
create mode 100644 arch/arm/boot/dts/mstar-v7.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 754521938303..839ae0250d3d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2114,6 +2114,9 @@ ARM/MStar/Sigmastar ARMv7 SoC support
M: Daniel Palmer <[email protected]>
L: [email protected] (moderated for non-subscribers)
S: Maintained
+F: arch/arm/boot/dts/infinity*.dtsi
+F: arch/arm/boot/dts/mercury*.dtsi
+F: arch/arm/boot/dts/mstar-v7.dtsi
F: arch/arm/mach-mstar/
F: Documentation/devicetree/bindings/arm/mstar.yaml
diff --git a/arch/arm/boot/dts/infinity-msc313.dtsi b/arch/arm/boot/dts/infinity-msc313.dtsi
new file mode 100644
index 000000000000..4eb522e6a75d
--- /dev/null
+++ b/arch/arm/boot/dts/infinity-msc313.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "infinity.dtsi"
+
+/ {
+ memory {
+ device_type = "memory";
+ reg = <0x20000000 0x4000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/infinity.dtsi b/arch/arm/boot/dts/infinity.dtsi
new file mode 100644
index 000000000000..25d379028689
--- /dev/null
+++ b/arch/arm/boot/dts/infinity.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "mstar-v7.dtsi"
+
+/ {
+};
diff --git a/arch/arm/boot/dts/infinity3-msc313e.dtsi b/arch/arm/boot/dts/infinity3-msc313e.dtsi
new file mode 100644
index 000000000000..d0c53153faad
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3-msc313e.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "infinity3.dtsi"
+
+/ {
+ memory {
+ device_type = "memory";
+ reg = <0x20000000 0x4000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/infinity3.dtsi b/arch/arm/boot/dts/infinity3.dtsi
new file mode 100644
index 000000000000..cf5f18a07835
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "infinity.dtsi"
+
+/ {
+};
diff --git a/arch/arm/boot/dts/mercury5-ssc8336n.dtsi b/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
new file mode 100644
index 000000000000..7513f903c838
--- /dev/null
+++ b/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "mercury5.dtsi"
+
+/ {
+ memory {
+ device_type = "memory";
+ reg = <0x20000000 0x4000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/mercury5.dtsi b/arch/arm/boot/dts/mercury5.dtsi
new file mode 100644
index 000000000000..25d379028689
--- /dev/null
+++ b/arch/arm/boot/dts/mercury5.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "mstar-v7.dtsi"
+
+/ {
+};
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
new file mode 100644
index 000000000000..0fccc4ca52a4
--- /dev/null
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ };
+ };
+
+ arch_timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>;
+ clock-frequency = <6000000>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gic: interrupt-controller@16001000 {
+ compatible = "arm,cortex-a7-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-controller;
+ reg = <0x16001000 0x1000>,
+ <0x16002000 0x1000>;
+ };
+
+ pm_uart: uart@1f221000 {
+ compatible = "ns16550a";
+ reg = <0x1f221000 0x100>;
+ reg-shift = <3>;
+ clock-frequency = <172000000>;
+ status = "disabled";
+ };
+ };
+};
--
2.27.0.rc0
Daniel,
On 2020-06-10 10:04, Daniel Palmer wrote:
> Adds initial dtsi for the base MStar ARMv7 SoCs, family dtsis for
> infinity
> and mercury families, and then some chip level dtsis for chips in those
> families.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> ---
> MAINTAINERS | 3 +
> arch/arm/boot/dts/infinity-msc313.dtsi | 14 +++++
> arch/arm/boot/dts/infinity.dtsi | 10 ++++
> arch/arm/boot/dts/infinity3-msc313e.dtsi | 14 +++++
> arch/arm/boot/dts/infinity3.dtsi | 10 ++++
> arch/arm/boot/dts/mercury5-ssc8336n.dtsi | 14 +++++
> arch/arm/boot/dts/mercury5.dtsi | 10 ++++
> arch/arm/boot/dts/mstar-v7.dtsi | 71 ++++++++++++++++++++++++
> 8 files changed, 146 insertions(+)
> create mode 100644 arch/arm/boot/dts/infinity-msc313.dtsi
> create mode 100644 arch/arm/boot/dts/infinity.dtsi
> create mode 100644 arch/arm/boot/dts/infinity3-msc313e.dtsi
> create mode 100644 arch/arm/boot/dts/infinity3.dtsi
> create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n.dtsi
> create mode 100644 arch/arm/boot/dts/mercury5.dtsi
> create mode 100644 arch/arm/boot/dts/mstar-v7.dtsi
[...]
> diff --git a/arch/arm/boot/dts/mstar-v7.dtsi
> b/arch/arm/boot/dts/mstar-v7.dtsi
> new file mode 100644
> index 000000000000..0fccc4ca52a4
> --- /dev/null
> +++ b/arch/arm/boot/dts/mstar-v7.dtsi
> @@ -0,0 +1,71 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <&gic>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x0>;
> + };
> + };
> +
> + arch_timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2)
> + | IRQ_TYPE_LEVEL_LOW)>;
> + clock-frequency = <6000000>;
This is 2020, and not 2012 anymore. The frequency should be set
by your favourite bootloader.
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a7-pmu";
> + interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + soc: soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + gic: interrupt-controller@16001000 {
> + compatible = "arm,cortex-a7-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-controller;
> + reg = <0x16001000 0x1000>,
> + <0x16002000 0x1000>;
The GICC region is likely to be 8kB, and not 4kB.
Missing GICH and GICV regions, as well as the maintenance interrupt.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Am 10.06.20 um 11:04 schrieb Daniel Palmer:
> Initial support for the MStar/Sigmastar infinity/mercury series of ARMv7
> based IP camera and dashcam SoCs.
>
> These chips are interesting in that they contain a Cortex A7,
"Cortex-A7"
> peripherals and system memory in a single tiny QFN package that
> can be hand soldered allowing almost anyone to embed Linux
"soldered, allowing"?
> in their projects.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> ---
> MAINTAINERS | 1 +
> arch/arm/Kconfig | 2 +
> arch/arm/Makefile | 1 +
> arch/arm/mach-mstar/Kconfig | 26 +++++++++++++
> arch/arm/mach-mstar/Makefile | 1 +
> arch/arm/mach-mstar/mstarv7.c | 72 +++++++++++++++++++++++++++++++++++
> 6 files changed, 103 insertions(+)
> create mode 100644 arch/arm/mach-mstar/Kconfig
> create mode 100644 arch/arm/mach-mstar/Makefile
> create mode 100644 arch/arm/mach-mstar/mstarv7.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ca77f97b8ee..754521938303 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2114,6 +2114,7 @@ ARM/MStar/Sigmastar ARMv7 SoC support
> M: Daniel Palmer <[email protected]>
> L: [email protected] (moderated for non-subscribers)
> S: Maintained
> +F: arch/arm/mach-mstar/
> F: Documentation/devicetree/bindings/arm/mstar.yaml
>
> ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
[snip]
The sort order has recently been changed to case-sensitive, i.e., you
should append arch after Documentation.
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Hi Andreas,
On Thu, 11 Jun 2020 at 21:49, Andreas Färber <[email protected]> wrote:
> > peripherals and system memory in a single tiny QFN package that
> > can be hand soldered allowing almost anyone to embed Linux
>
> "soldered, allowing"?
The original reads ok to me. Maybe I can just split that into two sentences?
Like ".. QFN package that can be hand soldered. This allows almost anyone..".
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2114,6 +2114,7 @@ ARM/MStar/Sigmastar ARMv7 SoC support
> > M: Daniel Palmer <[email protected]>
> > L: [email protected] (moderated for non-subscribers)
> > S: Maintained
> > +F: arch/arm/mach-mstar/
> > F: Documentation/devicetree/bindings/arm/mstar.yaml
> >
> > ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
> [snip]
>
> The sort order has recently been changed to case-sensitive, i.e., you
> should append arch after Documentation.
Interesting. Checkpatch didn't complain about that although it
complained about the
original ordering I had.
Thanks for the input.
Daniel
Hi Andreas,
On Thu, 11 Jun 2020 at 21:58, Andreas Färber <[email protected]> wrote:
> You call the dir mach-mstar, but name the Kconfig ARCH_MSTARV7. I had
> previously been asked to just use the vendor name, so this should
> probably be just ARCH_MSTAR. Outside arch/arm/ you can then use ARM &&
> ARCH_MSTAR condition to make things 32-bit only, allowing to reuse
> ARCH_MSTAR for arm64 or whatever.
The ARM9 MStar chips before they switched to a common ARMv7 base aren't directly
compatible so I thought there should be some distinction there. I
doubt anyone will do it
but I made the directory mach-mstar so potentially someone could add
machine support
for the older stuff to without having more directories.
> > + bool "MStar/Sigmastar ARMv7 SoC Support"
> > + depends on ARCH_MULTI_V7
> > + select ARM_GIC
> > + select ARM_HEAVY_MB
> > + help
> > + Support for newer MStar/Sigmastar SoC families that are
> > + based on ARMv7 cores like the Cortex A7 and share the same
> > + basic hardware like the infinity and mercury series.
> > +
> > +if ARCH_MSTARV7
> > +
> > +config MACH_INFINITY
> > + bool "MStar/Sigmastar infinity SoC support"
> > + default ARCH_MSTARV7
> > + help
> > + Support for MStar/Sigmastar infinity IP camera SoCs.
> > +
> > +config MACH_MERCURY
> > + bool "MStar/Sigmastar mercury SoC support"
> > + default ARCH_MSTARV7
> > + help
> > + Support for MStar/Sigmastar mercury dash camera SoCs.
> > + Note that older Mercury2 SoCs are ARM9 based and not supported.
>
> Is this comment really helpful? This menu item would only seem to come
> up after having selected multi_v7, which kind of rules out ARM9.
The older mercury2 based chips seem to still be available and used in
drive recorders
that are on the market right now. The infinity series is all ARMv7 so
can be supported
but for the mercury series only the newer ones are ARMv7 so I thought
it was worth
mentioning that "mercury SoC support" doesn't mean all of them. I'll
take it out if you
think it's unnecessary.
> Consider adding mercury in a second step?
I'll think about that. I wanted to try to get a machine that isn't one
I'm personally making
into the series.
Cheers,
Daniel
Hi,
Am 10.06.20 um 11:04 schrieb Daniel Palmer:
> Adds initial dtsi for the base MStar ARMv7 SoCs, family dtsis for infinity
> and mercury families, and then some chip level dtsis for chips in those
> families.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> ---
> MAINTAINERS | 3 +
> arch/arm/boot/dts/infinity-msc313.dtsi | 14 +++++
> arch/arm/boot/dts/infinity.dtsi | 10 ++++
> arch/arm/boot/dts/infinity3-msc313e.dtsi | 14 +++++
> arch/arm/boot/dts/infinity3.dtsi | 10 ++++
> arch/arm/boot/dts/mercury5-ssc8336n.dtsi | 14 +++++
> arch/arm/boot/dts/mercury5.dtsi | 10 ++++
> arch/arm/boot/dts/mstar-v7.dtsi | 71 ++++++++++++++++++++++++
> 8 files changed, 146 insertions(+)
Can you split this up into three parts for easier review?
> create mode 100644 arch/arm/boot/dts/infinity-msc313.dtsi
> create mode 100644 arch/arm/boot/dts/infinity.dtsi
> create mode 100644 arch/arm/boot/dts/infinity3-msc313e.dtsi
> create mode 100644 arch/arm/boot/dts/infinity3.dtsi
> create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n.dtsi
> create mode 100644 arch/arm/boot/dts/mercury5.dtsi
> create mode 100644 arch/arm/boot/dts/mstar-v7.dtsi
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 754521938303..839ae0250d3d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2114,6 +2114,9 @@ ARM/MStar/Sigmastar ARMv7 SoC support
> M: Daniel Palmer <[email protected]>
> L: [email protected] (moderated for non-subscribers)
> S: Maintained
> +F: arch/arm/boot/dts/infinity*.dtsi
> +F: arch/arm/boot/dts/mercury*.dtsi
> +F: arch/arm/boot/dts/mstar-v7.dtsi
Sort order wrt D.
> F: arch/arm/mach-mstar/
> F: Documentation/devicetree/bindings/arm/mstar.yaml
>
> diff --git a/arch/arm/boot/dts/infinity-msc313.dtsi b/arch/arm/boot/dts/infinity-msc313.dtsi
> new file mode 100644
> index 000000000000..4eb522e6a75d
> --- /dev/null
> +++ b/arch/arm/boot/dts/infinity-msc313.dtsi
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0
DTs as hardware description should be dual-licensed as either MIT or
BSD-2-Clause, similar to the schema.
Also, elsewhere, for any code that might get reused for OpenOCD (e.g.,
clk drivers and low-level init like machine - 2/5) or other non-kernel
projects potentially incompatible with GPL-2.0-only, it would be useful
to use the -or-later version of the GPL for code sharing - if the
sources you used permit that.
> +/*
> + * Copyright (c) 2019 thingy.jp.
2019-2020? Check elsewhere.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +#include "infinity.dtsi"
> +
> +/ {
> + memory {
> + device_type = "memory";
> + reg = <0x20000000 0x4000000>;
The memory node needs to become memory@20000000 then.
> + };
I take it, this RAM is integrated? Maybe add some explanation of what
this file is
> +};
> diff --git a/arch/arm/boot/dts/infinity.dtsi b/arch/arm/boot/dts/infinity.dtsi
> new file mode 100644
> index 000000000000..25d379028689
> --- /dev/null
> +++ b/arch/arm/boot/dts/infinity.dtsi
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +#include "mstar-v7.dtsi"
> +
> +/ {
> +};
What do you intend to add here? Is it really needed? (same below)
Pre-DT-Schema I used to add a compatible property in the .dtsi, to make
sure we have at least the SoC's, in case someone neglects to add one in
their board's .dts. With DT schema that's no longer valid (if enum/const
is required), but Linux would still work better with than without.
> diff --git a/arch/arm/boot/dts/infinity3-msc313e.dtsi b/arch/arm/boot/dts/infinity3-msc313e.dtsi
> new file mode 100644
> index 000000000000..d0c53153faad
> --- /dev/null
> +++ b/arch/arm/boot/dts/infinity3-msc313e.dtsi
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +#include "infinity3.dtsi"
> +
> +/ {
> + memory {
Ditto, unit address missing.
> + device_type = "memory";
> + reg = <0x20000000 0x4000000>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/infinity3.dtsi b/arch/arm/boot/dts/infinity3.dtsi
> new file mode 100644
> index 000000000000..cf5f18a07835
> --- /dev/null
> +++ b/arch/arm/boot/dts/infinity3.dtsi
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +#include "infinity.dtsi"
> +
> +/ {
> +};
Don't you anticipate incompatibilities between infinity and infinity3,
i.e., things you don't want to inherit? Seems a bit optimistic. You can
of course overwrite properties, but deleting is more difficult.
> diff --git a/arch/arm/boot/dts/mercury5-ssc8336n.dtsi b/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
> new file mode 100644
> index 000000000000..7513f903c838
> --- /dev/null
> +++ b/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +#include "mercury5.dtsi"
> +
> +/ {
> + memory {
Unit address.
> + device_type = "memory";
> + reg = <0x20000000 0x4000000>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/mercury5.dtsi b/arch/arm/boot/dts/mercury5.dtsi
> new file mode 100644
> index 000000000000..25d379028689
> --- /dev/null
> +++ b/arch/arm/boot/dts/mercury5.dtsi
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +#include "mstar-v7.dtsi"
> +
> +/ {
> +};
> diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
> new file mode 100644
> index 000000000000..0fccc4ca52a4
> --- /dev/null
> +++ b/arch/arm/boot/dts/mstar-v7.dtsi
So this is the only file starting with mstar. Have you thought about
prefixing infinity/mercury, so that they're grouped together?
> @@ -0,0 +1,71 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;>
> + interrupt-parent = <&gic>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x0>;
> + };
> + };
> +
> + arch_timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2)
> + | IRQ_TYPE_LEVEL_LOW)>;
> + clock-frequency = <6000000>;
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a7-pmu";
> + interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
Lacking interrupt-affinity.
"This property should be present when there is more than a single SPI."
To deal with single- vs. dual-core models, you should give the pmu node
a label, e.g., arm_pmu used elsewhere, I think. Depending on your
preferences you could set it here in common code (less work) or in the
SoC-specific .dtsi where you know the number of CPUs for sure (safer to
not forget later).
> + };
> +
> + soc: soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
I had been instructed not to use full identity ranges but to exclude RAM
ranges for safety reasons.
> +
> + gic: interrupt-controller@16001000 {
> + compatible = "arm,cortex-a7-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-controller;
> + reg = <0x16001000 0x1000>,
> + <0x16002000 0x1000>;
In addition to Marc's comments, please reorder reg to below compatible
for consistency. Suggest to also reorder interrupt-controller before the
-cells properties, after reg.
> + };
> +
> + pm_uart: uart@1f221000 {
> + compatible = "ns16550a";
> + reg = <0x1f221000 0x100>;
> + reg-shift = <3>;
> + clock-frequency = <172000000>;
> + status = "disabled";
> + };
If you have any decent manuals for these SoCs, I suggest to check
whether there are any internal buses that you may want to model as
simple-bus for grouping. In-tree examples include meson and recently
merged rtd1195 - it affects the reg addresses and unit addresses via
suitable ranges mappings.
> + };
> +};
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
BTW I think the subject convention has been "ARM: dts: ...", with "ARM:
mstar: ..." more for mach-mstar.
Am 10.06.20 um 11:04 schrieb Daniel Palmer:
> Adds inital support for the 70mai midrive d08 dash camera.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> ---
> arch/arm/boot/dts/Makefile | 3 ++-
> .../boot/dts/mercury5-ssc8336n-midrive08.dts | 25 +++++++++++++++++++
> 2 files changed, 27 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4a5f8075a4f6..35c7ecc52c60 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1344,7 +1344,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
> dtb-$(CONFIG_ARCH_MSTARV7) += \
> infinity-msc313-breadbee_crust.dtb \
> - infinity3-msc313e-breadbee.dtb
> + infinity3-msc313e-breadbee.dtb \
> + mercury5-ssc8336n-midrive08.dtb
> dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
> dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-ast2500-evb.dtb \
> diff --git a/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
> new file mode 100644
> index 000000000000..4ee50ecf6ab1
> --- /dev/null
> +++ b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +/dts-v1/;
> +#include "mercury5-ssc8336n.dtsi"
> +
> +/ {
> + model = "midrive d08";
Couldn't find this on their website. Should this be "70mai midrive ..."
or is "midrive" a different brand?
> + compatible = "70mai,midrived08", "mstar,mercury5";
Have you considered naming it "70mai,midrive-d08" for better
readability? (affects 1/5)
> +
> + aliases {
> + serial0 = &pm_uart;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&pm_uart {
> + status = "okay";
clock-frequency?
> +};
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Hi Andreas,
On Thu, 11 Jun 2020 at 22:54, Andreas Färber <[email protected]> wrote:
>
> BTW I think the subject convention has been "ARM: dts: ...", with "ARM:
> mstar: ..." more for mach-mstar.
I noticed this after sending out this series. I've fixed up the
subjects in line with convention for the next try.
> > diff --git a/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
> > new file mode 100644
> > index 000000000000..4ee50ecf6ab1
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
> > @@ -0,0 +1,25 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019 thingy.jp.
> > + * Author: Daniel Palmer <[email protected]>
> > + */
> > +
> > +/dts-v1/;
> > +#include "mercury5-ssc8336n.dtsi"
> > +
> > +/ {
> > + model = "midrive d08";
>
> Couldn't find this on their website. Should this be "70mai midrive ..."
> or is "midrive" a different brand?
I think it should be 70mai Midrive D08 based on your comments on the
other model names.
On their site this camera is now called "Dash Cam Lite".
Midrive D08 is the name I bought it under and the name that was used
for it's FCC approval (https://fccid.io/2AOK9-MIDRIVED08) so that's
what I went
with.
> > + compatible = "70mai,midrived08", "mstar,mercury5";
>
> Have you considered naming it "70mai,midrive-d08" for better
> readability? (affects 1/5)
I went with midrived08 as that's what was used for the FCC and from
what I remember was written on the casing.
Thanks,
Daniel
+ linux-mediatek
Am 10.06.20 um 11:03 schrieb Daniel Palmer:
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index ef6d75b9113a..1770fc794027 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
[...]
> @@ -678,6 +680,8 @@ patternProperties:
> description: Microsemi Corporation
> "^msi,.*":
> description: Micro-Star International Co. Ltd.
> + "^mstar,.*":
> + description: MStar Semiconductor, Inc.
Depending on what exactly its legal status is these days
(https://en.wikipedia.org/wiki/MStar), you might either follow the below
MIPS example of describing it as
"MediaTek Inc. (formerly MStar Semiconductor, Inc.)",
or you might extend above description as
"MStar Semiconductor, Inc. (acquired by MediaTek Inc.)" if it still exists.
Or accordingly "Xiamen Xingchen Technology Co., Ltd. (formerly MStar
Semiconductor, Inc.)" if it was renamed to Sigmastar (in which case you
might additionally reserve sstar prefix for Sigmastar while at it).
http://www.sigmastarsemi.com/en/enterprisenews/info.aspx?itemid=441
> "^mti,.*":
> description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
> "^multi-inno,.*":
[...]
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 77a3fa5e3edd..1ca77f97b8ee 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2110,6 +2110,12 @@ L: [email protected] (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/mach-pxa/mioa701.c
>
> +ARM/MStar/Sigmastar ARMv7 SoC support
Here you do mention Sigmastar.
> +M: Daniel Palmer <[email protected]>
> +L: [email protected] (moderated for non-subscribers)
> +S: Maintained
> +F: Documentation/devicetree/bindings/arm/mstar.yaml
> +
> ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
> M: Michael Petchkovsky <[email protected]>
> S: Maintained
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Hi Andreas,
On Thu, 11 Jun 2020 at 23:39, Andreas Färber <[email protected]> wrote:
> The downside would be if someone wanted to add newer sstar chips under
> the new name later, then they wouldn't be grouped with predecessor
> families. Right now it seems like mercury and infinity are not that
> different, so I figured it might be useful for people contributing
> patches to see that changes in one might require review of the other.
I've thought about this too. One thing I considered was not using
mstar or sstar at all
and doing the same thing as sunxi and using either the "chenxing"
(MorningStar, MStar) or "xingchen" (SigmaStar)
moniker instead.
However, there are lots of kernel dumps from MStar based TVs etc in
the wild already that are using the mstar
prefix so just continuing to use that seems like the right thing to do.
Thanks,
Daniel
Am 10.06.20 um 11:04 schrieb Daniel Palmer:
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 59fde2d598d8..e7f4ca060c0f 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -197,6 +197,7 @@ machine-$(CONFIG_ARCH_MXC) += imx
> machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
> machine-$(CONFIG_ARCH_MILBEAUT) += milbeaut
> machine-$(CONFIG_ARCH_MXS) += mxs
> +machine-$(CONFIG_ARCH_MSTARV7) += mstar
> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> machine-$(CONFIG_ARCH_NPCM) += npcm
> machine-$(CONFIG_ARCH_NSPIRE) += nspire
> diff --git a/arch/arm/mach-mstar/Kconfig b/arch/arm/mach-mstar/Kconfig
> new file mode 100644
> index 000000000000..6235d0a7860a
> --- /dev/null
> +++ b/arch/arm/mach-mstar/Kconfig
> @@ -0,0 +1,26 @@
> +menuconfig ARCH_MSTARV7
You call the dir mach-mstar, but name the Kconfig ARCH_MSTARV7. I had
previously been asked to just use the vendor name, so this should
probably be just ARCH_MSTAR. Outside arch/arm/ you can then use ARM &&
ARCH_MSTAR condition to make things 32-bit only, allowing to reuse
ARCH_MSTAR for arm64 or whatever.
> + bool "MStar/Sigmastar ARMv7 SoC Support"
> + depends on ARCH_MULTI_V7
> + select ARM_GIC
> + select ARM_HEAVY_MB
> + help
> + Support for newer MStar/Sigmastar SoC families that are
> + based on ARMv7 cores like the Cortex A7 and share the same
> + basic hardware like the infinity and mercury series.
> +
> +if ARCH_MSTARV7
> +
> +config MACH_INFINITY
> + bool "MStar/Sigmastar infinity SoC support"
> + default ARCH_MSTARV7
> + help
> + Support for MStar/Sigmastar infinity IP camera SoCs.
> +
> +config MACH_MERCURY
> + bool "MStar/Sigmastar mercury SoC support"
> + default ARCH_MSTARV7
> + help
> + Support for MStar/Sigmastar mercury dash camera SoCs.
> + Note that older Mercury2 SoCs are ARM9 based and not supported.
Is this comment really helpful? This menu item would only seem to come
up after having selected multi_v7, which kind of rules out ARM9.
Consider adding mercury in a second step?
> +
> +endif
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Hi Andreas,
On Thu, 11 Jun 2020 at 22:39, Andreas Färber <[email protected]> wrote:
> Can you split this up into three parts for easier review?
Understood. Will do.
> 2019-2020? Check elsewhere.
The patches are originally from 2019. I'll update everything.
> > + * Author: Daniel Palmer <[email protected]>
> > + */
> > +
> > +#include "infinity.dtsi"
> > +
> > +/ {
> > + memory {
> > + device_type = "memory";
> > + reg = <0x20000000 0x4000000>;
>
> The memory node needs to become memory@20000000 then.
>
> > + };
>
> I take it, this RAM is integrated? Maybe add some explanation of what
> this file is
Yes. The memory is integrated and the size depends on the specific chips
so the memory node is at the chip level dtsi and not the board level.
> > +};
> > diff --git a/arch/arm/boot/dts/infinity.dtsi b/arch/arm/boot/dts/infinity.dtsi
> > new file mode 100644
> > index 000000000000..25d379028689
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/infinity.dtsi
> > @@ -0,0 +1,10 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019 thingy.jp.
> > + * Author: Daniel Palmer <[email protected]>
> > + */
> > +
> > +#include "mstar-v7.dtsi"
> > +
> > +/ {
> > +};
>
> What do you intend to add here? Is it really needed? (same below)
The specific nodes will go into there. This is mostly an artefact of splitting
the device trees out of a more developed tree.
> > new file mode 100644
> > index 000000000000..cf5f18a07835
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/infinity3.dtsi
> > @@ -0,0 +1,10 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019 thingy.jp.
> > + * Author: Daniel Palmer <[email protected]>
> > + */
> > +
> > +#include "infinity.dtsi"
> > +
> > +/ {
> > +};
>
> Don't you anticipate incompatibilities between infinity and infinity3,
> i.e., things you don't want to inherit? Seems a bit optimistic. You can
> of course overwrite properties, but deleting is more difficult.
In my tree with drivers for the rest of the hardware it hasn't been a problem.
So far I've found infinity, infinity2, infinity3, infinity5 and
infinity6 chips. The memory
map for them is almost identical and the changes are adding in more
copies of things
like DMA controllers, extra clock blocks etc.
Having infinity.dtsi as the base for the newer versions should avoid
having duplication
of nodes that aren't common on the mstar armv7 level but are common to
the infinity subtypes.
There are two good examples of this:
For infinity? the USB and SD controllers are at the same place for all
of the chips I've
found so far. Unfortunately, despite using the same IP block and the
same driver those
blocks are in different places in the mercury5. At the moment with all
of the infinity chips
pulling in infinity.dtsi those nodes are only in infinity.dtsi and
mercury5.dtsi.
If infinity?.dtsi are all stacked on top of the mstarv7.dtsi base then
there will be a number of
copies of the same nodes.
> > diff --git a/arch/arm/boot/dts/mercury5.dtsi b/arch/arm/boot/dts/mercury5.dtsi
> > new file mode 100644
> > index 000000000000..25d379028689
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/mercury5.dtsi
> > @@ -0,0 +1,10 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019 thingy.jp.
> > + * Author: Daniel Palmer <[email protected]>
> > + */
> > +
> > +#include "mstar-v7.dtsi"
> > +
> > +/ {
> > +};
> > diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
> > new file mode 100644
> > index 000000000000..0fccc4ca52a4
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/mstar-v7.dtsi
>
> So this is the only file starting with mstar. Have you thought about
> prefixing infinity/mercury, so that they're grouped together?
I have been thinking about that. I didn't see any other dts in arm that had
the vendor as a prefix though. With arm64 everything is in per vendor
subdirectories
to achieve the same thing.
> > + };
> > +
> > + pm_uart: uart@1f221000 {
> > + compatible = "ns16550a";
> > + reg = <0x1f221000 0x100>;
> > + reg-shift = <3>;
> > + clock-frequency = <172000000>;
> > + status = "disabled";
> > + };
>
> If you have any decent manuals for these SoCs,
Everything so far has been reverse engineered from an old 3.18
kernel, poking with a multimeter etc. I wish I had a decent manual.
> I suggest to check whether there are any internal buses that you may
> want to model as simple-bus for grouping. In-tree examples include meson
> and recently merged rtd1195 - it affects the reg addresses and unit addresses via
> suitable ranges mappings.
There is a bridge that is between the CPU and the peripheral registers
that doesn't quite fit simple-bus (from what I remember it needs a clk).
My plan was to introduce the thin driver for that bus (it just consumes the clks
it needs so they don't get disabled at the moment) after introducing
the clk support.
Thanks,
Daniel
Hi Daniel,
Am 11.06.20 um 15:01 schrieb Daniel Palmer:
> On Thu, 11 Jun 2020 at 21:49, Andreas Färber <[email protected]> wrote:
>>> peripherals and system memory in a single tiny QFN package that
>>> can be hand soldered allowing almost anyone to embed Linux
>>
>> "soldered, allowing"?
>
> The original reads ok to me. Maybe I can just split that into two sentences?
> Like ".. QFN package that can be hand soldered. This allows almost anyone..".
As non-native speaker I merely wondered whether a comma should better be
inserted to separate the two parts of the sentence. Splitting it in two
or leaving as is should be fine, too - I assume you're a native speaker.
Most people will rather read the bindings document than old git history,
so you might want to consider adding such a description below its title.
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -2114,6 +2114,7 @@ ARM/MStar/Sigmastar ARMv7 SoC support
>>> M: Daniel Palmer <[email protected]>
>>> L: [email protected] (moderated for non-subscribers)
>>> S: Maintained
>>> +F: arch/arm/mach-mstar/
>>> F: Documentation/devicetree/bindings/arm/mstar.yaml
>>>
>>> ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
>> [snip]
>>
>> The sort order has recently been changed to case-sensitive, i.e., you
>> should append arch after Documentation.
>
> Interesting. Checkpatch didn't complain about that although it
> complained about the
> original ordering I had.
I only noticed because someone refactored my Realtek section, causing a
merge conflict.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b50142d8528e1efc1c07f69c540f926c58ab3ad
Which reminds me, in 1/5 you should probably add a W: line (after S:
according to above sort commit) pointing to your
http://linux-chenxing.org/ website.
And for the community following your project, you may want to set up a
linux-chenxing mailing list on vger.kernel.org or on infradead.org and
add it as L:, to allow for error reports and patches to not just go to
you and crowded LAKML.
Cheers,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Hi,
Am 11.06.20 um 16:19 schrieb Daniel Palmer:
> On Thu, 11 Jun 2020 at 22:39, Andreas Färber <[email protected]> wrote:
>>> diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
>>> new file mode 100644
>>> index 000000000000..0fccc4ca52a4
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/mstar-v7.dtsi
>>
>> So this is the only file starting with mstar. Have you thought about
>> prefixing infinity/mercury, so that they're grouped together?
>
> I have been thinking about that. I didn't see any other dts in arm that had
> the vendor as a prefix though. With arm64 everything is in per vendor
> subdirectories
> to achieve the same thing.
qcom- and arm- are examples. Admittedly outliers, but for a new target
you don't have all the historical backwards-compatibility baggage.
The downside would be if someone wanted to add newer sstar chips under
the new name later, then they wouldn't be grouped with predecessor
families. Right now it seems like mercury and infinity are not that
different, so I figured it might be useful for people contributing
patches to see that changes in one might require review of the other.
Cheers,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Hi Andreas,
On Thu, 11 Jun 2020 at 23:27, Andreas Färber <[email protected]> wrote:
>
> Hi Daniel,
>
> Am 11.06.20 um 15:01 schrieb Daniel Palmer:
> > On Thu, 11 Jun 2020 at 21:49, Andreas Färber <[email protected]> wrote:
> >>> peripherals and system memory in a single tiny QFN package that
> >>> can be hand soldered allowing almost anyone to embed Linux
> >>
> >> "soldered, allowing"?
> >
> > The original reads ok to me. Maybe I can just split that into two sentences?
> > Like ".. QFN package that can be hand soldered. This allows almost anyone..".
>
> As non-native speaker I merely wondered whether a comma should better be
> inserted to separate the two parts of the sentence. Splitting it in two
> or leaving as is should be fine, too - I assume you're a native speaker.
I'm a native speaker but it's not my daily driver anymore so I often mangle it.
> Most people will rather read the bindings document than old git history,
> so you might want to consider adding such a description below its title.
I'll move the blurb and maybe reword it.
> Which reminds me, in 1/5 you should probably add a W: line (after S:
> according to above sort commit) pointing to your
> http://linux-chenxing.org/ website.
>
> And for the community following your project, you may want to set up a
> linux-chenxing mailing list on vger.kernel.org or on infradead.org and
> add it as L:, to allow for error reports and patches to not just go to
> you and crowded LAKML.
Very good points. I was thinking I should probably get this into mainline
before setting up lists etc.
Thanks,
Daniel
Am 10.06.20 um 11:04 schrieb Daniel Palmer:
> BreadBee is an opensource development board based on the
> MStar msc313(e) SoC.
>
> Hardware details, schematics and so on can be found at:
> https://github.com/breadbee/breadbee
>
> Signed-off-by: Daniel Palmer <[email protected]>
> ---
> arch/arm/boot/dts/Makefile | 3 +++
> .../dts/infinity-msc313-breadbee_crust.dts | 25 +++++++++++++++++++
> .../boot/dts/infinity3-msc313e-breadbee.dts | 25 +++++++++++++++++++
> 3 files changed, 53 insertions(+)
> create mode 100644 arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
> create mode 100644 arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e6a1cac0bfc7..4a5f8075a4f6 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1342,6 +1342,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt8127-moose.dtb \
> mt8135-evbp1.dtb
> dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
> +dtb-$(CONFIG_ARCH_MSTARV7) += \
> + infinity-msc313-breadbee_crust.dtb \
> + infinity3-msc313e-breadbee.dtb
> dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
> dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-ast2500-evb.dtb \
> diff --git a/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts b/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
> new file mode 100644
> index 000000000000..8a827c8fd8b2
> --- /dev/null
> +++ b/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +/dts-v1/;
> +#include "infinity-msc313.dtsi"
> +
> +/ {
> + model = "breadbee-crust";
This is user-visible text, so "BreadBee Crust" or so?
> + compatible = "thingyjp,breadbee-crust", "mstar,infinity";
> +
> + aliases {
> + serial0 = &pm_uart;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&pm_uart {
> + status = "okay";
Might this be a more suited place for temporary clock-frequency? For
lack of clk driver it would seem to depend on the board's bootloader
pre-configuring it rather than being a default of the SoC.
> +};
> diff --git a/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
> new file mode 100644
> index 000000000000..423bb32e6b74
> --- /dev/null
> +++ b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 thingy.jp.
> + * Author: Daniel Palmer <[email protected]>
> + */
> +
> +/dts-v1/;
> +#include "infinity3-msc313e.dtsi"
> +
> +/ {
> + model = "breadbee";
Ditto, "BreadBee"?
> + compatible = "thingyjp,breadbee", "mstar,infinity3";
> +
> + aliases {
> + serial0 = &pm_uart;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&pm_uart {
> + status = "okay";
Ditto, clock-frequency?
> +};
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Hi Andreas,
On Thu, 11 Jun 2020 at 22:45, Andreas Färber <[email protected]> wrote:
> > + compatible = "thingyjp,breadbee-crust", "mstar,infinity";
> > +
> > + aliases {
> > + serial0 = &pm_uart;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +};
> > +
> > +&pm_uart {
> > + status = "okay";
>
> Might this be a more suited place for temporary clock-frequency? For
> lack of clk driver it would seem to depend on the board's bootloader
> pre-configuring it rather than being a default of the SoC.
For all of the chips so far their second stage bootloader always turns
on a PLL and
reconfigures the pm_uart clock to use a 172MHz tap from that PLL right
at the start
of the boot process before u-boot is started. The new u-boot SPL I'm
working on to replace
that loader follows that convention.
Once the clk parts are in it should be possible to pull out the fixed
frequency and
replace it with a proper handle to that PLL tap.
Basically it's not documented anywhere except the assembly but the
convention for
these chips is to use the 172MHz clock for the uart pretty soon after
power on so it
made sense to have it in one place.
Thanks,
Daniel
This patch set adds initial support for MStar/Sigmastar's
Armv7 based SoCs. There is just enough here to get to a shell
with an initramfs but support for a lot of the hardware is
in progress and will follow.
MStar also shipped chips with MIPS cores and ARM9 etc which
are incompatible so I've tried to make the distinction in the
code that this is strictly for the Armv7 based chips.
Differences from v2:
1. With Marc Zyngier's help the GIC node has been filled out properly.
2. A comment was added to the arch timer node to explain why the
clock-frequency is specified. Basically the vendor u-boot is old and
broken.
3. Based on Arnd Bergmann's feedback the heavy memory barrier is now
implemented using a DT node to specify where the registers are instead
of hardcoding their location. A binding description has been added for
the new node.
4. Expanded comments around the heavy memory barrier code so it's more
obvious why it looks like it does.
5. The heavy memory barrier init code was folded into the machine init
function.
6. Updated the device tree bindings and prefixes based on Andreas Färber's
feedback. They have also been split out into a number of commits
7. Based on Andreas Färber's feedback I've added the "riu" (register interface
unit) internal bus that contains all of the peripheral registers and the proper
ranges for the soc node. This bus has clocks, interrupts and some configuration
register so it might get it's own driver in the future.
8. I've dropped the pmu node for now as it's not needed to boot and I'm not
sure of the relationship between the single core in most of the chips and
the 4 documented interrupts.
9. Numerous cosmetic changes based on Andreas Färber's feedback.
Differences from v1:
1. v1 only really supported two specific chips that were known
at the time of submitting that patch series. Since then it's
become apparent that there are a few families of SoCs based
on the same ARMv7 core, clk blocks, interrupt controllers etc
and this v2 attempts to make support more generic so in the future
more SoCs from this lineage can be added. Support for some other
chips is already in progress and will follow.
2. v1 only added support for the BreadBee boards that I have been
working on. v2 also adds support for a readily available car dash
camera.
3. Support for the BreadBee board has been split into two top level
dts to cleanly support if either the msc313 or msc313e is mounted on
the board. The chips are pin compatible but some of the internal
hardware is different. The u-boot port for these SoCs can detect
which chip it is running on and select the right dts so the user
doesn't have to care which chip is mounted on their board.
Daniel Palmer (12):
dt-bindings: vendor-prefixes: Add mstar vendor prefix
dt-bindings: vendor-prefixes: Add sstar vendor prefix
dt-bindings: vendor-prefixes: Add 70mai vendor prefix
dt-bindings: vendor-prefixes: Add thingy.jp prefix
dt-bindings: dt-bindings: arm: Add mstar YAML schema
ARM: mstar: Add machine for MStar/Sigmastar Armv7 SoCs
ARM: mstar: Add binding details for mstar,l3bridge
ARM: mstar: Add Armv7 base dtsi
ARM: mstar: Add infinity/infinity3 family dtsis
ARM: mstar: Add mercury5 series dtsis
ARM: mstar: Add dts for msc313(e) based BreadBee boards
ARM: mstar: Add dts for 70mai midrive d08
.../devicetree/bindings/arm/mstar.yaml | 33 ++++++++
.../bindings/misc/mstar,l3bridge.yaml | 44 ++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 8 ++
MAINTAINERS | 11 +++
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 4 +
.../dts/infinity-msc313-breadbee_crust.dts | 25 ++++++
arch/arm/boot/dts/infinity-msc313.dtsi | 14 ++++
arch/arm/boot/dts/infinity.dtsi | 7 ++
.../boot/dts/infinity3-msc313e-breadbee.dts | 25 ++++++
arch/arm/boot/dts/infinity3-msc313e.dtsi | 14 ++++
arch/arm/boot/dts/infinity3.dtsi | 7 ++
.../boot/dts/mercury5-ssc8336n-midrive08.dts | 25 ++++++
arch/arm/boot/dts/mercury5-ssc8336n.dtsi | 14 ++++
arch/arm/boot/dts/mercury5.dtsi | 7 ++
arch/arm/boot/dts/mstar-v7.dtsi | 83 +++++++++++++++++++
arch/arm/mach-mstar/Kconfig | 26 ++++++
arch/arm/mach-mstar/Makefile | 1 +
arch/arm/mach-mstar/mstarv7.c | 80 ++++++++++++++++++
20 files changed, 431 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
create mode 100644 Documentation/devicetree/bindings/misc/mstar,l3bridge.yaml
create mode 100644 arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
create mode 100644 arch/arm/boot/dts/infinity-msc313.dtsi
create mode 100644 arch/arm/boot/dts/infinity.dtsi
create mode 100644 arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
create mode 100644 arch/arm/boot/dts/infinity3-msc313e.dtsi
create mode 100644 arch/arm/boot/dts/infinity3.dtsi
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n.dtsi
create mode 100644 arch/arm/boot/dts/mercury5.dtsi
create mode 100644 arch/arm/boot/dts/mstar-v7.dtsi
create mode 100644 arch/arm/mach-mstar/Kconfig
create mode 100644 arch/arm/mach-mstar/Makefile
create mode 100644 arch/arm/mach-mstar/mstarv7.c
--
2.27.0.rc0
Add prefix for 70mai Co., Ltd
Signed-off-by: Daniel Palmer <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 314a2ddcb6a0..7c45b4c6fe40 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -23,6 +23,8 @@ patternProperties:
"^(simple-audio-card|simple-graph-card|st-plgpio|st-spics|ts),.*": true
# Keep list in alphabetical order.
+ "^70mai,.*":
+ description: 70mai Co., Ltd.
"^abilis,.*":
description: Abilis Systems
"^abracon,.*":
--
2.27.0.rc0
This adds some intial boards for Armv7 based mstar platforms.
Signed-off-by: Daniel Palmer <[email protected]>
---
.../devicetree/bindings/arm/mstar.yaml | 33 +++++++++++++++++++
MAINTAINERS | 7 ++++
2 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
diff --git a/Documentation/devicetree/bindings/arm/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar.yaml
new file mode 100644
index 000000000000..633e89f415cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mstar.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mstar.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar platforms device tree bindings
+
+maintainers:
+ - Daniel Palmer <[email protected]>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ # infinity boards
+ items:
+ - enum:
+ - thingyjp,breadbee-crust # thingy.jp BreadBee Crust
+ - const: mstar,infinity
+
+ # infinity3 boards
+ items:
+ - enum:
+ - thingyjp,breadbee # thingy.jp BreadBee
+ - const: mstar,infinity3
+
+ # mercury5 boards
+ items:
+ - enum:
+ - 70mai,midrived08 # 70mai midrive d08
+ - const: mstar,mercury5
diff --git a/MAINTAINERS b/MAINTAINERS
index 77a3fa5e3edd..c44070f76a1b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2110,6 +2110,13 @@ L: [email protected] (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-pxa/mioa701.c
+ARM/MStar/Sigmastar Armv7 SoC support
+M: Daniel Palmer <[email protected]>
+L: [email protected] (moderated for non-subscribers)
+S: Maintained
+W: http://linux-chenxing.org/
+F: Documentation/devicetree/bindings/arm/mstar.yaml
+
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
M: Michael Petchkovsky <[email protected]>
S: Maintained
--
2.27.0.rc0
This adds a YAML description of the l3bridge node needed by the
platform code for the MStar/SigmaStar Armv7 SoCs.
Signed-off-by: Daniel Palmer <[email protected]>
---
.../bindings/misc/mstar,l3bridge.yaml | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/mstar,l3bridge.yaml
diff --git a/Documentation/devicetree/bindings/misc/mstar,l3bridge.yaml b/Documentation/devicetree/bindings/misc/mstar,l3bridge.yaml
new file mode 100644
index 000000000000..cb7fd1cdfb1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/mstar,l3bridge.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 thingy.jp.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/misc/mstar,l3bridge.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: MStar/SigmaStar Armv7 SoC l3bridge
+
+maintainers:
+ - Daniel Palmer <[email protected]>
+
+description: |
+ MStar/SigmaStar's Armv7 SoCs have a pipeline in the interface
+ between the CPU and memory. This means that before DMA capable
+ devices are allowed to run the pipeline must be flushed to ensure
+ everything is in memory.
+
+ The l3bridge region contains registers that allow such a flush
+ to be triggered.
+
+ This node is used by the platform code to find where the registers
+ are and install a barrier that triggers the required pipeline flush.
+
+properties:
+ compatible:
+ items:
+ - const: mstar,l3bridge
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ l3bridge: l3bridge@1f204400 {
+ compatible = "mstar,l3bridge";
+ reg = <0x1f204400 0x200>;
+ };
--
2.27.0.rc0
Adds initial dtsi for the base MStar/Sigmastar Armv7 SoCs.
These SoCs have very similar memory maps and this will avoid
duplicating nodes across multiple dtsis.
Signed-off-by: Daniel Palmer <[email protected]>
---
MAINTAINERS | 1 +
arch/arm/boot/dts/mstar-v7.dtsi | 83 +++++++++++++++++++++++++++++++++
2 files changed, 84 insertions(+)
create mode 100644 arch/arm/boot/dts/mstar-v7.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 4bd57bbdddb0..00de66458e53 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2116,6 +2116,7 @@ L: [email protected] (moderated for non-subscribers)
S: Maintained
W: http://linux-chenxing.org/
F: Documentation/devicetree/bindings/arm/mstar.yaml
+F: arch/arm/boot/dts/mstar-v7.dtsi
F: arch/arm/mach-mstar/
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
new file mode 100644
index 000000000000..3b99bb435bb5
--- /dev/null
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ };
+ };
+
+ arch_timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>;
+ /*
+ * we shouldn't need this but the vendor
+ * u-boot is broken
+ */
+ clock-frequency = <6000000>;
+ };
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x16001000 0x16001000 0x00007000>,
+ <0x1f000000 0x1f000000 0x00400000>;
+
+ gic: interrupt-controller@16001000 {
+ compatible = "arm,cortex-a7-gic";
+ reg = <0x16001000 0x1000>,
+ <0x16002000 0x2000>,
+ <0x16004000 0x2000>,
+ <0x16006000 0x2000>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2)
+ | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ riu: bus@1f000000 {
+ compatible = "simple-bus";
+ reg = <0x1f000000 0x00400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x1f000000 0x00400000>;
+
+ l3bridge: l3bridge@204400 {
+ compatible = "mstar,l3bridge";
+ reg = <0x204400 0x200>;
+ };
+
+ pm_uart: uart@221000 {
+ compatible = "ns16550a";
+ reg = <0x221000 0x100>;
+ reg-shift = <3>;
+ clock-frequency = <172000000>;
+ status = "disabled";
+ };
+ };
+ };
+};
--
2.27.0.rc0
Add prefix for Xiamen Xingchen Technology Co., Ltd
Signed-off-by: Daniel Palmer <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 86b569a0c008..314a2ddcb6a0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -984,6 +984,8 @@ patternProperties:
description: Spreadtrum Communications Inc.
"^sst,.*":
description: Silicon Storage Technology, Inc.
+ "^sstar,.*":
+ description: Xiamen Xingchen(SigmaStar) Technology Co., Ltd. (formerly part of MStar Semiconductor, Inc.)
"^st,.*":
description: STMicroelectronics
"^starry,.*":
--
2.27.0.rc0
This adds two family level dtsis for the infinity and infinity3
and then adds a chip level dtsi each for a chip in those families.
infinity3.dtsi includes infinity.dtsi as these SoCs share most of
their memory map and we would have a lot of duplication otherwise.
Signed-off-by: Daniel Palmer <[email protected]>
---
MAINTAINERS | 1 +
arch/arm/boot/dts/infinity-msc313.dtsi | 14 ++++++++++++++
arch/arm/boot/dts/infinity.dtsi | 7 +++++++
arch/arm/boot/dts/infinity3-msc313e.dtsi | 14 ++++++++++++++
arch/arm/boot/dts/infinity3.dtsi | 7 +++++++
5 files changed, 43 insertions(+)
create mode 100644 arch/arm/boot/dts/infinity-msc313.dtsi
create mode 100644 arch/arm/boot/dts/infinity.dtsi
create mode 100644 arch/arm/boot/dts/infinity3-msc313e.dtsi
create mode 100644 arch/arm/boot/dts/infinity3.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 00de66458e53..7673acf55172 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2116,6 +2116,7 @@ L: [email protected] (moderated for non-subscribers)
S: Maintained
W: http://linux-chenxing.org/
F: Documentation/devicetree/bindings/arm/mstar.yaml
+F: arch/arm/boot/dts/infinity*.dtsi
F: arch/arm/boot/dts/mstar-v7.dtsi
F: arch/arm/mach-mstar/
diff --git a/arch/arm/boot/dts/infinity-msc313.dtsi b/arch/arm/boot/dts/infinity-msc313.dtsi
new file mode 100644
index 000000000000..42f2b5552c77
--- /dev/null
+++ b/arch/arm/boot/dts/infinity-msc313.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "infinity.dtsi"
+
+/ {
+ memory@20000000 {
+ device_type = "memory";
+ reg = <0x20000000 0x4000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/infinity.dtsi b/arch/arm/boot/dts/infinity.dtsi
new file mode 100644
index 000000000000..f68e6d59c328
--- /dev/null
+++ b/arch/arm/boot/dts/infinity.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "mstar-v7.dtsi"
diff --git a/arch/arm/boot/dts/infinity3-msc313e.dtsi b/arch/arm/boot/dts/infinity3-msc313e.dtsi
new file mode 100644
index 000000000000..4e7239afd823
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3-msc313e.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "infinity3.dtsi"
+
+/ {
+ memory@20000000 {
+ device_type = "memory";
+ reg = <0x20000000 0x4000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/infinity3.dtsi b/arch/arm/boot/dts/infinity3.dtsi
new file mode 100644
index 000000000000..2830d064c07d
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "infinity.dtsi"
--
2.27.0.rc0
This adds a family level dtsi for the mercury5 and then a
chip level dtsi for the ssc8336n chip.
Signed-off-by: Daniel Palmer <[email protected]>
---
MAINTAINERS | 1 +
arch/arm/boot/dts/mercury5-ssc8336n.dtsi | 14 ++++++++++++++
arch/arm/boot/dts/mercury5.dtsi | 7 +++++++
3 files changed, 22 insertions(+)
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n.dtsi
create mode 100644 arch/arm/boot/dts/mercury5.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 7673acf55172..246951ab0888 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2117,6 +2117,7 @@ S: Maintained
W: http://linux-chenxing.org/
F: Documentation/devicetree/bindings/arm/mstar.yaml
F: arch/arm/boot/dts/infinity*.dtsi
+F: arch/arm/boot/dts/mercury*.dtsi
F: arch/arm/boot/dts/mstar-v7.dtsi
F: arch/arm/mach-mstar/
diff --git a/arch/arm/boot/dts/mercury5-ssc8336n.dtsi b/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
new file mode 100644
index 000000000000..7d4a4630c25c
--- /dev/null
+++ b/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "mercury5.dtsi"
+
+/ {
+ memory@20000000 {
+ device_type = "memory";
+ reg = <0x20000000 0x4000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/mercury5.dtsi b/arch/arm/boot/dts/mercury5.dtsi
new file mode 100644
index 000000000000..f68e6d59c328
--- /dev/null
+++ b/arch/arm/boot/dts/mercury5.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include "mstar-v7.dtsi"
--
2.27.0.rc0
Add prefix for thingy.jp
Signed-off-by: Daniel Palmer <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 7c45b4c6fe40..70a8f2696427 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1036,6 +1036,8 @@ patternProperties:
description: Three Five Corp
"^thine,.*":
description: THine Electronics, Inc.
+ "^thingyjp,.*":
+ description: thingy.jp
"^ti,.*":
description: Texas Instruments
"^tianma,.*":
--
2.27.0.rc0
Adds initial support for the 70mai midrive d08 dash camera.
Signed-off-by: Daniel Palmer <[email protected]>
---
arch/arm/boot/dts/Makefile | 3 ++-
.../boot/dts/mercury5-ssc8336n-midrive08.dts | 25 +++++++++++++++++++
2 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4a5f8075a4f6..35c7ecc52c60 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1344,7 +1344,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
dtb-$(CONFIG_ARCH_MSTARV7) += \
infinity-msc313-breadbee_crust.dtb \
- infinity3-msc313e-breadbee.dtb
+ infinity3-msc313e-breadbee.dtb \
+ mercury5-ssc8336n-midrive08.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
new file mode 100644
index 000000000000..f24bd8cb8e60
--- /dev/null
+++ b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+/dts-v1/;
+#include "mercury5-ssc8336n.dtsi"
+
+/ {
+ model = "70mai Midrive D08";
+ compatible = "70mai,midrived08", "mstar,mercury5";
+
+ aliases {
+ serial0 = &pm_uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&pm_uart {
+ status = "okay";
+};
--
2.27.0.rc0
Initial support for the MStar/Sigmastar Armv7 based IP camera
and dashcam SoCs.
These chips are interesting in that they contain a Cortex-A7,
peripherals and system memory in a single tiny QFN package that
can be hand soldered allowing almost anyone to embed Linux
in their projects.
Signed-off-by: Daniel Palmer <[email protected]>
---
MAINTAINERS | 1 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-mstar/Kconfig | 26 ++++++++++++
arch/arm/mach-mstar/Makefile | 1 +
arch/arm/mach-mstar/mstarv7.c | 80 +++++++++++++++++++++++++++++++++++
6 files changed, 111 insertions(+)
create mode 100644 arch/arm/mach-mstar/Kconfig
create mode 100644 arch/arm/mach-mstar/Makefile
create mode 100644 arch/arm/mach-mstar/mstarv7.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c44070f76a1b..4bd57bbdddb0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2116,6 +2116,7 @@ L: [email protected] (moderated for non-subscribers)
S: Maintained
W: http://linux-chenxing.org/
F: Documentation/devicetree/bindings/arm/mstar.yaml
+F: arch/arm/mach-mstar/
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
M: Michael Petchkovsky <[email protected]>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fb6c85c5d344..e466694f8486 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -669,6 +669,8 @@ source "arch/arm/mach-mmp/Kconfig"
source "arch/arm/mach-moxart/Kconfig"
+source "arch/arm/mach-mstar/Kconfig"
+
source "arch/arm/mach-mv78xx0/Kconfig"
source "arch/arm/mach-mvebu/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 59fde2d598d8..e7f4ca060c0f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -197,6 +197,7 @@ machine-$(CONFIG_ARCH_MXC) += imx
machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
machine-$(CONFIG_ARCH_MILBEAUT) += milbeaut
machine-$(CONFIG_ARCH_MXS) += mxs
+machine-$(CONFIG_ARCH_MSTARV7) += mstar
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
machine-$(CONFIG_ARCH_NPCM) += npcm
machine-$(CONFIG_ARCH_NSPIRE) += nspire
diff --git a/arch/arm/mach-mstar/Kconfig b/arch/arm/mach-mstar/Kconfig
new file mode 100644
index 000000000000..52744fe32368
--- /dev/null
+++ b/arch/arm/mach-mstar/Kconfig
@@ -0,0 +1,26 @@
+menuconfig ARCH_MSTARV7
+ bool "MStar/Sigmastar Armv7 SoC Support"
+ depends on ARCH_MULTI_V7
+ select ARM_GIC
+ select ARM_HEAVY_MB
+ help
+ Support for newer MStar/Sigmastar SoC families that are
+ based on Armv7 cores like the Cortex A7 and share the same
+ basic hardware like the infinity and mercury series.
+
+if ARCH_MSTARV7
+
+config MACH_INFINITY
+ bool "MStar/Sigmastar infinity SoC support"
+ default ARCH_MSTARV7
+ help
+ Support for MStar/Sigmastar infinity IP camera SoCs.
+
+config MACH_MERCURY
+ bool "MStar/Sigmastar mercury SoC support"
+ default ARCH_MSTARV7
+ help
+ Support for MStar/Sigmastar mercury dash camera SoCs.
+ Note that older Mercury2 SoCs are ARM9 based and not supported.
+
+endif
diff --git a/arch/arm/mach-mstar/Makefile b/arch/arm/mach-mstar/Makefile
new file mode 100644
index 000000000000..93b0391ede7e
--- /dev/null
+++ b/arch/arm/mach-mstar/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARCH_MSTARV7) += mstarv7.o
diff --git a/arch/arm/mach-mstar/mstarv7.c b/arch/arm/mach-mstar/mstarv7.c
new file mode 100644
index 000000000000..81a4cbcab206
--- /dev/null
+++ b/arch/arm/mach-mstar/mstarv7.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree support for MStar/Sigmastar Armv7 SoCs
+ *
+ * Copyright (c) 2020 thingy.jp
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+#include <linux/init.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+/*
+ * In the u-boot code the area these registers are in is
+ * called "L3 bridge" and there are register descriptions
+ * for something in the same area called "AXI".
+ *
+ * It's not exactly known what this is but the vendor code
+ * for both u-boot and linux share calls to "flush the miu pipe".
+ * This seems to be to force pending CPU writes to memory so that
+ * the state is right before DMA capable devices try to read
+ * descriptors and data the CPU has prepared. Without doing this
+ * ethernet doesn't work reliably for example.
+ */
+
+#define MSTARV7_L3BRIDGE_FLUSH 0x14
+#define MSTARV7_L3BRIDGE_STATUS 0x40
+#define MSTARV7_L3BRIDGE_FLUSH_TRIGGER BIT(0)
+#define MSTARV7_L3BRIDGE_STATUS_DONE BIT(12)
+
+static void __iomem *l3bridge;
+
+static const char * const mstarv7_board_dt_compat[] __initconst = {
+ "mstar,infinity",
+ "mstar,infinity3",
+ "mstar,mercury5",
+ NULL,
+};
+
+/*
+ * This may need locking to deal with situations where an interrupt
+ * happens while we are in here and mb() gets called by the interrupt handler.
+ *
+ * The vendor code did have a spin lock but it doesn't seem to be needed and
+ * removing it hasn't caused any side effects so far.
+ *
+ * [writel|readl]_relaxed have to be used here because otherwise
+ * we'd end up right back in here.
+ */
+static void mstarv7_mb(void)
+{
+ /* toggle the flush miu pipe fire bit */
+ writel_relaxed(0, l3bridge + MSTARV7_L3BRIDGE_FLUSH);
+ writel_relaxed(MSTARV7_L3BRIDGE_FLUSH_TRIGGER, l3bridge
+ + MSTARV7_L3BRIDGE_FLUSH);
+ while (!(readl_relaxed(l3bridge + MSTARV7_L3BRIDGE_STATUS)
+ & MSTARV7_L3BRIDGE_STATUS_DONE)) {
+ /* wait for flush to complete */
+ }
+}
+
+static void __init mstarv7_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "mstar,l3bridge");
+ l3bridge = of_iomap(np, 0);
+ if (l3bridge)
+ soc_mb = mstarv7_mb;
+ else
+ pr_warn("Failed to install memory barrier, DMA will be broken!\n");
+}
+
+DT_MACHINE_START(MSTARV7_DT, "MStar/Sigmastar Armv7 (Device Tree)")
+ .dt_compat = mstarv7_board_dt_compat,
+ .init_machine = mstarv7_init,
+MACHINE_END
--
2.27.0.rc0
BreadBee is an opensource development board based on the
MStar msc313(e) SoC.
Hardware details, schematics and so on can be found at:
https://github.com/breadbee/breadbee
Signed-off-by: Daniel Palmer <[email protected]>
---
arch/arm/boot/dts/Makefile | 3 +++
.../dts/infinity-msc313-breadbee_crust.dts | 25 +++++++++++++++++++
.../boot/dts/infinity3-msc313e-breadbee.dts | 25 +++++++++++++++++++
3 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
create mode 100644 arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..4a5f8075a4f6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1342,6 +1342,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8127-moose.dtb \
mt8135-evbp1.dtb
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
+dtb-$(CONFIG_ARCH_MSTARV7) += \
+ infinity-msc313-breadbee_crust.dtb \
+ infinity3-msc313e-breadbee.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts b/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
new file mode 100644
index 000000000000..f24c5580d3e4
--- /dev/null
+++ b/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+/dts-v1/;
+#include "infinity-msc313.dtsi"
+
+/ {
+ model = "BreadBee Crust";
+ compatible = "thingyjp,breadbee-crust", "mstar,infinity";
+
+ aliases {
+ serial0 = &pm_uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&pm_uart {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
new file mode 100644
index 000000000000..1f93401c8530
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer <[email protected]>
+ */
+
+/dts-v1/;
+#include "infinity3-msc313e.dtsi"
+
+/ {
+ model = "BreadBee";
+ compatible = "thingyjp,breadbee", "mstar,infinity3";
+
+ aliases {
+ serial0 = &pm_uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&pm_uart {
+ status = "okay";
+};
--
2.27.0.rc0
On Fri, 12 Jun 2020 22:00:05 +0900, Daniel Palmer wrote:
> This adds some intial boards for Armv7 based mstar platforms.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> ---
> .../devicetree/bindings/arm/mstar.yaml | 33 +++++++++++++++++++
> MAINTAINERS | 7 ++++
> 2 files changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
Traceback (most recent call last):
File "/usr/local/bin/dt-doc-validate", line 64, in <module>
ret = check_doc(args.yamldt)
File "/usr/local/bin/dt-doc-validate", line 25, in check_doc
testtree = dtschema.load(filename, line_number=line_number, duplicate_keys=False)
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 595, in load
return yaml.load(f.read())
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/main.py", line 343, in load
return constructor.get_single_data()
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 113, in get_single_data
return self.construct_document(node)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 123, in construct_document
for _dummy in generator:
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 723, in construct_yaml_map
value = self.construct_mapping(node)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 440, in construct_mapping
return BaseConstructor.construct_mapping(self, node, deep=deep)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 257, in construct_mapping
if self.check_mapping_key(node, key_node, mapping, key, value):
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 295, in check_mapping_key
raise DuplicateKeyError(*args)
ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping
in "<unicode string>", line 18, column 9
found duplicate key "items" with value "[]" (original value: "[]")
in "<unicode string>", line 24, column 9
To suppress this check see:
http://yaml.readthedocs.io/en/latest/api.html#duplicate-keys
Duplicate keys will become an error in future releases, and are errors
by default when using the new API.
Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/arm/mstar.example.dts' failed
make[1]: *** [Documentation/devicetree/bindings/arm/mstar.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs....
Traceback (most recent call last):
File "/usr/local/bin/dt-mk-schema", line 34, in <module>
schemas = dtschema.process_schemas(args.schemas, core_schema=(not args.useronly))
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 557, in process_schemas
sch = process_schema(os.path.abspath(filename))
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 510, in process_schema
schema = load_schema(filename)
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 123, in load_schema
return do_load(os.path.join(schema_basedir, schema))
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 108, in do_load
return yaml.load(tmp)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/main.py", line 343, in load
return constructor.get_single_data()
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 113, in get_single_data
return self.construct_document(node)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 123, in construct_document
for _dummy in generator:
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 723, in construct_yaml_map
value = self.construct_mapping(node)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 440, in construct_mapping
return BaseConstructor.construct_mapping(self, node, deep=deep)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 257, in construct_mapping
if self.check_mapping_key(node, key_node, mapping, key, value):
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 295, in check_mapping_key
raise DuplicateKeyError(*args)
ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping
in "<unicode string>", line 18, column 9
found duplicate key "items" with value "[]" (original value: "[]")
in "<unicode string>", line 24, column 9
To suppress this check see:
http://yaml.readthedocs.io/en/latest/api.html#duplicate-keys
Duplicate keys will become an error in future releases, and are errors
by default when using the new API.
Documentation/devicetree/bindings/Makefile:45: recipe for target 'Documentation/devicetree/bindings/processed-schema.yaml' failed
make[1]: *** [Documentation/devicetree/bindings/processed-schema.yaml] Error 123
make[1]: *** Deleting file 'Documentation/devicetree/bindings/processed-schema.yaml'
Traceback (most recent call last):
File "/usr/local/bin/dt-mk-schema", line 34, in <module>
schemas = dtschema.process_schemas(args.schemas, core_schema=(not args.useronly))
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 557, in process_schemas
sch = process_schema(os.path.abspath(filename))
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 510, in process_schema
schema = load_schema(filename)
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 123, in load_schema
return do_load(os.path.join(schema_basedir, schema))
File "/usr/local/lib/python3.6/dist-packages/dtschema/lib.py", line 108, in do_load
return yaml.load(tmp)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/main.py", line 343, in load
return constructor.get_single_data()
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 113, in get_single_data
return self.construct_document(node)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 123, in construct_document
for _dummy in generator:
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 723, in construct_yaml_map
value = self.construct_mapping(node)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 440, in construct_mapping
return BaseConstructor.construct_mapping(self, node, deep=deep)
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 257, in construct_mapping
if self.check_mapping_key(node, key_node, mapping, key, value):
File "/usr/local/lib/python3.6/dist-packages/ruamel/yaml/constructor.py", line 295, in check_mapping_key
raise DuplicateKeyError(*args)
ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping
in "<unicode string>", line 18, column 9
found duplicate key "items" with value "[]" (original value: "[]")
in "<unicode string>", line 24, column 9
To suppress this check see:
http://yaml.readthedocs.io/en/latest/api.html#duplicate-keys
Duplicate keys will become an error in future releases, and are errors
by default when using the new API.
Documentation/devicetree/bindings/Makefile:41: recipe for target 'Documentation/devicetree/bindings/processed-schema-examples.yaml' failed
make[1]: *** [Documentation/devicetree/bindings/processed-schema-examples.yaml] Error 123
make[1]: *** Deleting file 'Documentation/devicetree/bindings/processed-schema-examples.yaml'
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1308156
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.