This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited
Signed-off-by: Giulio Benetti <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ae850d6..9854399 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -61,6 +61,7 @@ capella Capella Microsystems, Inc
cascoda Cascoda, Ltd.
cavium Cavium, Inc.
cdns Cadence Design Systems Inc.
+cdtech CDTech(H.K.) Electronics Limited
ceva Ceva, Inc.
chipidea Chipidea, Inc
chipone ChipOne
--
2.7.4
The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
Signed-off-by: Giulio Benetti <[email protected]>
---
.../devicetree/bindings/arm/micronova.txt | 4 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +++++++++++++++++++++
3 files changed, 197 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt
index 35c4127..9f5ac72 100644
--- a/Documentation/devicetree/bindings/arm/micronova.txt
+++ b/Documentation/devicetree/bindings/arm/micronova.txt
@@ -4,3 +4,7 @@ Micronova Device Tree Bindings
A20-LiNova1-4_3 HMI
Required root node properties:
- compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
+
+A20-LiNova1-7 HMI
+Required root node properties:
+ - compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c45a4f25..eafa7cb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
sun7i-a20-linova1-ctp-4_3i.dtb\
+ sun7i-a20-linova1-ctp-7i.dtb\
sun7i-a20-olimex-som-evb.dtb \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
new file mode 100644
index 0000000..7fd0d98
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
@@ -0,0 +1,192 @@
+/*
+ * This is based on sun7i-a20-linova1-ctp-7i.dts
+ *
+ * Copyright 2014 - Hans de Goede <[email protected]>
+ * Copyright (c) 2014 FUKAUMI Naoki <[email protected]>
+ * Copyright (c) 2018 Giulio Benetti <[email protected]>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ model = "Micronova srl LiNova1 CTP 7i";
+ compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ panel: panel {
+ compatible = "cdtech,s070wv95-ct16", "simple-panel";
+ power-supply = <®_vcc3v3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_panel>;
+ };
+ };
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+
+ ft5x: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
+ reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_usb0_vbus {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ status = "okay";
+};
+
+&be0 {
+ status = "okay";
+};
+
+&de {
+ status = "okay";
+};
+
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb888_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
--
2.7.4
Signed-off-by: Giulio Benetti <[email protected]>
---
.../display/panel/cdtech,s043wq26h-ct7.txt | 7 ++++++
drivers/gpu/drm/panel/panel-simple.c | 28 ++++++++++++++++++++++
2 files changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
diff --git a/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt b/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
new file mode 100644
index 0000000..a22af85
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
@@ -0,0 +1,7 @@
+CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
+
+Required properties:
+- compatible: should be "cdtech,s043wq26h-ct7"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 714fbdd..5e0c6d9 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -764,6 +764,31 @@ static const struct panel_desc boe_nv101wxmn51 = {
},
};
+static const struct drm_display_mode cdtech_s043wq26h_ct7_mode = {
+ .clock = 9000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 5,
+ .hsync_end = 480 + 5 + 5,
+ .htotal = 480 + 5 + 5 + 40,
+ .vdisplay = 272,
+ .vsync_start = 272 + 8,
+ .vsync_end = 272 + 8 + 8,
+ .vtotal = 272 + 8 + 8 + 8,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc cdtech_s043wq26h_ct7 = {
+ .modes = &cdtech_s043wq26h_ct7_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 95,
+ .height = 54,
+ },
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
static const struct drm_display_mode cdtech_s070wv95_ct16_mode = {
.clock = 35000,
.hdisplay = 800,
@@ -2091,6 +2116,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
}, {
+ .compatible = "cdtech,s043wq26h-ct7",
+ .data = &cdtech_s043wq26h_ct7,
+ }, {
.compatible = "cdtech,s070wv95-ct16",
.data = &cdtech_s070wv95_ct16,
}, {
--
2.7.4
The A20-Linova1-4_3 HMI, also called Q027_2_A which is printed on
production label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 4.3" 24-bits Tft 480x272 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
Signed-off-by: Giulio Benetti <[email protected]>
---
.../devicetree/bindings/arm/micronova.txt | 6 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts | 192 +++++++++++++++++++++
3 files changed, 199 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/micronova.txt
create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt
new file mode 100644
index 0000000..35c4127
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/micronova.txt
@@ -0,0 +1,6 @@
+Micronova Device Tree Bindings
+---------------------------
+
+A20-LiNova1-4_3 HMI
+Required root node properties:
+ - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ade7a38..c45a4f25 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -941,6 +941,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-lamobo-r1.dtb \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
+ sun7i-a20-linova1-ctp-4_3i.dtb\
sun7i-a20-olimex-som-evb.dtb \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
new file mode 100644
index 0000000..cd4ac73
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
@@ -0,0 +1,192 @@
+/*
+ * This is based on sun7i-a20-linova1-ctp-4_3i.dts
+ *
+ * Copyright 2014 - Hans de Goede <[email protected]>
+ * Copyright (c) 2014 FUKAUMI Naoki <[email protected]>
+ * Copyright (c) 2018 Giulio Benetti <[email protected]>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ model = "Micronova srl LiNova1 CTP 4.3i";
+ compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ panel: panel {
+ compatible = "cdtech,s043wq26h-ct7", "simple-panel";
+ power-supply = <®_vcc3v3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_panel>;
+ };
+ };
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+
+ ft5x: touchscreen@38 {
+ compatible = "edt,edt-ft5306";
+ reg = <0x38>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
+ reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <272>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_usb0_vbus {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ status = "okay";
+};
+
+&be0 {
+ status = "okay";
+};
+
+&de {
+ status = "okay";
+};
+
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb888_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
--
2.7.4
This adds a vendor prefix "micronova" for Micronova srl
Signed-off-by: Giulio Benetti <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 9854399..b07d1fc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -217,6 +217,7 @@ micrel Micrel Inc.
microchip Microchip Technology Inc.
microcrystal Micro Crystal AG
micron Micron Technology Inc.
+micronova Micronova srl
minix MINIX Technology Ltd.
miramems MiraMEMS Sensing Technology Co., Ltd.
mitsubishi Mitsubishi Electric Corporation
--
2.7.4
The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
for the needed pins.
Signed-off-by: Giulio Benetti <[email protected]>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index efb5607..bfe6728 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -922,6 +922,14 @@
pins = "PI20", "PI21";
function = "uart7";
};
+
+ lcd0_rgb888_pins: lcd0-rgb888-pins {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+ "PD8", "PD9", "PD10", "PD11", "PD12", "PD13", "PD14", "PD15",
+ "PD16", "PD17", "PD18", "PD19", "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ function = "lcd0";
+ };
};
timer@1c20c00 {
--
2.7.4
Signed-off-by: Giulio Benetti <[email protected]>
---
.../display/panel/cdtech,s070wv95-ct16.txt | 7 ++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
diff --git a/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt b/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
new file mode 100644
index 0000000..b00d6c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
@@ -0,0 +1,7 @@
+CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
+
+Required properties:
+- compatible: should be "cdtech,s070wv95-ct16"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 5591984..714fbdd 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -764,6 +764,30 @@ static const struct panel_desc boe_nv101wxmn51 = {
},
};
+static const struct drm_display_mode cdtech_s070wv95_ct16_mode = {
+ .clock = 35000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 40,
+ .hsync_end = 800 + 40 + 40,
+ .htotal = 800 + 40 + 40 + 48,
+ .vdisplay = 480,
+ .vsync_start = 480 + 29,
+ .vsync_end = 480 + 29 + 13,
+ .vtotal = 480 + 29 + 13 + 3,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc cdtech_s070wv95_ct16 = {
+ .modes = &cdtech_s070wv95_ct16_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 85,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -2067,6 +2091,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
}, {
+ .compatible = "cdtech,s070wv95-ct16",
+ .data = &cdtech_s070wv95_ct16,
+ }, {
.compatible = "chunghwa,claa070wp03xg",
.data = &chunghwa_claa070wp03xg,
}, {
--
2.7.4
On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
> The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
> label, is an industrial Human Machine Interface.
> It features:
> - 512MB DDR RAM
> - 1 Sd-card >= 4GB
> - 1 Usb otg(programmable via software) with A-Usb Connector
> - 1 Usb host
> - 1 Buzzer
> - 1 Input for LiPo
> - 1 Relay to signal absence of power supply
> - 1 External Rtc with 56 bytes of ram + CR2032 battery
> - 1 7" 24-bits Tft 800x480 with PCap on
> - 1 Mono audio 1-watt amplifier
> - 1 RS485 port
> - 1 Power On Line through +12Vdc reaching 57.600baud,
> from where it can be supplied and placed in a network of 50 units
> - exposed jtag pins
>
> HMI is supplied from +12Vdc.
> Ethernet is absent, so for debugging, need to enable rndis on Usb otg
> port through an A-A usb cable.
> It comes in different flavours for connector types and can be found with
> umounted features as requested by customers.
So this is essentially the same board than in patch 6, but with a
different screen?
You should have a single DT then, and handle the two different panels
using DT overlays.
> Signed-off-by: Giulio Benetti <[email protected]>
> ---
> .../devicetree/bindings/arm/micronova.txt | 4 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +++++++++++++++++++++
> 3 files changed, 197 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt
> index 35c4127..9f5ac72 100644
> --- a/Documentation/devicetree/bindings/arm/micronova.txt
> +++ b/Documentation/devicetree/bindings/arm/micronova.txt
> @@ -4,3 +4,7 @@ Micronova Device Tree Bindings
> A20-LiNova1-4_3 HMI
> Required root node properties:
> - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
> +
> +A20-LiNova1-7 HMI
> +Required root node properties:
> + - compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";
These bindings are unnecessary, but the panel-simple bindings should
be sent to the DT maintainers as well.
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c45a4f25..eafa7cb 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> sun7i-a20-m3.dtb \
> sun7i-a20-mk808c.dtb \
> sun7i-a20-linova1-ctp-4_3i.dtb\
> + sun7i-a20-linova1-ctp-7i.dtb\
You should have a space after dtb, and it should be ordered
alphabetically.
> sun7i-a20-olimex-som-evb.dtb \
> sun7i-a20-olinuxino-lime.dtb \
> sun7i-a20-olinuxino-lime2.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
> new file mode 100644
> index 0000000..7fd0d98
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
> @@ -0,0 +1,192 @@
> +/*
> + * This is based on sun7i-a20-linova1-ctp-7i.dts
> + *
> + * Copyright 2014 - Hans de Goede <[email protected]>
> + * Copyright (c) 2014 FUKAUMI Naoki <[email protected]>
> + * Copyright (c) 2018 Giulio Benetti <[email protected]>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
You should use an SPDX license header here.
> +
> +/dts-v1/;
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> + model = "Micronova srl LiNova1 CTP 7i";
> + compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + panel: panel {
> + compatible = "cdtech,s070wv95-ct16", "simple-panel";
> + power-supply = <®_vcc3v3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel_input: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_out_panel>;
> + };
> + };
> + };
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins_a>;
> + status = "okay";
> +
> + axp209: pmic@34 {
> + compatible = "x-powers,axp209";
> + reg = <0x34>;
> + interrupt-parent = <&nmi_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pins_a>;
> + status = "okay";
> +
> + ft5x: touchscreen@38 {
> + compatible = "edt,edt-ft5206";
> + reg = <0x38>;
> + interrupt-parent = <&pio>;
> + interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
> + reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + };
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> + cd-inverted;
> + status = "okay";
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&otg_sram {
> + status = "okay";
> +};
> +
> +®_usb0_vbus {
> + status = "okay";
> +};
> +
> +®_usb1_vbus {
> + status = "okay";
> +};
Ideally you should be defining the regulators here too.
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins_a>;
> + status = "okay";
> +};
> +
> +&usb_otg {
> + dr_mode = "otg";
You're saying that this is a USB-A connector? Then it's not OTG since
it doesn't have an ID pin, this is an host.
> + status = "okay";
> +};
> +
> +&usbphy {
> + pinctrl-names = "default";
> + usb0_vbus-supply = <®_usb0_vbus>;
> + usb1_vbus-supply = <®_usb1_vbus>;
> + status = "okay";
> +};
> +
> +&be0 {
> + status = "okay";
> +};
> +
> +&de {
> + status = "okay";
> +};
The nodes should be ordered by alphabetical order.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi,
Le mercredi 21 mars 2018 à 21:03 +0100, Giulio Benetti a écrit :
> The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
> for the needed pins.
>
> Signed-off-by: Giulio Benetti <[email protected]>
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index efb5607..bfe6728 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -922,6 +922,14 @@
> pins = "PI20", "PI21";
> function = "uart7";
> };
> +
> + lcd0_rgb888_pins: lcd0-rgb888-pins {
It would be more consistent with other pins definitions to have
underscores in both names and to indicate the index, such as:
lcd0_rgb888_pins: lcd0_rgb888_pins@0 {
This way, other set of pins for LCD (PH0-PH27) can be declared as @1
when they are needed in the future.
> + pins = "PD0", "PD1", "PD2", "PD3",
> "PD4", "PD5", "PD6", "PD7",
> + "PD8", "PD9", "PD10", "PD11",
> "PD12", "PD13", "PD14", "PD15",
> + "PD16", "PD17", "PD18",
> "PD19", "PD20", "PD21", "PD22", "PD23",
> + "PD24", "PD25", "PD26",
> "PD27";
> + function = "lcd0";
> + };
> };
>
> timer@1c20c00 {
--
Paul Kocialkowski,
developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Hi,
On Sun, Mar 25, 2018 at 04:09:13PM +0200, Paul Kocialkowski wrote:
> Le mercredi 21 mars 2018 ? 21:03 +0100, Giulio Benetti a ?crit :
> > The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
> > for the needed pins.
> >
> > Signed-off-by: Giulio Benetti <[email protected]>
> > ---
> > arch/arm/boot/dts/sun7i-a20.dtsi | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> > b/arch/arm/boot/dts/sun7i-a20.dtsi
> > index efb5607..bfe6728 100644
> > --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> > +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> > @@ -922,6 +922,14 @@
> > pins = "PI20", "PI21";
> > function = "uart7";
> > };
> > +
> > + lcd0_rgb888_pins: lcd0-rgb888-pins {
>
> It would be more consistent with other pins definitions to have
> underscores in both names and to indicate the index, such as:
> lcd0_rgb888_pins: lcd0_rgb888_pins@0 {
Both your suggestions will generate DTC warnings, and we'd like to get
rid of them eventually :)
> This way, other set of pins for LCD (PH0-PH27) can be declared as @1
> when they are needed in the future.
A better idea would be to call it lcd0-rgb888-pd-pins, and introduce
the ph variant when it's done.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi,
Il 26/03/2018 12:01, Maxime Ripard ha scritto:
> Hi,
>
> On Sun, Mar 25, 2018 at 04:09:13PM +0200, Paul Kocialkowski wrote:
>> Le mercredi 21 mars 2018 ? 21:03 +0100, Giulio Benetti a ?crit :
>>> The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
>>> for the needed pins.
>>>
>>> Signed-off-by: Giulio Benetti <[email protected]>
>>> ---
>>> arch/arm/boot/dts/sun7i-a20.dtsi | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
>>> b/arch/arm/boot/dts/sun7i-a20.dtsi
>>> index efb5607..bfe6728 100644
>>> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
>>> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
>>> @@ -922,6 +922,14 @@
>>> pins = "PI20", "PI21";
>>> function = "uart7";
>>> };
>>> +
>>> + lcd0_rgb888_pins: lcd0-rgb888-pins {
>>
>> It would be more consistent with other pins definitions to have
>> underscores in both names and to indicate the index, such as:
>> lcd0_rgb888_pins: lcd0_rgb888_pins@0 {
>
> Both your suggestions will generate DTC warnings, and we'd like to get
> rid of them eventually :)
>
>> This way, other set of pins for LCD (PH0-PH27) can be declared as @1
>> when they are needed in the future.
>
> A better idea would be to call it lcd0-rgb888-pd-pins, and introduce
> the ph variant when it's done.
As I know, only PD is muxed with LCD0.
And PH is for LCD1 only.
And LCD0 seems to come out only from PD port according to datasheet,
this is why I didn't put @0 after lcd0-rgb888-pins.
So I don't think it makes sense to handle pins in the way Paul suggests.
What do you all think?
Giulio
>
> Maxime
>
>
>
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
On Mon, Mar 26, 2018 at 01:27:05PM +0200, Giulio Benetti wrote:
> Hi,
>
> Il 26/03/2018 12:01, Maxime Ripard ha scritto:
> > Hi,
> >
> > On Sun, Mar 25, 2018 at 04:09:13PM +0200, Paul Kocialkowski wrote:
> > > Le mercredi 21 mars 2018 ? 21:03 +0100, Giulio Benetti a ?crit :
> > > > The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
> > > > for the needed pins.
> > > >
> > > > Signed-off-by: Giulio Benetti <[email protected]>
> > > > ---
> > > > arch/arm/boot/dts/sun7i-a20.dtsi | 8 ++++++++
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> > > > b/arch/arm/boot/dts/sun7i-a20.dtsi
> > > > index efb5607..bfe6728 100644
> > > > --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> > > > +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> > > > @@ -922,6 +922,14 @@
> > > > pins = "PI20", "PI21";
> > > > function = "uart7";
> > > > };
> > > > +
> > > > + lcd0_rgb888_pins: lcd0-rgb888-pins {
> > >
> > > It would be more consistent with other pins definitions to have
> > > underscores in both names and to indicate the index, such as:
> > > lcd0_rgb888_pins: lcd0_rgb888_pins@0 {
> >
> > Both your suggestions will generate DTC warnings, and we'd like to get
> > rid of them eventually :)
> >
> > > This way, other set of pins for LCD (PH0-PH27) can be declared as @1
> > > when they are needed in the future.
> >
> > A better idea would be to call it lcd0-rgb888-pd-pins, and introduce
> > the ph variant when it's done.
>
> As I know, only PD is muxed with LCD0.
> And PH is for LCD1 only.
>
> And LCD0 seems to come out only from PD port according to datasheet,
> this is why I didn't put @0 after lcd0-rgb888-pins.
>
> So I don't think it makes sense to handle pins in the way Paul suggests.
>
> What do you all think?
y
That seems sensible in this case, yes.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
On Wed, Mar 21, 2018 at 09:03:11PM +0100, Giulio Benetti wrote:
> This adds a vendor prefix "micronova" for Micronova srl
>
> Signed-off-by: Giulio Benetti <[email protected]>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring <[email protected]>
On Wed, Mar 21, 2018 at 09:03:09PM +0100, Giulio Benetti wrote:
> Signed-off-by: Giulio Benetti <[email protected]>
> ---
> .../display/panel/cdtech,s043wq26h-ct7.txt | 7 ++++++
> drivers/gpu/drm/panel/panel-simple.c | 28 ++++++++++++++++++++++
> 2 files changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt b/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
> new file mode 100644
> index 0000000..a22af85
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
> @@ -0,0 +1,7 @@
> +CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "cdtech,s043wq26h-ct7"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
Same comment here.
Also, please split bindings to separate patches.
Rob
On Wed, Mar 21, 2018 at 09:03:12PM +0100, Giulio Benetti wrote:
> The A20-Linova1-4_3 HMI, also called Q027_2_A which is printed on
> production label, is an industrial Human Machine Interface.
> It features:
> - 512MB DDR RAM
> - 1 Sd-card >= 4GB
> - 1 Usb otg(programmable via software) with A-Usb Connector
> - 1 Usb host
> - 1 Buzzer
> - 1 Input for LiPo
> - 1 Relay to signal absence of power supply
> - 1 External Rtc with 56 bytes of ram + CR2032 battery
> - 1 4.3" 24-bits Tft 480x272 with PCap on
> - 1 Mono audio 1-watt amplifier
> - 1 RS485 port
> - 1 Power On Line through +12Vdc reaching 57.600baud,
> from where it can be supplied and placed in a network of 50 units
> - exposed jtag pins
>
> HMI is supplied from +12Vdc.
> Ethernet is absent, so for debugging, need to enable rndis on Usb otg
> port through an A-A usb cable.
> It comes in different flavours for connector types and can be found with
> umounted features as requested by customers.
>
> Signed-off-by: Giulio Benetti <[email protected]>
> ---
> .../devicetree/bindings/arm/micronova.txt | 6 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts | 192 +++++++++++++++++++++
> 3 files changed, 199 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/micronova.txt
> create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt
> new file mode 100644
> index 0000000..35c4127
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/micronova.txt
> @@ -0,0 +1,6 @@
> +Micronova Device Tree Bindings
> +---------------------------
> +
> +A20-LiNova1-4_3 HMI
> +Required root node properties:
> + - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
I'd prefer that board compatibles are documented where the SoC
compatibles are documented, but it seems mostly allwinner platforms have
not done this.
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ade7a38..c45a4f25 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -941,6 +941,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> sun7i-a20-lamobo-r1.dtb \
> sun7i-a20-m3.dtb \
> sun7i-a20-mk808c.dtb \
> + sun7i-a20-linova1-ctp-4_3i.dtb\
> sun7i-a20-olimex-som-evb.dtb \
> sun7i-a20-olinuxino-lime.dtb \
> sun7i-a20-olinuxino-lime2.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
> new file mode 100644
> index 0000000..cd4ac73
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
> @@ -0,0 +1,192 @@
> +/*
> + * This is based on sun7i-a20-linova1-ctp-4_3i.dts
> + *
> + * Copyright 2014 - Hans de Goede <[email protected]>
> + * Copyright (c) 2014 FUKAUMI Naoki <[email protected]>
> + * Copyright (c) 2018 Giulio Benetti <[email protected]>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
Use SPDX tag instead of license text. checkpatch.pl will now tell you
this.
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> + model = "Micronova srl LiNova1 CTP 4.3i";
> + compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + panel: panel {
> + compatible = "cdtech,s043wq26h-ct7", "simple-panel";
> + power-supply = <®_vcc3v3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel_input: endpoint@0 {
> + reg = <0>;
reg is not needed if there is only one child.
> + remote-endpoint = <&tcon0_out_panel>;
> + };
> + };
> + };
> +};
On Wed, Mar 21, 2018 at 09:03:08PM +0100, Giulio Benetti wrote:
> Signed-off-by: Giulio Benetti <[email protected]>
> ---
> .../display/panel/cdtech,s070wv95-ct16.txt | 7 ++++++
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt b/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
> new file mode 100644
> index 0000000..b00d6c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
> @@ -0,0 +1,7 @@
> +CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "cdtech,s070wv95-ct16"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
Please be specific as to what properties apply. In particular, are you
not describing the power supply and it has multiple supplies or the
panel has a single supply?
Rob
On Wed, Mar 21, 2018 at 09:03:07PM +0100, Giulio Benetti wrote:
> This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited
Would be good to have website and/or info about what this company does.
>
> Signed-off-by: Giulio Benetti <[email protected]>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
In any case,
Reviewed-by: Rob Herring <[email protected]>
Hi,
Il 27/03/2018 00:24, Rob Herring ha scritto:
> On Wed, Mar 21, 2018 at 09:03:07PM +0100, Giulio Benetti wrote:
>> This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited
>
> Would be good to have website and/or info about what this company does.
Do you mean to have it in commit log?
I ask you because I can resubmit this patch with the others since I have
to do v2 patchset.
Thanks
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
>
>>
>> Signed-off-by: Giulio Benetti <[email protected]>
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>
> In any case,
>
> Reviewed-by: Rob Herring <[email protected]>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi,
Il 22/03/2018 19:05, Maxime Ripard ha scritto:
> On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
>> The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
>> label, is an industrial Human Machine Interface.
>> It features:
>> - 512MB DDR RAM
>> - 1 Sd-card >= 4GB
>> - 1 Usb otg(programmable via software) with A-Usb Connector
>> - 1 Usb host
>> - 1 Buzzer
>> - 1 Input for LiPo
>> - 1 Relay to signal absence of power supply
>> - 1 External Rtc with 56 bytes of ram + CR2032 battery
>> - 1 7" 24-bits Tft 800x480 with PCap on
>> - 1 Mono audio 1-watt amplifier
>> - 1 RS485 port
>> - 1 Power On Line through +12Vdc reaching 57.600baud,
>> from where it can be supplied and placed in a network of 50 units
>> - exposed jtag pins
>>
>> HMI is supplied from +12Vdc.
>> Ethernet is absent, so for debugging, need to enable rndis on Usb otg
>> port through an A-A usb cable.
>> It comes in different flavours for connector types and can be found with
>> umounted features as requested by customers.
>
> So this is essentially the same board than in patch 6, but with a
> different screen?
>
> You should have a single DT then, and handle the two different panels
> using DT overlays.
Ok for having different DT overlays.
But do I have to submit them as patches? Or keep them in my company's repo?
I ask you this because this involves sending also patches for displays
and other little modifications to mainline ex:
- rgb888 pins
- 2 simple-panels
- 1 uart iomux pins
etc.
If I don't submit those overlays, the other patches wouldn't make sense
alone as I've seen, just like rgb888 pins.
>
>> Signed-off-by: Giulio Benetti <[email protected]>
>> ---
>> .../devicetree/bindings/arm/micronova.txt | 4 +
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +++++++++++++++++++++
>> 3 files changed, 197 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt
>> index 35c4127..9f5ac72 100644
>> --- a/Documentation/devicetree/bindings/arm/micronova.txt
>> +++ b/Documentation/devicetree/bindings/arm/micronova.txt
>> @@ -4,3 +4,7 @@ Micronova Device Tree Bindings
>> A20-LiNova1-4_3 HMI
>> Required root node properties:
>> - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
>> +
>> +A20-LiNova1-7 HMI
>> +Required root node properties:
>> + - compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";
>
> These bindings are unnecessary, but the panel-simple bindings should
> be sent to the DT maintainers as well.
Ok, removed them and already sent the ones for display.
>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index c45a4f25..eafa7cb 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-m3.dtb \
>> sun7i-a20-mk808c.dtb \
>> sun7i-a20-linova1-ctp-4_3i.dtb\
>> + sun7i-a20-linova1-ctp-7i.dtb\
>
> You should have a space after dtb, and it should be ordered
> alphabetically.
Done.
>
>> sun7i-a20-olimex-som-evb.dtb \
>> sun7i-a20-olinuxino-lime.dtb \
>> sun7i-a20-olinuxino-lime2.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
>> new file mode 100644
>> index 0000000..7fd0d98
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
>> @@ -0,0 +1,192 @@
>> +/*
>> + * This is based on sun7i-a20-linova1-ctp-7i.dts
>> + *
>> + * Copyright 2014 - Hans de Goede <[email protected]>
>> + * Copyright (c) 2014 FUKAUMI Naoki <[email protected]>
>> + * Copyright (c) 2018 Giulio Benetti <[email protected]>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>
> You should use an SPDX license header here.
Done
>
>> +
>> +/dts-v1/;
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +
>> +/ {
>> + model = "Micronova srl LiNova1 CTP 7i";
>> + compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + panel: panel {
>> + compatible = "cdtech,s070wv95-ct16", "simple-panel";
>> + power-supply = <®_vcc3v3>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + panel_input: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint = <&tcon0_out_panel>;
>> + };
>> + };
>> + };
>> +};
>> +
>> +&ehci0 {
>> + status = "okay";
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&i2c0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c0_pins_a>;
>> + status = "okay";
>> +
>> + axp209: pmic@34 {
>> + compatible = "x-powers,axp209";
>> + reg = <0x34>;
>> + interrupt-parent = <&nmi_intc>;
>> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> + };
>> +};
>> +
>> +&i2c2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c2_pins_a>;
>> + status = "okay";
>> +
>> + ft5x: touchscreen@38 {
>> + compatible = "edt,edt-ft5206";
>> + reg = <0x38>;
>> + interrupt-parent = <&pio>;
>> + interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
>> + reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */
>> + touchscreen-size-x = <800>;
>> + touchscreen-size-y = <480>;
>> + };
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
>> + cd-inverted;
>> + status = "okay";
>> +};
>> +
>> +&ohci0 {
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&otg_sram {
>> + status = "okay";
>> +};
>> +
>> +®_usb0_vbus {
>> + status = "okay";
>> +};
>> +
>> +®_usb1_vbus {
>> + status = "okay";
>> +};
>
> Ideally you should be defining the regulators here too.
Added.
>
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_pins_a>;
>> + status = "okay";
>> +};
>> +
>> +&usb_otg {
>> + dr_mode = "otg";
>
> You're saying that this is a USB-A connector? Then it's not OTG since
> it doesn't have an ID pin, this is an host.
Right, with a special overlay I will activate Usb Device for RNDIS,
so modified as host
>
>> + status = "okay";
>> +};
>> +
>> +&usbphy {
>> + pinctrl-names = "default";
>> + usb0_vbus-supply = <®_usb0_vbus>;
>> + usb1_vbus-supply = <®_usb1_vbus>;
>> + status = "okay";
>> +};
>> +
>> +&be0 {
>> + status = "okay";
>> +};
>> +
>> +&de {
>> + status = "okay";
>> +};
>
> The nodes should be ordered by alphabetical order.
Done.
One last question:
now I have some patch already reviewed-by.
Do I have to re-submit entire patchset?
Thank you very much.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
>
> Thanks!
> Maxime
>
Hi,
On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote:
> Il 22/03/2018 19:05, Maxime Ripard ha scritto:
> > On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
> > > The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
> > > label, is an industrial Human Machine Interface.
> > > It features:
> > > - 512MB DDR RAM
> > > - 1 Sd-card >= 4GB
> > > - 1 Usb otg(programmable via software) with A-Usb Connector
> > > - 1 Usb host
> > > - 1 Buzzer
> > > - 1 Input for LiPo
> > > - 1 Relay to signal absence of power supply
> > > - 1 External Rtc with 56 bytes of ram + CR2032 battery
> > > - 1 7" 24-bits Tft 800x480 with PCap on
> > > - 1 Mono audio 1-watt amplifier
> > > - 1 RS485 port
> > > - 1 Power On Line through +12Vdc reaching 57.600baud,
> > > from where it can be supplied and placed in a network of 50 units
> > > - exposed jtag pins
> > >
> > > HMI is supplied from +12Vdc.
> > > Ethernet is absent, so for debugging, need to enable rndis on Usb otg
> > > port through an A-A usb cable.
> > > It comes in different flavours for connector types and can be found with
> > > umounted features as requested by customers.
> >
> > So this is essentially the same board than in patch 6, but with a
> > different screen?
> >
> > You should have a single DT then, and handle the two different panels
> > using DT overlays.
>
> Ok for having different DT overlays.
> But do I have to submit them as patches? Or keep them in my company's repo?
> I ask you this because this involves sending also patches for displays
> and other little modifications to mainline ex:
> - rgb888 pins
> - 2 simple-panels
> - 1 uart iomux pins
> etc.
>
> If I don't submit those overlays, the other patches wouldn't make sense
> alone as I've seen, just like rgb888 pins.
We don't have a repo for overlays yet
> > > +&usb_otg {
> > > + dr_mode = "otg";
> >
> > You're saying that this is a USB-A connector? Then it's not OTG since
> > it doesn't have an ID pin, this is an host.
>
> Right, with a special overlay I will activate Usb Device for RNDIS,
> so modified as host
That doesn't really make much sense. The USB OTG is wired only using a
daughter board?
> One last question:
> now I have some patch already reviewed-by.
> Do I have to re-submit entire patchset?
Yes
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Maxime and all,
I resend the e-mail since it was refused by some address(my phone
composed it in HTML). Sorry.
Il 24/04/2018 10:41, Maxime Ripard ha scritto:
> Hi,
>
> On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote:
>> Il 22/03/2018 19:05, Maxime Ripard ha scritto:
>>> On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
>>>> The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
>>>> label, is an industrial Human Machine Interface.
>>>> It features:
>>>> - 512MB DDR RAM
>>>> - 1 Sd-card >= 4GB
>>>> - 1 Usb otg(programmable via software) with A-Usb Connector
>>>> - 1 Usb host
>>>> - 1 Buzzer
>>>> - 1 Input for LiPo
>>>> - 1 Relay to signal absence of power supply
>>>> - 1 External Rtc with 56 bytes of ram + CR2032 battery
>>>> - 1 7" 24-bits Tft 800x480 with PCap on
>>>> - 1 Mono audio 1-watt amplifier
>>>> - 1 RS485 port
>>>> - 1 Power On Line through +12Vdc reaching 57.600baud,
>>>> from where it can be supplied and placed in a network of 50 units
>>>> - exposed jtag pins
>>>>
>>>> HMI is supplied from +12Vdc.
>>>> Ethernet is absent, so for debugging, need to enable rndis on Usb otg
>>>> port through an A-A usb cable.
>>>> It comes in different flavours for connector types and can be found with
>>>> umounted features as requested by customers.
>>>
>>> So this is essentially the same board than in patch 6, but with a
>>> different screen?
>>>
>>> You should have a single DT then, and handle the two different panels
>>> using DT overlays.
>>
>> Ok for having different DT overlays.
>> But do I have to submit them as patches? Or keep them in my company's repo?
>> I ask you this because this involves sending also patches for displays
>> and other little modifications to mainline ex:
>> - rgb888 pins
>> - 2 simple-panels
>> - 1 uart iomux pins
>> etc.
>>
>> If I don't submit those overlays, the other patches wouldn't make sense
>> alone as I've seen, just like rgb888 pins.
>
> We don't have a repo for overlays yet
Ok I can provide them on my company Repo.
But, sorry if insist(please don't kill me! :) ), I would try to explain
better how it's made LiNova, because I think I didn't provide enough
information about it:
LiNova1 is not a board with various headers to connect other peripherals
such display, pcap etc.
It's an HMI that I would consider the same as a Tablet, because it has a
plastic enclosure also.
So I would like to understand how to manage it in the best way.
Try to consider LiNova1 as a Tablet series, with following list:
LiNova1 4.3" ctp
LiNova1 7" ctp
LiNova1 10.1" ctp
LiNova1 4.3" rtp
LiNova1 7" rtp
LiNova1 10.1" rtp
Every of those has a slightly different BOM, so they are 6 different
boards with a common base(uP, ram). And same pcb.
So I don't know if submit only the common base and provide separately on
our github DT-overlays, or provide as many dts patches as the HMI number
with a base dtsi.
Basically Micronova provides entire system without the capability to
hack hardware adding shields of various type.
There are also other 2 LiNova:
LiNova2 and LiNova3
So I understand that this could lead to 18 different dts files and 3
dtsi files.
But with Tablet it should be the same way.
For sure people would be more interested on famous tablets instead of
our HMI.
In the case I need to use dt-overlays, you mean .dto files with
fragments inside loaded by u-boot or runtime, right?
Sorry if I bother you again but I wanted to understand better.
>
>>>> +&usb_otg {
>>>> + dr_mode = "otg";
>>>
>>> You're saying that this is a USB-A connector? Then it's not OTG since
>>> it doesn't have an ID pin, this is an host.
>>
>> Right, with a special overlay I will activate Usb Device for RNDIS,
>> so modified as host
>
> That doesn't really make much sense. The USB OTG is wired only using a
> daughter board?
My fault, I've meant "peripheral" in one case and "host" in another case.
Usually "host".
Are there problem with this?
There is no daughter board.
Thank you very very much in advance for you patience :)
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
>
>
>> One last question:
>> now I have some patch already reviewed-by.
>> Do I have to re-submit entire patchset?
>
> Yes
>
> Maxime
>
Hi Giulio,
On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote:
> LiNova1 is not a board with various headers to connect other peripherals
> such display, pcap etc.
> It's an HMI that I would consider the same as a Tablet, because it has a
> plastic enclosure also.
>
> So I would like to understand how to manage it in the best way.
> Try to consider LiNova1 as a Tablet series, with following list:
> LiNova1 4.3" ctp
> LiNova1 7" ctp
> LiNova1 10.1" ctp
> LiNova1 4.3" rtp
> LiNova1 7" rtp
> LiNova1 10.1" rtp
>
> Every of those has a slightly different BOM, so they are 6 different
> boards with a common base(uP, ram). And same pcb.
So the LiNova1 is exactly the same in all these setups, the only
difference is that it has a connector that you connect a different
display / touchscreen to?
If so, that's definitely a case for device tree overlays.
> So I don't know if submit only the common base and provide
> separately on our github DT-overlays, or provide as many dts patches
> as the HMI number with a base dtsi.
That's really up to you, but the overlays will make this much simpler
to handle precisely because it will reduce the amount of combinations
you have.
You can even reduce it in your case to 5 of them, 3 for each panel and
2 for each touchscreen.
> Basically Micronova provides entire system without the capability to hack
> hardware adding shields of various type.
>
> There are also other 2 LiNova:
> LiNova2 and LiNova3
Which SoCs are these boards based on?
> So I understand that this could lead to 18 different dts files and 3
> dtsi files.
Yeah, I'd really like to keep this under control :)
> But with Tablet it should be the same way. For sure people would be
> more interested on famous tablets instead of our HMI.
>
> In the case I need to use dt-overlays, you mean .dto files with
> fragments inside loaded by u-boot or runtime, right?
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
> > > > > +&usb_otg {
> > > > > + dr_mode = "otg";
> > > >
> > > > You're saying that this is a USB-A connector? Then it's not OTG since
> > > > it doesn't have an ID pin, this is an host.
> > >
> > > Right, with a special overlay I will activate Usb Device for RNDIS,
> > > so modified as host
> >
> > That doesn't really make much sense. The USB OTG is wired only using a
> > daughter board?
>
> My fault, I've meant "peripheral" in one case and "host" in another case.
> Usually "host".
> Are there problem with this?
> There is no daughter board.
If you have an ID pin and the ability to control VBUS, then you don't
need to change the device tree, it's done automatically at runtime by
Linux.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Maxime,
Il 25/04/2018 20:40, Maxime Ripard ha scritto:
> Hi Giulio,
>
> On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote:
>> LiNova1 is not a board with various headers to connect other peripherals
>> such display, pcap etc.
>> It's an HMI that I would consider the same as a Tablet, because it has a
>> plastic enclosure also.
>>
>> So I would like to understand how to manage it in the best way.
>> Try to consider LiNova1 as a Tablet series, with following list:
>> LiNova1 4.3" ctp
>> LiNova1 7" ctp
>> LiNova1 10.1" ctp
>> LiNova1 4.3" rtp
>> LiNova1 7" rtp
>> LiNova1 10.1" rtp
>>
>> Every of those has a slightly different BOM, so they are 6 different
>> boards with a common base(uP, ram). And same pcb.
>
> So the LiNova1 is exactly the same in all these setups, the only
> difference is that it has a connector that you connect a different
> display / touchscreen to?
>
> If so, that's definitely a case for device tree overlays.
Yes it is that way. So I proceed with dt overlays.
>
>> So I don't know if submit only the common base and provide
>> separately on our github DT-overlays, or provide as many dts patches
>> as the HMI number with a base dtsi.
>
> That's really up to you, but the overlays will make this much simpler
> to handle precisely because it will reduce the amount of combinations
> you have.
>
> You can even reduce it in your case to 5 of them, 3 for each panel and
> 2 for each touchscreen.
Ah, that's right! Good idea, more "encapsulation".
>
>> Basically Micronova provides entire system without the capability to hack
>> hardware adding shields of various type.
>>
>> There are also other 2 LiNova:
>> LiNova2 and LiNova3
>
> Which SoCs are these boards based on?
A20 on all three. They are slightly between each other.
Some RS485 more, 1 USB more etc.
>
>> So I understand that this could lead to 18 different dts files and 3
>> dtsi files.
>
> Yeah, I'd really like to keep this under control :)
:)
>
>> But with Tablet it should be the same way. For sure people would be
>> more interested on famous tablets instead of our HMI.
>>
>> In the case I need to use dt-overlays, you mean .dto files with
>> fragments inside loaded by u-boot or runtime, right?
>
> You don't have to handcode the fragments anymore with the new syntax,
> and U-Boot makes it really trivial to use if you use the FIT image
> format to have multiple overlays bundled in the same image. You can
> choose to apply them dynamically, for example based on an EEPROM or
> some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
>
>>>>>> +&usb_otg {
>>>>>> + dr_mode = "otg";
>>>>>
>>>>> You're saying that this is a USB-A connector? Then it's not OTG since
>>>>> it doesn't have an ID pin, this is an host.
>>>>
>>>> Right, with a special overlay I will activate Usb Device for RNDIS,
>>>> so modified as host
>>>
>>> That doesn't really make much sense. The USB OTG is wired only using a
>>> daughter board?
>>
>> My fault, I've meant "peripheral" in one case and "host" in another case.
>> Usually "host".
>> Are there problem with this?
>> There is no daughter board.
>
> If you have an ID pin and the ability to control VBUS, then you don't
> need to change the device tree, it's done automatically at runtime by
> Linux.
Unfortanetely I don't have ID pin and a common mosfet to control VBUS.
"peripheral" mode should be used only in debug mode,
so right dt-overlay can be written to sd-card by ourself or some of our
customers.
Thank you very much for all clarifications!
Giulio.
>
> Maxime
>
Hi Maxime,
>> You don't have to handcode the fragments anymore with the new syntax,
>> and U-Boot makes it really trivial to use if you use the FIT image
>> format to have multiple overlays bundled in the same image. You can
>> choose to apply them dynamically, for example based on an EEPROM or
>> some other metric to see which combination you have.
>
> Ah, this is interesting. I'm going to experiment with that.
>
I'm struggling against this, I don't really know how to proceed,
except keeping monolithic dts files including other dtsi files.
About dt-overlays I've tried to look around lot of time,
but the only thing I've found is this:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
where they use .dtso tagging them as "/plugin/;"
and compile all .dtso found in dts folder.
Then they obtain .dtbo files that should be the dt-overlays we have
spoken about right?
What I can't understand is if there's a real standard at this time to
follow, because on renesas-driver they use their way to handle all .dtso
files, but on mainline there seems to be nothing about that.
So at the moment I'm trying to compile dts tagged as /plugin/;
but dtc gives me a lot of warnings.
dts:
"
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
&i2c2 {
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
ft5x {
compatible = "edt,edt-ft5306";
reg = <0x38>;
interrupt-parent = <&pio>;
interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */
touchscreen-size-x = <480>;
touchscreen-size-y = <272>;
};
};
"
Build output issuing make ARCH=arm CROSS_COMPILE=arm-linux- aaa.dtb (I
use aaa.dts as source):
"
arch/arm/boot/dts/aaa.dtb: Warning (reg_format):
/fragment@0/__overlay__/ft5x:reg: property has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/aaa.dtb: Warning (pci_device_bus_num): Failed
prerequisite 'reg_format'
arch/arm/boot/dts/aaa.dtb: Warning (simple_bus_reg): Failed prerequisite
'reg_format'
arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
/fragment@0/__overlay__/ft5x: Relying on default #address-cells value
arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
/fragment@0/__overlay__/ft5x: Relying on default #size-cells value
"
Then in uboot I'm trying to do as follows:
# fdt addr 0x43000000 (where dtb is)
# fdt resize 8192
# fdt apply 0x430c0000 (where dtbo is)
But it gives me "libfdt fdt_check_header(): FDT_ERR_BADMAGIC"
(I was expecting some error)
Is there anywhere a guide for this?
Is this what you've meant before?
Using FIT for my use is not the best, so I would like to have many
overlays in /boot folder and use different boot.scr depending on hardware.
Can you point me to somewhere or something?
I don't really know where to beat my head!
Thanks in advance.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
> > > You don't have to handcode the fragments anymore with the new syntax,
> > > and U-Boot makes it really trivial to use if you use the FIT image
> > > format to have multiple overlays bundled in the same image. You can
> > > choose to apply them dynamically, for example based on an EEPROM or
> > > some other metric to see which combination you have.
> >
> > Ah, this is interesting. I'm going to experiment with that.
> >
>
> I'm struggling against this, I don't really know how to proceed,
> except keeping monolithic dts files including other dtsi files.
>
> About dt-overlays I've tried to look around lot of time,
> but the only thing I've found is this:
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
>
> where they use .dtso tagging them as "/plugin/;"
> and compile all .dtso found in dts folder.
> Then they obtain .dtbo files that should be the dt-overlays we have spoken
> about right?
Yes. You don't have to do that though, you can just rely on dtc to
compile them, outside of the linux build system.
> What I can't understand is if there's a real standard at this time to
> follow, because on renesas-driver they use their way to handle all .dtso
> files, but on mainline there seems to be nothing about that.
I'm not sure what you mean here. It's just fragments of device tree,
that have to be compiled using dtc, that's it. You can use the Linux
build system infrastructure to do that, or you can build your own
simpler one. That's really up to you. See for example
https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
(even though the overlays themselves use the legacy syntax and
shouldn't really be used an examples)
> So at the moment I'm trying to compile dts tagged as /plugin/;
> but dtc gives me a lot of warnings.
>
> dts:
> "
> /dts-v1/;
> /plugin/;
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
>
> &i2c2 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c2_pins_a>;
> status = "okay";
>
> ft5x {
> compatible = "edt,edt-ft5306";
> reg = <0x38>;
> interrupt-parent = <&pio>;
> interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
> reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */
> touchscreen-size-x = <480>;
> touchscreen-size-y = <272>;
> };
> };
> "
>
> Build output issuing make ARCH=arm CROSS_COMPILE=arm-linux- aaa.dtb (I use
> aaa.dts as source):
> "
> arch/arm/boot/dts/aaa.dtb: Warning (reg_format):
> /fragment@0/__overlay__/ft5x:reg: property has invalid length (4 bytes)
> (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/aaa.dtb: Warning (pci_device_bus_num): Failed prerequisite
> 'reg_format'
> arch/arm/boot/dts/aaa.dtb: Warning (simple_bus_reg): Failed prerequisite
> 'reg_format'
> arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
> /fragment@0/__overlay__/ft5x: Relying on default #address-cells value
> arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
> /fragment@0/__overlay__/ft5x: Relying on default #size-cells value
> "
Yeah, your i2c node doesn't have the right address-cells and
size-cells properties value, like dtc is telling you.
> Then in uboot I'm trying to do as follows:
> # fdt addr 0x43000000 (where dtb is)
> # fdt resize 8192
> # fdt apply 0x430c0000 (where dtbo is)
> But it gives me "libfdt fdt_check_header(): FDT_ERR_BADMAGIC"
> (I was expecting some error)
It looks like your overlay hasn't been properly loaded.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Maxime!
Il 04/05/2018 10:06, Maxime Ripard ha scritto:
> Hi,
>
> On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
>>>> You don't have to handcode the fragments anymore with the new syntax,
>>>> and U-Boot makes it really trivial to use if you use the FIT image
>>>> format to have multiple overlays bundled in the same image. You can
>>>> choose to apply them dynamically, for example based on an EEPROM or
>>>> some other metric to see which combination you have.
>>>
>>> Ah, this is interesting. I'm going to experiment with that.
>>>
>>
>> I'm struggling against this, I don't really know how to proceed,
>> except keeping monolithic dts files including other dtsi files.
>>
>> About dt-overlays I've tried to look around lot of time,
>> but the only thing I've found is this:
>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
>>
>> where they use .dtso tagging them as "/plugin/;"
>> and compile all .dtso found in dts folder.
>> Then they obtain .dtbo files that should be the dt-overlays we have spoken
>> about right?
>
> Yes. You don't have to do that though, you can just rely on dtc to
> compile them, outside of the linux build system.
>
>> What I can't understand is if there's a real standard at this time to
>> follow, because on renesas-driver they use their way to handle all .dtso
>> files, but on mainline there seems to be nothing about that.
>
> I'm not sure what you mean here. It's just fragments of device tree,
> that have to be compiled using dtc, that's it. You can use the Linux
> build system infrastructure to do that, or you can build your own
> simpler one. That's really up to you. See for example
> https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
>
> (even though the overlays themselves use the legacy syntax and
> shouldn't really be used an examples)
Everything works now!
Thank you very much!
I've setted up a Repo on Github to give an example on how make it work
with no pain:
https://github.com/micronovasrl/linova-dtoverlays
At the moment it's a mess all around, but it's working and give an idea
on how to make it work. Though I'm going to clean it up well as a base
for linova dtoverlays.
Ah, btw, can you confirm me that base dts file must be compiled outside
kernel with:
dtc -@ ....
Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
Right?
Thank you a lot for your help and time again!
Best regards!
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Hi, Giulio,
On 05/05/2018 12:52 AM, Giulio Benetti wrote:
> Hi Maxime!
>
> Il 04/05/2018 10:06, Maxime Ripard ha scritto:
>> Hi,
>>
>> On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
>>>>> You don't have to handcode the fragments anymore with the new syntax,
>>>>> and U-Boot makes it really trivial to use if you use the FIT image
>>>>> format to have multiple overlays bundled in the same image. You can
>>>>> choose to apply them dynamically, for example based on an EEPROM or
>>>>> some other metric to see which combination you have.
>>>>
>>>> Ah, this is interesting. I'm going to experiment with that.
>>>>
>>>
>>> I'm struggling against this, I don't really know how to proceed,
>>> except keeping monolithic dts files including other dtsi files.
>>>
>>> About dt-overlays I've tried to look around lot of time,
>>> but the only thing I've found is this:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
>>>
>>>
>>> where they use .dtso tagging them as "/plugin/;"
>>> and compile all .dtso found in dts folder.
>>> Then they obtain .dtbo files that should be the dt-overlays we have
>>> spoken
>>> about right?
>>
>> Yes. You don't have to do that though, you can just rely on dtc to
>> compile them, outside of the linux build system.
>>
>>> What I can't understand is if there's a real standard at this time to
>>> follow, because on renesas-driver they use their way to handle all
>>> .dtso
>>> files, but on mainline there seems to be nothing about that.
>>
>> I'm not sure what you mean here. It's just fragments of device tree,
>> that have to be compiled using dtc, that's it. You can use the Linux
>> build system infrastructure to do that, or you can build your own
>> simpler one. That's really up to you. See for example
>> https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
>>
>> (even though the overlays themselves use the legacy syntax and
>> shouldn't really be used an examples)
>
> Everything works now!
> Thank you very much!
> I've setted up a Repo on Github to give an example on how make it work
> with no pain:
> https://github.com/micronovasrl/linova-dtoverlays
>
> At the moment it's a mess all around, but it's working and give an
> idea on how to make it work. Though I'm going to clean it up well as a
> base for linova dtoverlays.
>
> Ah, btw, can you confirm me that base dts file must be compiled
> outside kernel with:
> dtc -@ ....
> Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
> Right?
>
> Thank you a lot for your help and time again!
>
> Best regards!
>
I'd highly recommend you to look at Armbian overlay support: it is easy
and elegant.
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-sunxi-overlays.patch
Sergey
Hi Sergey,
Il 04/05/2018 23:59, Sergey Suloev ha scritto:
> Hi, Giulio,
>
> On 05/05/2018 12:52 AM, Giulio Benetti wrote:
>> Hi Maxime!
>>
>> Il 04/05/2018 10:06, Maxime Ripard ha scritto:
>>> Hi,
>>>
>>> On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
>>>>>> You don't have to handcode the fragments anymore with the new syntax,
>>>>>> and U-Boot makes it really trivial to use if you use the FIT image
>>>>>> format to have multiple overlays bundled in the same image. You can
>>>>>> choose to apply them dynamically, for example based on an EEPROM or
>>>>>> some other metric to see which combination you have.
>>>>>
>>>>> Ah, this is interesting. I'm going to experiment with that.
>>>>>
>>>>
>>>> I'm struggling against this, I don't really know how to proceed,
>>>> except keeping monolithic dts files including other dtsi files.
>>>>
>>>> About dt-overlays I've tried to look around lot of time,
>>>> but the only thing I've found is this:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
>>>>
>>>>
>>>> where they use .dtso tagging them as "/plugin/;"
>>>> and compile all .dtso found in dts folder.
>>>> Then they obtain .dtbo files that should be the dt-overlays we have
>>>> spoken
>>>> about right?
>>>
>>> Yes. You don't have to do that though, you can just rely on dtc to
>>> compile them, outside of the linux build system.
>>>
>>>> What I can't understand is if there's a real standard at this time to
>>>> follow, because on renesas-driver they use their way to handle all
>>>> .dtso
>>>> files, but on mainline there seems to be nothing about that.
>>>
>>> I'm not sure what you mean here. It's just fragments of device tree,
>>> that have to be compiled using dtc, that's it. You can use the Linux
>>> build system infrastructure to do that, or you can build your own
>>> simpler one. That's really up to you. See for example
>>> https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
>>>
>>> (even though the overlays themselves use the legacy syntax and
>>> shouldn't really be used an examples)
>>
>> Everything works now!
>> Thank you very much!
>> I've setted up a Repo on Github to give an example on how make it work
>> with no pain:
>> https://github.com/micronovasrl/linova-dtoverlays
>>
>> At the moment it's a mess all around, but it's working and give an
>> idea on how to make it work. Though I'm going to clean it up well as a
>> base for linova dtoverlays.
>>
>> Ah, btw, can you confirm me that base dts file must be compiled
>> outside kernel with:
>> dtc -@ ....
>> Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
>> Right?
>>
>> Thank you a lot for your help and time again!
>>
>> Best regards!
>>
> I'd highly recommend you to look at Armbian overlay support: it is easy
> and elegant.
>
> https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch
>
>
> https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-sunxi-overlays.patch
Thanks for pointing me that,
but as we've discussed before, at the moment overlays are not going to
be included in Mainline Kernel(Maxime correct if I'm wrong).
Try to think maintaining thousands and thousands of overlays,
it would be a nightmare(IMHO).
Maybe it will change, I don't know.
Thanks anyway.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
On Fri, May 04, 2018 at 11:52:59PM +0200, Giulio Benetti wrote:
> Hi Maxime!
>
> Il 04/05/2018 10:06, Maxime Ripard ha scritto:
> > Hi,
> >
> > On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
> > > > > You don't have to handcode the fragments anymore with the new syntax,
> > > > > and U-Boot makes it really trivial to use if you use the FIT image
> > > > > format to have multiple overlays bundled in the same image. You can
> > > > > choose to apply them dynamically, for example based on an EEPROM or
> > > > > some other metric to see which combination you have.
> > > >
> > > > Ah, this is interesting. I'm going to experiment with that.
> > > >
> > >
> > > I'm struggling against this, I don't really know how to proceed,
> > > except keeping monolithic dts files including other dtsi files.
> > >
> > > About dt-overlays I've tried to look around lot of time,
> > > but the only thing I've found is this:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
> > >
> > > where they use .dtso tagging them as "/plugin/;"
> > > and compile all .dtso found in dts folder.
> > > Then they obtain .dtbo files that should be the dt-overlays we have spoken
> > > about right?
> >
> > Yes. You don't have to do that though, you can just rely on dtc to
> > compile them, outside of the linux build system.
> >
> > > What I can't understand is if there's a real standard at this time to
> > > follow, because on renesas-driver they use their way to handle all .dtso
> > > files, but on mainline there seems to be nothing about that.
> >
> > I'm not sure what you mean here. It's just fragments of device tree,
> > that have to be compiled using dtc, that's it. You can use the Linux
> > build system infrastructure to do that, or you can build your own
> > simpler one. That's really up to you. See for example
> > https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
> >
> > (even though the overlays themselves use the legacy syntax and
> > shouldn't really be used an examples)
>
> Everything works now!
> Thank you very much!
> I've setted up a Repo on Github to give an example on how make it work with
> no pain:
> https://github.com/micronovasrl/linova-dtoverlays
>
> At the moment it's a mess all around, but it's working and give an idea on
> how to make it work. Though I'm going to clean it up well as a base for
> linova dtoverlays.
>
> Ah, btw, can you confirm me that base dts file must be compiled outside
> kernel with:
> dtc -@ ....
> Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
> Right?
You should use DTC_FLAGS='-@'
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi,
Il 07/05/2018 09:30, Maxime Ripard ha scritto:
>> Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
>> Right?
>
> You should use DTC_FLAGS='-@'
Thank you, I'm going to use that.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642