Message ID | 20191014061617.10296-1-daniel@0x0f.com |
---|---|
State | Changes Requested, archived |
Headers | show |
Series | [1/4] dt-bindings: arm: Initial MStar vendor prefixes and compatible strings | expand |
Context | Check | Description |
---|---|---|
robh/checkpatch | success | |
robh/dt-meta-schema | success |
On Mon, Oct 14, 2019 at 8:21 AM Daniel Palmer <daniel@0x0f.com> 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 <daniel@0x0f.com> > + > +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
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 <daniel@0x0f.com> > --- > .../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 <daniel@thingy.jp> > + > +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: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) > F: arch/arm/mach-pxa/mioa701.c > S: Maintained > > +ARM/MStar SoC support > +M: Daniel Palmer <daniel@thingy.jp> > +L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) > +F: Documentation/devicetree/bindings/arm/mstar.yaml > +S: Maintained > + > ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT > M: Michael Petchkovsky <mkpetch@internode.on.net> > 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 5:44 PM Daniel Palmer <daniel@0x0f.com> 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 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
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 <daniel@thingy.jp> + +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: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) F: arch/arm/mach-pxa/mioa701.c S: Maintained +ARM/MStar SoC support +M: Daniel Palmer <daniel@thingy.jp> +L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) +F: Documentation/devicetree/bindings/arm/mstar.yaml +S: Maintained + ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT M: Michael Petchkovsky <mkpetch@internode.on.net> S: Maintained
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 <daniel@0x0f.com> --- .../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