mbox series

[v2,00/10] ARM: mstar: Add basic support for i2m and SMP

Message ID 20201201134330.3037007-1-daniel@0x0f.com
Headers show
Series ARM: mstar: Add basic support for i2m and SMP | expand

Message

Daniel Palmer Dec. 1, 2020, 1:43 p.m. UTC 
Sorry for spamming this. I wanted to fix the DT parts
before anyone spent time looking at the DT related commits
in v1.

This series adds basic support for the infinity2m series
of chips. For now the SigmaStar SSD202D which is a dual
Cortex A7 in a QFN128 package.

These chips share most of the same hardware with the
currently supported infinity, infinity3 and mercury5
chips.

Changes since v1:

- Based on Arnd's feedback[0] there is now "mstar,smpctrl" as the 
  most generic compatible string for the smp control registers 
  and a more specific "sstar,ssd201" (yes sstar is right, this is
  a SigmaStar chip) string that is good for the SSD201 and SSD202D
  chips.

- Small code clean ups: remove initialiser for smpctrl, remove unneeded
  #ifdef CONFIG_SMP, make the smp_operations struct static and const.

0 - https://lore.kernel.org/linux-arm-kernel/CAK8P3a2MC5m4PdmXnwjGw_oZinKU93LP+eYQ8qaCmH4EesH0Bw@mail.gmail.com/

Daniel Palmer (10):
  dt-bindings: mstar: Add binding details for mstar,smpctrl
  dt-bindings: vendor-prefixes: Add honestar vendor prefix
  dt-bindings: mstar: Add Honestar SSD201_HT_V2 to mstar boards
  ARM: mstar: Add infinity2m support
  ARM: mstar: Add common dtsi for SSD201/SSD202D
  ARM: mstar: Add chip level dtsi for SSD202D
  ARM: mstar: Add dts for Honestar ssd201htv2
  ARM: mstar: Add smp ctrl registers to infinity2m dtsi
  ARM: mstar: Wire up smpctrl for SSD201/SSD202D
  ARM: mstar: SMP support

 .../bindings/arm/mstar/mstar,smpctrl.yaml     | 40 +++++++++++++++
 .../devicetree/bindings/arm/mstar/mstar.yaml  |  6 +++
 .../devicetree/bindings/vendor-prefixes.yaml  |  2 +
 arch/arm/boot/dts/Makefile                    |  1 +
 .../mstar-infinity2m-ssd202d-ssd201htv2.dts   | 25 ++++++++++
 .../boot/dts/mstar-infinity2m-ssd202d.dtsi    | 14 ++++++
 .../boot/dts/mstar-infinity2m-ssd20xd.dtsi    | 12 +++++
 arch/arm/boot/dts/mstar-infinity2m.dtsi       | 22 +++++++++
 arch/arm/boot/dts/mstar-v7.dtsi               |  2 +-
 arch/arm/mach-mstar/mstarv7.c                 | 49 +++++++++++++++++++
 10 files changed, 172 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
 create mode 100644 arch/arm/boot/dts/mstar-infinity2m-ssd202d-ssd201htv2.dts
 create mode 100644 arch/arm/boot/dts/mstar-infinity2m-ssd202d.dtsi
 create mode 100644 arch/arm/boot/dts/mstar-infinity2m-ssd20xd.dtsi
 create mode 100644 arch/arm/boot/dts/mstar-infinity2m.dtsi

Comments

Russell King (Oracle) Dec. 1, 2020, 3:04 p.m. UTC | #1 
On Tue, Dec 01, 2020 at 10:43:30PM +0900, Daniel Palmer wrote:
> +	np = of_find_compatible_node(NULL, NULL, "mstar,smpctrl");
> +	smpctrl = of_iomap(np, 0);
> +
> +	if (!smpctrl)
> +		return -ENODEV;

Wouldn't -ENOMEM be more appropriate here?
Daniel Palmer Dec. 2, 2020, 9:10 a.m. UTC | #2 
Hi Russell,

On Wed, 2 Dec 2020 at 00:04, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, Dec 01, 2020 at 10:43:30PM +0900, Daniel Palmer wrote:
> > +     np = of_find_compatible_node(NULL, NULL, "mstar,smpctrl");
> > +     smpctrl = of_iomap(np, 0);
> > +
> > +     if (!smpctrl)
> > +             return -ENODEV;
>
> Wouldn't -ENOMEM be more appropriate here?

There seems to be examples of both -ENOMEM and -ENODEV in other ARM platforms.
arch/arm/mach-aspeed/platsmp.c uses -ENODEV for example.

I went with -ENODEV there as the source of the error is most likely
the node not being in the device tree.
I didn't check the result of of_find_compatible_node() because for the
memory barrier code in the same file I was told it wasn't necessary.

Thanks,

Daniel