Hi Marcel,
On 03.07.20 09:56, Marcel Ziswiler wrote:
Hi Frieder
Nice to see some more i.MX 8M Mini action. Much appreciated!
On Thu, 2020-07-02 at 16:33 +0200, Schrempf Frieder wrote:
From: Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8MM
To avoid much confusion in NXP's nomenclature I would recommend writing this always as i.MX 8M Mini. Of course,
in code, using imx8mm is fine.
Ok, sounds reasonable.
including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
The matching baseboards have the same form factor and similar interfaces
as the other boards from the Kontron "Board-Line" family, including
SD card, 1G Ethernet, 100M Ethernet, USB Host/OTG, digital IOs, RS232,
RS485, CAN, LVDS or HDMI, RTC and much more.
Signed-off-by: Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>
---
.../dts/freescale/imx8mm-kontron-n8010-s.dts | 15 +
.../freescale/imx8mm-kontron-n8010-som.dtsi | 16 +
.../dts/freescale/imx8mm-kontron-n8011-s.dts | 15 +
.../freescale/imx8mm-kontron-n8011-som.dtsi | 16 +
.../dts/freescale/imx8mm-kontron-n801x-s.dtsi | 326 ++++++++++++++++++
.../freescale/imx8mm-kontron-n801x-som.dtsi | 281 +++++++++++++++
6 files changed, 669 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-n8010-s.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-n8010-som.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-n8011-s.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-n8011-som.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8010-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-
kontron-n8010-s.dts
new file mode 100644
index 000000000000..0911f2d0555b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8010-s.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
Don't you want to use the more common GPL-2.0+ OR MIT variant which allows for more freedom? At least NXP's
imx8mm.dtsi also uses that.
That actually sounds like a good idea. I will change that.
+/*
+ * Copyright (C) 2019 Kontron Electronics GmbH
I know that there is much about 2020 to rather be ignored.
Indeed, but I also once learned that you don't change the original date
in a copyright notice as it is used to express when the content has been
published or created first (and the original version has been online on
our server publically since 2019).
+ */
+
+/dts-v1/;
+
+#include "imx8mm-kontron-n8010-som.dtsi"
+#include "imx8mm-kontron-n801x-s.dtsi"
+
+/ {
+ model = "Kontron i.MX8MM N8010 S";
+ compatible = "kontron,imx8mm-n8010-s", "kontron,imx8mm-n8010-som",
+ "fsl,imx8mm";
I believe now with Linux having dropped the strict 80-column line length coding style limit we are allowed to
go up to 100 (;-p).
Right, I remember seeing some discussion about extending the column
limit. I will need to update my text editor's config.
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8010-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8010-som.dtsi
new file mode 100644
index 000000000000..5b178ce4ce1b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8010-som.dtsi
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Kontron Electronics GmbH
+ */
+
+#include "imx8mm-kontron-n801x-som.dtsi"
+
+/ {
+ model = "Kontron i.MX8MM N8010 SoM";
+ compatible = "kontron,imx8mm-n8010-som", "fsl,imx8mm";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x0 0x40000000 0 0x80000000>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8011-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-
kontron-n8011-s.dts
new file mode 100644
index 000000000000..5c44bd77ed32
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8011-s.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+
+#include "imx8mm-kontron-n8011-som.dtsi"
+#include "imx8mm-kontron-n801x-s.dtsi"
+
+/ {
+ model = "Kontron i.MX8MM N8011 S";
+ compatible = "kontron,imx8mm-n8011-s", "kontron,imx8mm-n8011-som",
+ "fsl,imx8mm";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8011-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8011-som.dtsi
new file mode 100644
index 000000000000..303594867b8f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n8011-som.dtsi
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Kontron Electronics GmbH
+ */
+
+#include "imx8mm-kontron-n801x-som.dtsi"
+
+/ {
+ model = "Kontron i.MX8MM N8011 SoM";
+ compatible = "kontron,imx8mm-n8011-som", "fsl,imx8mm";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x0 0x40000000 0 0xC0000000>;
+ };
Isn't the boot loader supposed to filling that in?
Hm, probably yes. I thought it would be good to have the upstream DT
fully describe the modules, including the memory size. But if it is more
common or useful, I will fill in the memory size for the smallest
configuration (1GB) only and let U-Boot overwrite the value if it
detects modules with larger DDR.
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dtsi
new file mode 100644
index 000000000000..d825e52e0beb
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dtsi
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Kontron Electronics GmbH
+ */
+
+/ {
+ aliases {
+ ethernet1 = &usbnet;
+ };
+
+ /* fixed crystal dedicated to mcp2515 */
+ clk16m: clk16m {
I believe a more human readable variant e.g. as follows is preferred:
osc_16m: clock-osc-16m
Ok.
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
Also the use of the optional property clock-output-names is recommended.
Ok.
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_led>;
+
+ led1 {
+ label = "led1";
+ gpios = <&gpio4 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led2 {
+ label = "led2";
+ gpios = <&gpio4 19 GPIO_ACTIVE_LOW>;
+ };
+
+ led3 {
+ label = "led3";
+ gpios = <&gpio4 18 GPIO_ACTIVE_LOW>;
+ };
+
+ led4 {
+ label = "led4";
+ gpios = <&gpio4 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led5 {
+ label = "led5";
+ gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led6 {
+ label = "led6";
+ gpios = <&gpio4 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ pwm-beeper {
+ compatible = "pwm-beeper";
+ pwms = <&pwm2 0 5000 0>;
+ };
+
+ reg_rst_eth2: regulator-rst-eth2 {
+ compatible = "regulator-fixed";
+ regulator-name = "rst-usb-eth2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_eth2>;
+ gpio = <&gpio3 2 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ };
+
+ vdd_5v: regulator-5v {
I would stick to consistent reg_ pre-fixing.
Ok.
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ status = "okay";
+ };
+};
+
+&ecspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ can0: can@0 {
+ compatible = "microchip,mcp2515";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can>;
+ clocks = <&clk16m>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <100000>;
+ vdd-supply = <&vdd_3v3>;
+ xceiver-supply = <&vdd_5v>;
+ status = "okay";
I find the property ordering a little confusing but that might just be me.
I think it's "compatible", "reg" and "pinctrl" first, then the other
properties in alphabetical order and "status" last. So I'm not really
sure what to improve here.
+ };
+};
+
+&ecspi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ userspi: userspi@0 {
+ compatible = "kontron,user-spi";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+ status = "okay";
+ };
I thought from earlier discussions you intended to drop that and either specify it from user-space directly or
use an overlay instead.
Yes, indeed, but when I learned about the possibility to override the
device's driver from userspace, I already had sent out this patch. I
will remove the userspi node in the next version.
Thanks so far for reviewing!
Frieder
