[PATCH 1/7] dt-bindings: add cdtech vendor prefix

[PATCH 1/7] dt-bindings: add cdtech vendor prefix

[Giulio Benetti]

This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 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

[PATCH 1/7] dt-bindings: add cdtech vendor prefix

[Giulio Benetti]

This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 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

[PATCH 2/7] drm/panel: add panel CDTech S070_WV95_CT16 to panel-simple

[Giulio Benetti]

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 .../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

[PATCH 2/7] drm/panel: add panel CDTech S070_WV95_CT16 to panel-simple

[Giulio Benetti]

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 .../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

[PATCH 2/7] drm/panel: add panel CDTech S070_WV95_CT16 to panel-simple

[Giulio Benetti]

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 .../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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/7] drm/panel: add panel CDTech S070_WV95_CT16 to panel-simple

[Rob Herring]

On Wed, Mar 21, 2018 at 09:03:08PM +0100, Giulio Benetti wrote:
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
>  .../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

[PATCH 2/7] drm/panel: add panel CDTech S070_WV95_CT16 to panel-simple

[Rob Herring]

On Wed, Mar 21, 2018 at 09:03:08PM +0100, Giulio Benetti wrote:
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
>  .../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

[PATCH 3/7] drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple

[Giulio Benetti]

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 .../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

[PATCH 3/7] drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple

[Giulio Benetti]

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 .../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

[PATCH 3/7] drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple

[Giulio Benetti]

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 .../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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/7] drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple

[Rob Herring]

On Wed, Mar 21, 2018 at 09:03:09PM +0100, Giulio Benetti wrote:
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
>  .../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

[PATCH 3/7] drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple

[Rob Herring]

On Wed, Mar 21, 2018 at 09:03:09PM +0100, Giulio Benetti wrote:
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
>  .../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

[PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Giulio Benetti]

The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
for the needed pins.

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 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

[PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Giulio Benetti]

The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
for the needed pins.

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 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 at 1c20c00 {
-- 
2.7.4

[PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Giulio Benetti]

The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
for the needed pins.

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

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 <giulio.benetti@micronovasrl.com>
> ---
>  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/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Paul Kocialkowski]

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 <giulio.benetti@micronovasrl.com>
> ---
>  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 at 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 at 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180325/54c13b55/attachment-0001.sig>

Re: [PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Paul Kocialkowski]

[-- Attachment #1.1: Type: text/plain, Size: 1552 bytes --]

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 <giulio.benetti@micronovasrl.com>
> ---
>  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/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

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 <giulio.benetti@micronovasrl.com>
> > ---
> >  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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Maxime Ripard]

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 <giulio.benetti@micronovasrl.com>
> > ---
> >  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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180326/ea41503e/attachment.sig>

Re: [PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1419 bytes --]

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 <giulio.benetti@micronovasrl.com>
> > ---
> >  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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
>>> ---
>>>   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

[PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
>>> ---
>>>   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 at 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

Re: [PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

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 <giulio.benetti@micronovasrl.com>
> > > > ---
> > > >   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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Maxime Ripard]

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 <giulio.benetti@micronovasrl.com>
> > > > ---
> > > >   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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180326/163e9c0e/attachment-0001.sig>

Re: [PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 2048 bytes --]

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 <giulio.benetti@micronovasrl.com>
> > > > ---
> > > >   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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] dt-bindings: add micronova vendor prefix

[Giulio Benetti]

This adds a vendor prefix "micronova" for Micronova srl

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 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

[PATCH 5/7] dt-bindings: add micronova vendor prefix

[Giulio Benetti]

This adds a vendor prefix "micronova" for Micronova srl

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 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

[PATCH 5/7] dt-bindings: add micronova vendor prefix

[Giulio Benetti]

This adds a vendor prefix "micronova" for Micronova srl

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] dt-bindings: add micronova vendor prefix

[Rob Herring]

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 <giulio.benetti@micronovasrl.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring <robh@kernel.org>

[PATCH 5/7] dt-bindings: add micronova vendor prefix

[Rob Herring]

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 <giulio.benetti@micronovasrl.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring <robh@kernel.org>

[PATCH 6/7] ARM: dts: sun7i: Add dts file for the A20-linova1-4_3 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
---
 .../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 <hdegoede@redhat.com>
+ * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
+ * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
+ *
+ * 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 = <&reg_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 = <&reg_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";
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
+&reg_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 = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_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

[PATCH 6/7] ARM: dts: sun7i: Add dts file for the A20-linova1-4_3 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
---
 .../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 <hdegoede@redhat.com>
+ * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
+ * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
+ *
+ * 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 = <&reg_vcc3v3>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			panel_input: endpoint at 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 at 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 at 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 = <&reg_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";
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
+&reg_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 = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_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 at 0 {
+		reg = <0>;
+		remote-endpoint = <&panel_input>;
+	};
+};
-- 
2.7.4

[PATCH 6/7] ARM: dts: sun7i: Add dts file for the A20-linova1-4_3 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
---
 .../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 <hdegoede@redhat.com>
+ * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
+ * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
+ *
+ * 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 = <&reg_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 = <&reg_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";
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
+&reg_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 = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7] ARM: dts: sun7i: Add dts file for the A20-linova1-4_3 HMI

[Rob Herring]

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 <giulio.benetti@micronovasrl.com>
> ---
>  .../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 <hdegoede@redhat.com>
> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
> + *
> + * 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 = <&reg_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>;
> +			};
> +		};
> +	};
> +};

[PATCH 6/7] ARM: dts: sun7i: Add dts file for the A20-linova1-4_3 HMI

[Rob Herring]

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 <giulio.benetti@micronovasrl.com>
> ---
>  .../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 <hdegoede@redhat.com>
> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
> + *
> + * 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 = <&reg_vcc3v3>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port at 0 {
> +			reg = <0>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			panel_input: endpoint at 0 {
> +				reg = <0>;

reg is not needed if there is only one child.

> +				remote-endpoint = <&tcon0_out_panel>;
> +			};
> +		};
> +	};
> +};

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
---
 .../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 <hdegoede@redhat.com>
+ * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
+ * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
+ *
+ * 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 = <&reg_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 = <&reg_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";
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
+&reg_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 = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_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

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
---
 .../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 <hdegoede@redhat.com>
+ * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
+ * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
+ *
+ * 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 = <&reg_vcc3v3>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			panel_input: endpoint at 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 at 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 at 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 = <&reg_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";
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
+&reg_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 = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_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 at 0 {
+		reg = <0>;
+		remote-endpoint = <&panel_input>;
+	};
+};
-- 
2.7.4

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
---
 .../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 <hdegoede@redhat.com>
+ * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
+ * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
+ *
+ * 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 = <&reg_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 = <&reg_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";
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
+&reg_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 = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 8496 bytes --]

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 <giulio.benetti@micronovasrl.com>
> ---
>  .../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 <hdegoede@redhat.com>
> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
> + *
> + * 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 = <&reg_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 = <&reg_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";
> +};
> +
> +&reg_usb0_vbus {
> +	status = "okay";
> +};
> +
> +&reg_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 = <&reg_usb0_vbus>;
> +	usb1_vbus-supply = <&reg_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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

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 <giulio.benetti@micronovasrl.com>
> ---
>  .../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 <hdegoede@redhat.com>
> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
> + *
> + * 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 = <&reg_vcc3v3>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port at 0 {
> +			reg = <0>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			panel_input: endpoint at 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 at 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 at 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 = <&reg_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";
> +};
> +
> +&reg_usb0_vbus {
> +	status = "okay";
> +};
> +
> +&reg_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 = <&reg_usb0_vbus>;
> +	usb1_vbus-supply = <&reg_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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180322/b3e82fe8/attachment.sig>

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
>> ---
>>   .../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 <hdegoede@redhat.com>
>> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
>> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
>> + *
>> + * 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 = <&reg_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 = <&reg_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";
>> +};
>> +
>> +&reg_usb0_vbus {
>> +	status = "okay";
>> +};
>> +
>> +&reg_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 = <&reg_usb0_vbus>;
>> +	usb1_vbus-supply = <&reg_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
> 

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
>> ---
>>   .../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 <hdegoede@redhat.com>
>> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
>> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
>> + *
>> + * 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 = <&reg_vcc3v3>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		port at 0 {
>> +			reg = <0>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			panel_input: endpoint at 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 at 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 at 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 = <&reg_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";
>> +};
>> +
>> +&reg_usb0_vbus {
>> +	status = "okay";
>> +};
>> +
>> +&reg_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 = <&reg_usb0_vbus>;
>> +	usb1_vbus-supply = <&reg_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
> 

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
>> ---
>>   .../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 <hdegoede@redhat.com>
>> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com>
>> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com>
>> + *
>> + * 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 = <&reg_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 = <&reg_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";
>> +};
>> +
>> +&reg_usb0_vbus {
>> +	status = "okay";
>> +};
>> +
>> +&reg_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 = <&reg_usb0_vbus>;
>> +	usb1_vbus-supply = <&reg_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
> 


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180424/3f76ff09/attachment.sig>

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 2507 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

[-- Attachment #1: Type: text/html, Size: 6480 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
> 

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
> 

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
> 



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

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

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

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

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
> 

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
> 

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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 at 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 at 0/__overlay__/ft5x: Relying on default #address-cells value
arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size): 
/fragment at 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

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

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 at 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 at 0/__overlay__/ft5x: Relying on default #address-cells value
> arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
> /fragment at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180504/149226f9/attachment.sig>

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 3793 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Sergey Suloev]

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

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Sergey Suloev]

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

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2867 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180507/73b6662a/attachment.sig>

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 2867 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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

[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

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

Re: [PATCH 1/7] dt-bindings: add cdtech vendor prefix

[Rob Herring]

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 <giulio.benetti@micronovasrl.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

In any case,

Reviewed-by: Rob Herring <robh@kernel.org>

[PATCH 1/7] dt-bindings: add cdtech vendor prefix

[Rob Herring]

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 <giulio.benetti@micronovasrl.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

In any case,

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH 1/7] dt-bindings: add cdtech vendor prefix

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
>> ---
>>   Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>   1 file changed, 1 insertion(+)
> 
> In any case,
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 1/7] dt-bindings: add cdtech vendor prefix

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
>> ---
>>   Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>   1 file changed, 1 insertion(+)
> 
> In any case,
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/7] dt-bindings: add cdtech vendor prefix

[Giulio Benetti]

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 <giulio.benetti@micronovasrl.com>
>> ---
>>   Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>   1 file changed, 1 insertion(+)
> 
> In any case,
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel