[PATCH 2/2] drm/panel: panel-simple: add bus_format and connector_type to cdtech_s070wv95_ct16 panel

[Giulio Benetti]

Add bus_format and connector_type to cdtech_s070wv95_ct16 panel.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index c8ad713865cb..dc300ace4d68 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1295,6 +1295,8 @@ static const struct panel_desc cdtech_s070wv95_ct16 = {
.width = 154,
.height = 85,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .connector_type = DRM_MODE_CONNECTOR_DPI,
 };
 
 static const struct display_timing chefree_ch101olhlwh_002_timing = {
-- 
2.25.1

[PATCH 1/2] drm/panel: panel-simple: add bus_format and connector_type to cdtech_s043wq26h_ct7 panel

[Giulio Benetti]

Add bus_format and connector_type to cdtech_s043wq26h_ct7 panel.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index eb475a3a774b..c8ad713865cb 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1215,7 +1215,9 @@ static const struct panel_desc cdtech_s043wq26h_ct7 = {
.width = 95,
.height = 54,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
.bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+   .connector_type = DRM_MODE_CONNECTOR_DPI,
 };
 
 /* S070PWS19HP-FC21 2017/04/22 */
-- 
2.25.1

Re: [PATCH v3 0/9] Add 4 Jenson simple panels

[Giulio Benetti]

Hello All,

kindly pinging this patchset, I've forgotten to set it Unarchived, now 
it is:

https://patchwork.kernel.org/project/dri-devel/list/?series=459931

Best regards
--
Giulio Benetti
Benetti Engineering sas

On 5/2/21 10:50 PM, Giulio Benetti wrote:

Hello Thierry,

I've seen that this patchset [1] in DRI Patchwork has been archived, but
it's not been applied and all patches result as "New", so I've set them
as un-archived. Hope it's correct.

[1]:https://patchwork.kernel.org/project/dri-devel/list/?series=459931
[2]:https://patchwork.kernel.org/project/dri-devel/list/

Best regards
-- Giulio Benetti Benetti Engineering sas On 4/2/21 1:17 AM, Giulio 
Benetti wrote:

This patchset introduce Jenson vendor and add 4 of its panels to
panel-simple driver.

---
V2-V3:
* changed my SoB and authorship
* added some forgotten acked-by
* fixed alpha-numeric order on adding bindings
---

Giulio Benetti (9):
dt-bindings: Add Jenson Display vendor prefix
dt-bindings: display/panel: add Jenson JT60245-01
dt-bindings: display/panel: add Jenson JT60248-01
dt-bindings: display/panel: add Jenson JT60249-01
dt-bindings: display/panel: add Jenson JT60250-02
drm/panel: simple: add Jenson JT60245-01
drm/panel: simple: add Jenson JT60248-01
drm/panel: simple: add Jenson JT60249-01
drm/panel: simple: add Jenson JT60250-02

   .../bindings/display/panel/panel-simple.yaml  |   8 ++
   .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
   drivers/gpu/drm/panel/panel-simple.c  | 108 ++
   3 files changed, 118 insertions(+)

Re: [PATCH v3 0/9] Add 4 Jenson simple panels

[Giulio Benetti]

Hello Thierry,

I've seen that this patchset [1] in DRI Patchwork has been archived, but 
it's not been applied and all patches result as "New", so I've set them 
as un-archived. Hope it's correct.


[1]: https://patchwork.kernel.org/project/dri-devel/list/?series=459931
[2]: https://patchwork.kernel.org/project/dri-devel/list/

Best regards
--
Giulio Benetti
Benetti Engineering sas

On 4/2/21 1:17 AM, Giulio Benetti wrote:

This patchset introduce Jenson vendor and add 4 of its panels to
panel-simple driver.

---
V2-V3:
* changed my SoB and authorship
* added some forgotten acked-by
* fixed alpha-numeric order on adding bindings
---

Giulio Benetti (9):
   dt-bindings: Add Jenson Display vendor prefix
   dt-bindings: display/panel: add Jenson JT60245-01
   dt-bindings: display/panel: add Jenson JT60248-01
   dt-bindings: display/panel: add Jenson JT60249-01
   dt-bindings: display/panel: add Jenson JT60250-02
   drm/panel: simple: add Jenson JT60245-01
   drm/panel: simple: add Jenson JT60248-01
   drm/panel: simple: add Jenson JT60249-01
   drm/panel: simple: add Jenson JT60250-02

  .../bindings/display/panel/panel-simple.yaml  |   8 ++
  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
  drivers/gpu/drm/panel/panel-simple.c  | 108 ++
  3 files changed, 118 insertions(+)



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

[PATCH v3 9/9] drm/panel: simple: add Jenson JT60250-02

[Giulio Benetti]

This patch adds support for Jenson JT60250-02 1024x600 10.1" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 1966ace764c3..2ebfe529e0c7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2604,6 +2604,30 @@ static const struct panel_desc jenson_jt60249_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60250_02_mode = {
+   .clock = 51000,
+   .hdisplay = 1024,
+   .hsync_start = 1024 + 160,
+   .hsync_end = 1204 + 160 + 10,
+   .htotal = 1024 + 160 + 10 + 160,
+   .vdisplay = 600,
+   .vsync_start = 600 + 12,
+   .vsync_end = 600 + 12 + 70,
+   .vtotal = 600 + 12 + 70 + 23,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60250_02 = {
+   .modes = _jt60250_02_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 223,
+   .height = 125,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4382,6 +4406,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60249-01",
.data = _jt60249_01,
+   }, {
+   .compatible = "jenson,jt60250-02",
+   .data = _jt60250_02,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH v3 2/9] dt-bindings: display/panel: add Jenson JT60245-01

[Giulio Benetti]

Add DT binding for "jenson,jt60245-01".

Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 62b0d54d87b7..ce41a589a3f4 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -168,6 +168,8 @@ properties:
   - innolux,n156bge-l21
 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
   - innolux,zj070na-01p
+# Jenson Display JT60245-01 7" (800x480) TFT LCD panel
+  - jenson,jt60245-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH v3 1/9] dt-bindings: Add Jenson Display vendor prefix

[Giulio Benetti]

Update Documentation/devicetree/bindings/vendor-prefixes.yaml to
include "jenson" as a vendor prefix for "Jenson Display".
Company website: http://www.jensondisplay.com/

Signed-off-by: Giulio Benetti 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index f6064d84a424..a1312637d6ff 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -553,6 +553,8 @@ patternProperties:
 description: Japan Display Inc.
   "^jedec,.*":
 description: JEDEC Solid State Technology Association
+  "^jenson,.*":
+description: Jenson Display
   "^jesurun,.*":
 description: Shenzhen Jesurun Electronics Business Dept.
   "^jianda,.*":
-- 
2.25.1

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

[PATCH v3 5/9] dt-bindings: display/panel: add Jenson JT60250-02

[Giulio Benetti]

Add DT binding for "jenson,jt60250-02".

Signed-off-by: Giulio Benetti 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 68eaa353be0d..cd2f4421de7e 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -174,6 +174,8 @@ properties:
   - jenson,jt60248-01
 # Jenson Display JT60249-01 5" (800x480) TFT LCD panel
   - jenson,jt60249-01
+# Jenson Display JT60250-02 10.1" (1024x600) TFT LCD panel
+  - jenson,jt60250-02
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH v3 7/9] drm/panel: simple: add Jenson JT60248-01

[Giulio Benetti]

This patch adds support for Jenson JT60248-01 480x272 4.3" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f63fa75ae4ef..f96f820a890b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2556,6 +2556,30 @@ static const struct panel_desc jenson_jt60245_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60248_01_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 8,
+   .hsync_end = 480 + 8 + 4,
+   .htotal = 480 + 8 + 4 + 43,
+   .vdisplay = 272,
+   .vsync_start = 272 + 8,
+   .vsync_end = 272 + 8 + 4,
+   .vtotal = 272 + 8 + 4 + 12,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60248_01 = {
+   .modes = _jt60248_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 95,
+   .height = 54,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4328,6 +4352,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60245-01",
.data = _jt60245_01,
+   }, {
+   .compatible = "jenson,jt60248-01",
+   .data = _jt60248_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH v3 8/9] drm/panel: simple: add Jenson JT60249-01

[Giulio Benetti]

This patch adds support for Jenson JT60249-01 800x480 5" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f96f820a890b..1966ace764c3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2580,6 +2580,30 @@ static const struct panel_desc jenson_jt60248_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60249_01_mode = {
+   .clock = 25000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 8,
+   .hsync_end = 800 + 8 + 4,
+   .htotal = 800 + 8 + 4 + 8,
+   .vdisplay = 480,
+   .vsync_start = 480 + 8,
+   .vsync_end = 480 + 8 + 4,
+   .vtotal = 480 + 8 + 4 + 8,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60249_01 = {
+   .modes = _jt60249_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 108,
+   .height = 65,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4355,6 +4379,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60248-01",
.data = _jt60248_01,
+   }, {
+   .compatible = "jenson,jt60249-01",
+   .data = _jt60249_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH v3 0/9] Add 4 Jenson simple panels

[Giulio Benetti]

This patchset introduce Jenson vendor and add 4 of its panels to
panel-simple driver.

---
V2-V3:
* changed my SoB and authorship
* added some forgotten acked-by
* fixed alpha-numeric order on adding bindings
---

Giulio Benetti (9):
  dt-bindings: Add Jenson Display vendor prefix
  dt-bindings: display/panel: add Jenson JT60245-01
  dt-bindings: display/panel: add Jenson JT60248-01
  dt-bindings: display/panel: add Jenson JT60249-01
  dt-bindings: display/panel: add Jenson JT60250-02
  drm/panel: simple: add Jenson JT60245-01
  drm/panel: simple: add Jenson JT60248-01
  drm/panel: simple: add Jenson JT60249-01
  drm/panel: simple: add Jenson JT60250-02

 .../bindings/display/panel/panel-simple.yaml  |   8 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 drivers/gpu/drm/panel/panel-simple.c  | 108 ++
 3 files changed, 118 insertions(+)

-- 
2.25.1

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

[PATCH v3 6/9] drm/panel: simple: add Jenson JT60245-01

[Giulio Benetti]

This patch adds support for Jenson JT60245-01 800x480 7" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 4e2dad314c79..f63fa75ae4ef 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2532,6 +2532,30 @@ static const struct panel_desc ivo_m133nwf4_r0 = {
.connector_type = DRM_MODE_CONNECTOR_eDP,
 };
 
+static const struct drm_display_mode jenson_jt60245_01_mode = {
+   .clock = 35000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 210,
+   .hsync_end = 800 + 210 + 20,
+   .htotal = 800 + 210 + 20 + 46,
+   .vdisplay = 480,
+   .vsync_start = 480 + 22,
+   .vsync_end = 480 + 22 + 10,
+   .vtotal = 480 + 22 + 10 + 23,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60245_01 = {
+   .modes = _jt60245_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4301,6 +4325,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ivo,m133nwf4-r0",
.data = _m133nwf4_r0,
+   }, {
+   .compatible = "jenson,jt60245-01",
+   .data = _jt60245_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH v3 3/9] dt-bindings: display/panel: add Jenson JT60248-01

[Giulio Benetti]

Add DT binding for "jenson,jt60248-01".

Signed-off-by: Giulio Benetti 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index ce41a589a3f4..35c335aa085e 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -170,6 +170,8 @@ properties:
   - innolux,zj070na-01p
 # Jenson Display JT60245-01 7" (800x480) TFT LCD panel
   - jenson,jt60245-01
+# Jenson Display JT60248-01 4,3" (480x272) TFT LCD panel
+  - jenson,jt60248-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH v3 4/9] dt-bindings: display/panel: add Jenson JT60249-01

[Giulio Benetti]

Add DT binding for "jenson,jt60249-01".

Signed-off-by: Giulio Benetti 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 35c335aa085e..68eaa353be0d 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -172,6 +172,8 @@ properties:
   - jenson,jt60245-01
 # Jenson Display JT60248-01 4,3" (480x272) TFT LCD panel
   - jenson,jt60248-01
+# Jenson Display JT60249-01 5" (800x480) TFT LCD panel
+  - jenson,jt60249-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

Re: [PATCH 4/9] dt-bindings: display/panel: add Jenson JT60245-01

[Giulio Benetti]

Hi Rob,

Il 05/03/2021 23:54, Rob Herring ha scritto:

On Thu, Feb 18, 2021 at 11:54:52PM +0100, Giulio Benetti wrote:

From: Giulio Benetti 

Add DT binding for "jenson,jt60245-01".

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 08afd6501094..fd0d2a573350 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -169,6 +169,8 @@ properties:
- jenson,jt60248-01
  # Jenson Display JT60249-01 5" (800x480) TFT LCD panel
- jenson,jt60249-01
+# Jenson Display JT60245-01 7" (800x480) TFT LCD panel
+  - jenson,jt60245-01


It was going so well. Alpha-numeric order please.


I've sent v2 patchset, but I didn't add your "Acked-by:" since
alphabetical order was wrong.

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


  # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
- kingdisplay,kd116n21-30nv-a010
  # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
--
2.25.1



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

[PATCH v2 0/9] Add 4 Jenson simple panels

[Giulio Benetti]

From: Giulio Benetti 

This patchset introduce Jenson vendor and add 4 of its panels to
panel-simple driver.

Giulio Benetti (9):
  dt-bindings: Add Jenson Display vendor prefix
  dt-bindings: display/panel: add Jenson JT60245-01
  dt-bindings: display/panel: add Jenson JT60248-01
  dt-bindings: display/panel: add Jenson JT60249-01
  dt-bindings: display/panel: add Jenson JT60250-02
  drm/panel: simple: add Jenson JT60245-01
  drm/panel: simple: add Jenson JT60248-01
  drm/panel: simple: add Jenson JT60249-01
  drm/panel: simple: add Jenson JT60250-02

 .../bindings/display/panel/panel-simple.yaml  |   8 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 drivers/gpu/drm/panel/panel-simple.c  | 108 ++
 3 files changed, 118 insertions(+)

-- 
2.25.1

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

[PATCH v2 9/9] drm/panel: simple: add Jenson JT60250-02

[Giulio Benetti]

From: Giulio Benetti 

This patch adds support for Jenson JT60250-02 1024x600 10.1" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 1966ace764c3..2ebfe529e0c7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2604,6 +2604,30 @@ static const struct panel_desc jenson_jt60249_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60250_02_mode = {
+   .clock = 51000,
+   .hdisplay = 1024,
+   .hsync_start = 1024 + 160,
+   .hsync_end = 1204 + 160 + 10,
+   .htotal = 1024 + 160 + 10 + 160,
+   .vdisplay = 600,
+   .vsync_start = 600 + 12,
+   .vsync_end = 600 + 12 + 70,
+   .vtotal = 600 + 12 + 70 + 23,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60250_02 = {
+   .modes = _jt60250_02_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 223,
+   .height = 125,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4382,6 +4406,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60249-01",
.data = _jt60249_01,
+   }, {
+   .compatible = "jenson,jt60250-02",
+   .data = _jt60250_02,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH v2 6/9] drm/panel: simple: add Jenson JT60245-01

[Giulio Benetti]

From: Giulio Benetti 

This patch adds support for Jenson JT60245-01 800x480 7" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 4e2dad314c79..f63fa75ae4ef 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2532,6 +2532,30 @@ static const struct panel_desc ivo_m133nwf4_r0 = {
.connector_type = DRM_MODE_CONNECTOR_eDP,
 };
 
+static const struct drm_display_mode jenson_jt60245_01_mode = {
+   .clock = 35000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 210,
+   .hsync_end = 800 + 210 + 20,
+   .htotal = 800 + 210 + 20 + 46,
+   .vdisplay = 480,
+   .vsync_start = 480 + 22,
+   .vsync_end = 480 + 22 + 10,
+   .vtotal = 480 + 22 + 10 + 23,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60245_01 = {
+   .modes = _jt60245_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4301,6 +4325,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ivo,m133nwf4-r0",
.data = _m133nwf4_r0,
+   }, {
+   .compatible = "jenson,jt60245-01",
+   .data = _jt60245_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH v2 3/9] dt-bindings: display/panel: add Jenson JT60248-01

[Giulio Benetti]

From: Giulio Benetti 

Add DT binding for "jenson,jt60248-01".

Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index ce41a589a3f4..35c335aa085e 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -170,6 +170,8 @@ properties:
   - innolux,zj070na-01p
 # Jenson Display JT60245-01 7" (800x480) TFT LCD panel
   - jenson,jt60245-01
+# Jenson Display JT60248-01 4,3" (480x272) TFT LCD panel
+  - jenson,jt60248-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH v2 8/9] drm/panel: simple: add Jenson JT60249-01

[Giulio Benetti]

From: Giulio Benetti 

This patch adds support for Jenson JT60249-01 800x480 5" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f96f820a890b..1966ace764c3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2580,6 +2580,30 @@ static const struct panel_desc jenson_jt60248_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60249_01_mode = {
+   .clock = 25000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 8,
+   .hsync_end = 800 + 8 + 4,
+   .htotal = 800 + 8 + 4 + 8,
+   .vdisplay = 480,
+   .vsync_start = 480 + 8,
+   .vsync_end = 480 + 8 + 4,
+   .vtotal = 480 + 8 + 4 + 8,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60249_01 = {
+   .modes = _jt60249_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 108,
+   .height = 65,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4355,6 +4379,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60248-01",
.data = _jt60248_01,
+   }, {
+   .compatible = "jenson,jt60249-01",
+   .data = _jt60249_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH v2 7/9] drm/panel: simple: add Jenson JT60248-01

[Giulio Benetti]

From: Giulio Benetti 

This patch adds support for Jenson JT60248-01 480x272 4.3" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f63fa75ae4ef..f96f820a890b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2556,6 +2556,30 @@ static const struct panel_desc jenson_jt60245_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60248_01_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 8,
+   .hsync_end = 480 + 8 + 4,
+   .htotal = 480 + 8 + 4 + 43,
+   .vdisplay = 272,
+   .vsync_start = 272 + 8,
+   .vsync_end = 272 + 8 + 4,
+   .vtotal = 272 + 8 + 4 + 12,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60248_01 = {
+   .modes = _jt60248_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 95,
+   .height = 54,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4328,6 +4352,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60245-01",
.data = _jt60245_01,
+   }, {
+   .compatible = "jenson,jt60248-01",
+   .data = _jt60248_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH v2 5/9] dt-bindings: display/panel: add Jenson JT60250-02

[Giulio Benetti]

From: Giulio Benetti 

Add DT binding for "jenson,jt60250-02".

Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 68eaa353be0d..cd2f4421de7e 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -174,6 +174,8 @@ properties:
   - jenson,jt60248-01
 # Jenson Display JT60249-01 5" (800x480) TFT LCD panel
   - jenson,jt60249-01
+# Jenson Display JT60250-02 10.1" (1024x600) TFT LCD panel
+  - jenson,jt60250-02
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH v2 4/9] dt-bindings: display/panel: add Jenson JT60249-01

[Giulio Benetti]

From: Giulio Benetti 

Add DT binding for "jenson,jt60249-01".

Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 35c335aa085e..68eaa353be0d 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -172,6 +172,8 @@ properties:
   - jenson,jt60245-01
 # Jenson Display JT60248-01 4,3" (480x272) TFT LCD panel
   - jenson,jt60248-01
+# Jenson Display JT60249-01 5" (800x480) TFT LCD panel
+  - jenson,jt60249-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH v2 2/9] dt-bindings: display/panel: add Jenson JT60245-01

[Giulio Benetti]

From: Giulio Benetti 

Add DT binding for "jenson,jt60245-01".

Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 62b0d54d87b7..ce41a589a3f4 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -168,6 +168,8 @@ properties:
   - innolux,n156bge-l21
 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
   - innolux,zj070na-01p
+# Jenson Display JT60245-01 7" (800x480) TFT LCD panel
+  - jenson,jt60245-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH v2 1/9] dt-bindings: Add Jenson Display vendor prefix

[Giulio Benetti]

From: Giulio Benetti 

Update Documentation/devicetree/bindings/vendor-prefixes.yaml to
include "jenson" as a vendor prefix for "Jenson Display".
Company website: http://www.jensondisplay.com/

Signed-off-by: Giulio Benetti 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index f6064d84a424..a1312637d6ff 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -553,6 +553,8 @@ patternProperties:
 description: Japan Display Inc.
   "^jedec,.*":
 description: JEDEC Solid State Technology Association
+  "^jenson,.*":
+description: Jenson Display
   "^jesurun,.*":
 description: Shenzhen Jesurun Electronics Business Dept.
   "^jianda,.*":
-- 
2.25.1

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

[PATCH 8/9] drm/panel: simple: add Jenson JT60249-01

[Giulio Benetti]

From: Giulio Benetti 

This patch adds support for Jenson JT60249-01 800x480 5" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f243087ce89b..995a581f8b2b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2444,6 +2444,30 @@ static const struct panel_desc jenson_jt60248_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60249_01_mode = {
+   .clock = 25000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 8,
+   .hsync_end = 800 + 8 + 4,
+   .htotal = 800 + 8 + 4 + 8,
+   .vdisplay = 480,
+   .vsync_start = 480 + 8,
+   .vsync_end = 480 + 8 + 4,
+   .vtotal = 480 + 8 + 4 + 8,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60249_01 = {
+   .modes = _jt60249_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 108,
+   .height = 65,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4216,6 +4240,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60248-01",
.data = _jt60248_01,
+   }, {
+   .compatible = "jenson,jt60249-01",
+   .data = _jt60249_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH 0/9] Add 4 Jenson simple panels

[Giulio Benetti]

This patchset introduce Jenson vendor and add 4 of its panels to
panel-simple driver.

Giulio Benetti (9):
  dt-bindings: Add Jenson Display vendor prefix
  dt-bindings: display/panel: add Jenson JT60248-01
  dt-bindings: display/panel: add Jenson JT60249-01
  dt-bindings: display/panel: add Jenson JT60245-01
  dt-bindings: display/panel: add Jenson JT60250-02
  drm/panel: simple: add Jenson JT60245-01
  drm/panel: simple: add Jenson JT60248-01
  drm/panel: simple: add Jenson JT60249-01
  drm/panel: simple: add Jenson JT60250-02

 .../bindings/display/panel/panel-simple.yaml  |   8 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 drivers/gpu/drm/panel/panel-simple.c  | 108 ++
 3 files changed, 118 insertions(+)

-- 
2.25.1

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

[PATCH 9/9] drm/panel: simple: add Jenson JT60250-02

[Giulio Benetti]

From: Giulio Benetti 

This patch adds support for Jenson JT60250-02 1024x600 10.1" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 995a581f8b2b..60805d7a12d7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2468,6 +2468,30 @@ static const struct panel_desc jenson_jt60249_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60250_02_mode = {
+   .clock = 51000,
+   .hdisplay = 1024,
+   .hsync_start = 1024 + 160,
+   .hsync_end = 1204 + 160 + 10,
+   .htotal = 1024 + 160 + 10 + 160,
+   .vdisplay = 600,
+   .vsync_start = 600 + 12,
+   .vsync_end = 600 + 12 + 70,
+   .vtotal = 600 + 12 + 70 + 23,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60250_02 = {
+   .modes = _jt60250_02_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 223,
+   .height = 125,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4243,6 +4267,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60249-01",
.data = _jt60249_01,
+   }, {
+   .compatible = "jenson,jt60250-02",
+   .data = _jt60250_02,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH 3/9] dt-bindings: display/panel: add Jenson JT60249-01

[Giulio Benetti]

From: Giulio Benetti 

Add DT binding for "jenson,jt60249-01".

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index d4359f09818a..08afd6501094 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -167,6 +167,8 @@ properties:
   - innolux,zj070na-01p
 # Jenson Display JT60248-01 4,3" (480x272) TFT LCD panel
   - jenson,jt60248-01
+# Jenson Display JT60249-01 5" (800x480) TFT LCD panel
+  - jenson,jt60249-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH 2/9] dt-bindings: display/panel: add Jenson JT60248-01

[Giulio Benetti]

From: Giulio Benetti 

Add DT binding for "jenson,jt60248-01".

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 27fffafe5b5c..d4359f09818a 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -165,6 +165,8 @@ properties:
   - innolux,n156bge-l21
 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
   - innolux,zj070na-01p
+# Jenson Display JT60248-01 4,3" (480x272) TFT LCD panel
+  - jenson,jt60248-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH 5/9] dt-bindings: display/panel: add Jenson JT60250-02

[Giulio Benetti]

From: Giulio Benetti 

Add DT binding for "jenson,jt60250-02".

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index fd0d2a573350..a3edf313be54 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -171,6 +171,8 @@ properties:
   - jenson,jt60249-01
 # Jenson Display JT60245-01 7" (800x480) TFT LCD panel
   - jenson,jt60245-01
+# Jenson Display JT60250-02 10.1" (1024x600) TFT LCD panel
+  - jenson,jt60250-02
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

[PATCH 7/9] drm/panel: simple: add Jenson JT60248-01

[Giulio Benetti]

From: Giulio Benetti 

This patch adds support for Jenson JT60248-01 480x272 4.3" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f268ad5f5345..f243087ce89b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2420,6 +2420,30 @@ static const struct panel_desc jenson_jt60245_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
 };
 
+static const struct drm_display_mode jenson_jt60248_01_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 8,
+   .hsync_end = 480 + 8 + 4,
+   .htotal = 480 + 8 + 4 + 43,
+   .vdisplay = 272,
+   .vsync_start = 272 + 8,
+   .vsync_end = 272 + 8 + 4,
+   .vtotal = 272 + 8 + 4 + 12,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60248_01 = {
+   .modes = _jt60248_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 95,
+   .height = 54,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4189,6 +4213,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60245-01",
.data = _jt60245_01,
+   }, {
+   .compatible = "jenson,jt60248-01",
+   .data = _jt60248_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH 6/9] drm/panel: simple: add Jenson JT60245-01

[Giulio Benetti]

From: Giulio Benetti 

This patch adds support for Jenson JT60245-01 800x480 7" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 41bbec72b2da..f268ad5f5345 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2396,6 +2396,30 @@ static const struct panel_desc ivo_m133nwf4_r0 = {
.connector_type = DRM_MODE_CONNECTOR_eDP,
 };
 
+static const struct drm_display_mode jenson_jt60245_01_mode = {
+   .clock = 35000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 210,
+   .hsync_end = 800 + 210 + 20,
+   .htotal = 800 + 210 + 20 + 46,
+   .vdisplay = 480,
+   .vsync_start = 480 + 22,
+   .vsync_end = 480 + 22 + 10,
+   .vtotal = 480 + 22 + 10 + 23,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60245_01 = {
+   .modes = _jt60245_01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+};
+
 static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4162,6 +4186,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ivo,m133nwf4-r0",
.data = _m133nwf4_r0,
+   }, {
+   .compatible = "jenson,jt60245-01",
+   .data = _jt60245_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = _kd116n21_30nv_a010,
-- 
2.25.1

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

[PATCH 1/9] dt-bindings: Add Jenson Display vendor prefix

[Giulio Benetti]

From: Giulio Benetti 

Update Documentation/devicetree/bindings/vendor-prefixes.yaml to
include "jenson" as a vendor prefix for "Jenson Display".
Company website: http://www.jensondisplay.com/

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 041ae90b0d8f..6fe66df86477 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -547,6 +547,8 @@ patternProperties:
 description: Japan Display Inc.
   "^jedec,.*":
 description: JEDEC Solid State Technology Association
+  "^jenson,.*":
+description: Jenson Display
   "^jesurun,.*":
 description: Shenzhen Jesurun Electronics Business Dept.
   "^jianda,.*":
-- 
2.25.1

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

[PATCH 4/9] dt-bindings: display/panel: add Jenson JT60245-01

[Giulio Benetti]

From: Giulio Benetti 

Add DT binding for "jenson,jt60245-01".

Signed-off-by: Giulio Benetti 
Signed-off-by: Giulio Benetti 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 08afd6501094..fd0d2a573350 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -169,6 +169,8 @@ properties:
   - jenson,jt60248-01
 # Jenson Display JT60249-01 5" (800x480) TFT LCD panel
   - jenson,jt60249-01
+# Jenson Display JT60245-01 7" (800x480) TFT LCD panel
+  - jenson,jt60245-01
 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
   - kingdisplay,kd116n21-30nv-a010
 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
-- 
2.25.1

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

Re: [PATCH v3] drm/sun4i: tcon: fix inverted DCLK polarity

[Giulio Benetti]

On 1/13/21 10:42 AM, Maxime Ripard wrote:

Hi,

On Mon, Jan 11, 2021 at 06:46:16PM +0100, Giulio Benetti wrote:

From: Giulio Benetti 

During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_POSITIVE as
bit 26 and activating according to bus_flags the same way it is done for
all the other signals polarity.

Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE 
flags")
Suggested-by: Maxime Ripard 
Signed-off-by: Giulio Benetti 
---
  drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
  drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
  2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..30171ccd87e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
  
-	/*

-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
-
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE;
  
  	regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,

   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |


You need to add SUN4I_TCON0_IO_POL_DCLK_POSITIVE to the mask you're
going to change here too


Ah, lost it during squash, I send a v4.

Thank you
Best regards
--
Giulio Benetti
Benetti Engineering sas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/sun4i: tcon: fix inverted DCLK polarity

[Giulio Benetti]

Hi Marjan,

On 1/14/21 8:58 AM, Marjan Pascolo wrote:

Hi Giulio,

You did a typo

Il 13/01/2021 17:05, Giulio Benetti ha scritto:

From: Giulio Benetti 

During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
as bit 26 and activating according to bus_flags the same way it is done
for all the other signals polarity.

Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE 
flags")
Suggested-by: Maxime Ripard 
Signed-off-by: Giulio Benetti 
---
V2->V3:
- squash 2 patches into 1
V3->V4:
- add SUN4I_TCON0_IO_POL_DCLK_POSITIVE to regmap_update_bits()
V4->V5:
polarity is still wrong so:
- let's use SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE macro
instead of _DCLK_POSITIVE(that would make sense only in realtion with DCLK)
- invert condition using _NEGEDGE instead of _POSEDGE and then matching with
register bit SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
- correct commit log according to V4->V5 changes
---
   drivers/gpu/drm/sun4i/sun4i_tcon.c | 21 ++---
   drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
   2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..c172ccfff7e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,30 +569,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
   
-	/*

-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
-
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   val |= SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE;
   
   	regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,

   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
   SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |

Here Below you missed an 'E'


yes, thank you, going to send v6.

Best regards
--
Giulio Benetti
Benetti Engineering sas


+  SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGDGE |
   SUN4I_TCON0_IO_POL_DE_NEGATIVE,
   val);
   
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h

index cfbf4e6c1679..c5ac1b02482c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
   #define SUN4I_TCON0_IO_POL_REG   0x88
   #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase) ((phase & 3) << 28)
   #define SUN4I_TCON0_IO_POL_DE_NEGATIVE   BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE  BIT(26)
   #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVEBIT(25)
   #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVEBIT(24)
   


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

[PATCH v6] drm/sun4i: tcon: fix inverted DCLK polarity

[Giulio Benetti]

From: Giulio Benetti 

During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
as bit 26 and activating according to bus_flags the same way it is done
for all the other signals polarity.

Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE 
flags")
Suggested-by: Maxime Ripard 
Signed-off-by: Giulio Benetti 
---
V2->V3:
- squash 2 patches into 1
V3->V4:
- add SUN4I_TCON0_IO_POL_DCLK_POSITIVE to regmap_update_bits() as suggested by 
Maxime
V4->V5:
polarity is still wrong so:
- let's use SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE macro
  instead of _DCLK_POSITIVE(that would make sense only in realtion with DCLK)
- invert condition using _NEGEDGE instead of _POSEDGE and then matching with
  register bit SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
- correct commit log according to V4->V5 changes
V5->V6:
- fix typo in SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE as suggested by Marjan
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 21 ++---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..6b9af4c08cd6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,30 +569,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
 
-   /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
-
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   val |= SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE;
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
   SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE |
   SUN4I_TCON0_IO_POL_DE_NEGATIVE,
   val);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..c5ac1b02482c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
 #define SUN4I_TCON0_IO_POL_REG 0x88
 #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase)   ((phase & 3) << 28)
 #define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE  BIT(26)
 #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE  BIT(25)
 #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE  BIT(24)
 
-- 
2.25.1

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

[PATCH v5] drm/sun4i: tcon: fix inverted DCLK polarity

[Giulio Benetti]

From: Giulio Benetti 

During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
as bit 26 and activating according to bus_flags the same way it is done
for all the other signals polarity.

Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE 
flags")
Suggested-by: Maxime Ripard 
Signed-off-by: Giulio Benetti 
---
V2->V3:
- squash 2 patches into 1
V3->V4:
- add SUN4I_TCON0_IO_POL_DCLK_POSITIVE to regmap_update_bits()
V4->V5:
polarity is still wrong so:
- let's use SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE macro
  instead of _DCLK_POSITIVE(that would make sense only in realtion with DCLK)
- invert condition using _NEGEDGE instead of _POSEDGE and then matching with
  register bit SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
- correct commit log according to V4->V5 changes
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 21 ++---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..c172ccfff7e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,30 +569,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
 
-   /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
-
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   val |= SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE;
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
   SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGDGE |
   SUN4I_TCON0_IO_POL_DE_NEGATIVE,
   val);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..c5ac1b02482c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
 #define SUN4I_TCON0_IO_POL_REG 0x88
 #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase)   ((phase & 3) << 28)
 #define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE  BIT(26)
 #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE  BIT(25)
 #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE  BIT(24)
 
-- 
2.25.1

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

[PATCH v4] drm/sun4i: tcon: fix inverted DCLK polarity

[Giulio Benetti]

From: Giulio Benetti 

During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_POSITIVE as
bit 26 and activating according to bus_flags the same way it is done for
all the other signals polarity.

Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE 
flags")
Suggested-by: Maxime Ripard 
Signed-off-by: Giulio Benetti 
---
V2->V3:
- squash 2 patches into 1
V3->V4:
- add SUN4I_TCON0_IO_POL_DCLK_POSITIVE to regmap_update_bits()
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 21 ++---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..6e454d316852 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,30 +569,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
 
-   /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
-
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE;
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
   SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_DCLK_POSITIVE |
   SUN4I_TCON0_IO_POL_DE_NEGATIVE,
   val);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..0ce71d10a31b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
 #define SUN4I_TCON0_IO_POL_REG 0x88
 #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase)   ((phase & 3) << 28)
 #define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_POSITIVE   BIT(26)
 #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE  BIT(25)
 #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE  BIT(24)
 
-- 
2.25.1

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

[PATCH v3] drm/sun4i: tcon: fix inverted DCLK polarity

[Giulio Benetti]

From: Giulio Benetti 

During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_POSITIVE as
bit 26 and activating according to bus_flags the same way it is done for
all the other signals polarity.

Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE 
flags")
Suggested-by: Maxime Ripard 
Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..30171ccd87e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
 
-   /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
-
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE;
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..0ce71d10a31b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
 #define SUN4I_TCON0_IO_POL_REG 0x88
 #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase)   ((phase & 3) << 28)
 #define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_POSITIVE   BIT(26)
 #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE  BIT(25)
 #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE  BIT(24)
 
-- 
2.25.1

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

Re: [PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling

[Giulio Benetti]

On 1/11/21 6:20 PM, Maxime Ripard wrote:

On Fri, Jan 08, 2021 at 03:34:52PM +0100, Giulio Benetti wrote:

Hi,

On 1/8/21 10:23 AM, Maxime Ripard wrote:

Hi,

Thanks for those patches

On Thu, Jan 07, 2021 at 03:30:32AM +0100, Giulio Benetti wrote:

From: Giulio Benetti 

It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is
dedicated to invert DCLK polarity and this makes thing really easier than
before. So let's handle DCLK polarity by adding
SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to
bus_flags the same way is done for all the other signals.

Cc: Maxime Ripard 


Suggested-by would be nice here :)


Ok, didn't know about this tag


Signed-off-by: Giulio Benetti 
---
   drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
   drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
   2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 52598bb0fb0b..30171ccd87e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
-   /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 0);
-
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 240);
+   val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE;


I'm not really sure why we need the first patch of this series here?


The idea was to have 2 for testing, 1st one is already applicable, while the
other must be tested, but I can send only one with no problem.


That patch only seem to undo what you did in patch 1


No, it doesn't, the 2nd one change the way it achieve the same thing,
because the 1st swap DCLK phase, while the 2nd uses the IO_POL bit to set IO
polarity according to bus_flags.


It makes sense for testing, but I'm not sure we want to carry it into
the history. Can you squash them both into the same patch?

Sure, I'm going to send V3 then.

Thank you
Best regards
--
Giulio Benetti
Benetti Engineering sas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling

[Giulio Benetti]

Hi,

On 1/8/21 10:23 AM, Maxime Ripard wrote:

Hi,

Thanks for those patches

On Thu, Jan 07, 2021 at 03:30:32AM +0100, Giulio Benetti wrote:

From: Giulio Benetti 

It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is
dedicated to invert DCLK polarity and this makes thing really easier than
before. So let's handle DCLK polarity by adding
SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to
bus_flags the same way is done for all the other signals.

Cc: Maxime Ripard 


Suggested-by would be nice here :)


Ok, didn't know about this tag


Signed-off-by: Giulio Benetti 
---
  drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
  drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
  2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 52598bb0fb0b..30171ccd87e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
  
-	/*

-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 0);
-
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 240);
+   val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE;


I'm not really sure why we need the first patch of this series here?


The idea was to have 2 for testing, 1st one is already applicable, while 
the other must be tested, but I can send only one with no problem.



That patch only seem to undo what you did in patch 1


No, it doesn't, the 2nd one change the way it achieve the same thing, 
because the 1st swap DCLK phase, while the 2nd uses the IO_POL bit to 
set IO polarity according to bus_flags.


Best Regards
--
Giulio Benetti
Benetti Engineering sas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling

[Giulio Benetti]

Hi Marjan,

On 1/8/21 10:32 AM, Marjan Pascolo wrote:

Hi,


please don't top post, answer in-line as we do, and please use 
plain-test instead of HTML. These are the standards in Mailing Lists(ML).



Quote "

I'm not really sure why we need the first patch of this series here?
That patch only seem to undo what you did in patch 1

"


Already answered to Maxime



And another question (probably could be a stupid one):

in "/[PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling/" I 
see you deleted:


-   clk_set_phase(tcon->dclk, 0);

Is safe to assume that phase register will be always set to 0?


We always assumed it is set to 0 by default.



Or maybe will be safer manually set it to 0 in every condition to avoid 
surprises (dirt values due to previous condition)?


That would be a good idea, so something like this:

'''
int phase = 0;

if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
phase = 240;

clk_set_phase(tcon->dclk, phase);
'''

because now DRM_BUS_FLAG_PIXDATA_SAMPLE_ and DRM_BUS_FLAG_PIXDATA_DRIVE_ 
are exclusive, while before not.


But then if bit 26 solution works everything gets easier.

Best Regards
Giulio



Marjan

Il 08/01/2021 10:23, Maxime Ripard ha scritto:

Hi,

Thanks for those patches

On Thu, Jan 07, 2021 at 03:30:32AM +0100, Giulio Benetti wrote:

From: Giulio Benetti

It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is
dedicated to invert DCLK polarity and this makes thing really easier than
before. So let's handle DCLK polarity by adding
SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to
bus_flags the same way is done for all the other signals.

Cc: Maxime Ripard

Suggested-by would be nice here :)


Signed-off-by: Giulio Benetti
---
  drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
  drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
  2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 52598bb0fb0b..30171ccd87e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
  
-	/*

-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 0);
-
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 240);
+   val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE;

I'm not really sure why we need the first patch of this series here?
That patch only seem to undo what you did in patch 1

Maxime

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

[PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling

[Giulio Benetti]

From: Giulio Benetti 

It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is
dedicated to invert DCLK polarity and this makes thing really easier than
before. So let's handle DCLK polarity by adding
SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to
bus_flags the same way is done for all the other signals.

Cc: Maxime Ripard 
Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 52598bb0fb0b..30171ccd87e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
 
-   /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 0);
-
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 240);
+   val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE;
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..0ce71d10a31b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
 #define SUN4I_TCON0_IO_POL_REG 0x88
 #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase)   ((phase & 3) << 28)
 #define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_POSITIVE   BIT(26)
 #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE  BIT(25)
 #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE  BIT(24)
 
-- 
2.25.1

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

[PATCH v2 0/2] drm/sun4i: fix DCLK and improve its handling

[Giulio Benetti]

From: Giulio Benetti 

First patch is a tested by me fix, while the second need testing to
understand if it works correctly with any sunxi SoC with DE peripheral.
Already tested SoCs are:
- A20
- A33

Need testing:
- A10
- A10s
- A13

Giulio Benetti (2):
  drm/sun4i: tcon: fix inverted DCLK polarity
  drm/sun4i: tcon: improve DCLK polarity handling

 drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 2 insertions(+), 19 deletions(-)

-- 
2.25.1

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

[PATCH v2 1/2] drm/sun4i: tcon: fix inverted DCLK polarity

[Giulio Benetti]

From: Giulio Benetti 

During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This lead to DLCK inversion, so let's swap DCLK
phase to fix it.

Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE 
flags")
Signed-off-by: Giulio Benetti 
---
V1->V2:
use Fixes: tag in commit log as suggested by Jernej
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..52598bb0fb0b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -585,10 +585,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 * and DOTCLOCK drivers.
 */
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
+   clk_set_phase(tcon->dclk, 0);
 
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   clk_set_phase(tcon->dclk, 240);
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
-- 
2.25.1

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

[PATCH 2/2] drm/sun4i: tcon: improve DCLK polarity handling

[Giulio Benetti]

It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is
dedicated to invert DCLK polarity and this makes thing really easier than
before. So let's handle DCLK polarity by adding
SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to
bus_flags the same way is done for all the other signals.

Cc: Maxime Ripard 
Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 52598bb0fb0b..30171ccd87e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
 
-   /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 0);
-
-   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 240);
+   val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE;
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..0ce71d10a31b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
 #define SUN4I_TCON0_IO_POL_REG 0x88
 #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase)   ((phase & 3) << 28)
 #define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_POSITIVE   BIT(26)
 #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE  BIT(25)
 #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE  BIT(24)
 
-- 
2.25.1

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

[PATCH 0/2] drm/sun4i: fix DCLK and improve its handling

[Giulio Benetti]

First patch is a tested by me fix, while the second need testing to
understand if it works correctly with any sunxi SoC with DE peripheral.
Already tested SoCs are:
- A20
- A33

Need testing:
- A10
- A10s
- A13

Giulio Benetti (2):
  drm/sun4i: tcon: fix inverted DCLK polarity
  drm/sun4i: tcon: improve DCLK polarity handling

 drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +---
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 2 insertions(+), 19 deletions(-)

-- 
2.25.1

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

[PATCH 1/2] drm/sun4i: tcon: fix inverted DCLK polarity

[Giulio Benetti]

During commit "88bc4178568b8e0331143cc0616640ab72f0cba1" DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This lead to DLCK inversion, so let's swap DCLK
phase to fix it.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..52598bb0fb0b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -585,10 +585,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 * and DOTCLOCK drivers.
 */
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
+   clk_set_phase(tcon->dclk, 0);
 
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
+   clk_set_phase(tcon->dclk, 240);
 
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
-- 
2.25.1

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

Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

[Giulio Benetti]

Il 13/12/2018 12:58, Giulio Benetti ha scritto:



Il 13/12/2018 04:08, Jonathan Liu ha scritto:

Hi Giulio,

On Wed, 12 Dec 2018 at 04:20, Giulio Benetti
 wrote:


Hi Jonathan,

Il 11/12/2018 11:49, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 6 Dec 2018 at 22:00, Giulio Benetti
 wrote:


Hi Jonathan,

Il 06/12/2018 08:29, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
 wrote:


Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.

Invert their settings of IO_POL register.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3c15cf2..aaf911a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 SUN4I_TCON0_BASIC3_H_SYNC(hsync));

/* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;

-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,


I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7"
LCD touchscreen (Innolux AT070TN92) connected to Olimex
A20-OLinuXino-MICRO that the image does not display correctly after
this change.
The image is shifted to the right.

Reverting the change results in the image being displayed correctly on
the screen.

I have in the device tree a "panel" node with compatible =
"innolux,at070tn92" which uses the timings in
drivers/gpu/drm/panel/panel-simple.c.

Any ideas?




Checking Display Datasheet:
https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf

Page 13 section 3.3.2 you can see it needs active low VS and HS.

You can refer to this Thread and check scope captures about VS and HS
versus TCON0_IOPOL register:
https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html

There should be something that wrongly sets one of these or both:
mode->flags |= DRM_MODE_FLAG_PHSYNC;
and/or
mode->flags |= DRM_MODE_FLAG_PVSYNC;

Checked in panel-simple.c but it's not there.




flags is 0 because it is not assigned in the struct definition for the panel.


I don't think it is 0, because otherwise IO_POL_REG wouldn't be set to
0x0300 but to 0.
What is checked is exactly mode->flags, so the problem seems to be upstream.

This is my doubt, it seems mode->flags is not initialized or overriden
at a certain point, this is why I want to debug it with Jtag tomorrow.


mode->flags is correct, just checked with debugger.





If you look at the change made by your patch:
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct
sun4i_tcon *tcon,
   SUN4I_TCON0_BASIC3_H_SYNC(hsync));

  /* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
  val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;

-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
  val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

  regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,

If mode->flags is 0,


mode->flags is 0xa(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) by
default if not specified different in panel-simple.c so the signals must
be active LOW(IO_POL_REG = 0x).


I was wrong, mode->flags is 0 by default if not specified, anyway this 
doesn't change the problem.

It seems that that display works with H/Vsync active HIGH(Positive).

Taken from drm_modes.h:
 *  - DRM_MODE_FLAG_PHSYNC: horizontal sync is active high.
 *  - DRM_MODE_FLAG_NHSYNC: horizontal sync is active low.
 *  - DRM_MODE_FLAG_PVSYNC: vertical sync is active high.
 *  - DRM_MODE_FLAG_NVSYNC: vertical sync is active low.

Maybe Datasheet is wrong at this point, since it should work correctly with:
mode->flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC

I've found other 2 Datasheet but they are equal about that:
https://datasheetspdf.com/pdf-file/775300/Innolux/AT070TN92/1
https://datasheetspdf.com/pdf-file/1256472/Innolux/AT070TN92-V1/1

Can you give a try changing those flags in panel-simple.c too?
I mean a try with:
mode->flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC
and one with:
mode->flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_

Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

[Giulio Benetti]

Il 13/12/2018 04:08, Jonathan Liu ha scritto:

Hi Giulio,

On Wed, 12 Dec 2018 at 04:20, Giulio Benetti
 wrote:


Hi Jonathan,

Il 11/12/2018 11:49, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 6 Dec 2018 at 22:00, Giulio Benetti
 wrote:


Hi Jonathan,

Il 06/12/2018 08:29, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
 wrote:


Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.

Invert their settings of IO_POL register.

Signed-off-by: Giulio Benetti 
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3c15cf2..aaf911a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
SUN4I_TCON0_BASIC3_H_SYNC(hsync));

   /* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
   val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;

-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
   val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

   regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,


I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7"
LCD touchscreen (Innolux AT070TN92) connected to Olimex
A20-OLinuXino-MICRO that the image does not display correctly after
this change.
The image is shifted to the right.

Reverting the change results in the image being displayed correctly on
the screen.

I have in the device tree a "panel" node with compatible =
"innolux,at070tn92" which uses the timings in
drivers/gpu/drm/panel/panel-simple.c.

Any ideas?




Checking Display Datasheet:
https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf

Page 13 section 3.3.2 you can see it needs active low VS and HS.

You can refer to this Thread and check scope captures about VS and HS
versus TCON0_IOPOL register:
https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html

There should be something that wrongly sets one of these or both:
mode->flags |= DRM_MODE_FLAG_PHSYNC;
and/or
mode->flags |= DRM_MODE_FLAG_PVSYNC;

Checked in panel-simple.c but it's not there.




flags is 0 because it is not assigned in the struct definition for the panel.


I don't think it is 0, because otherwise IO_POL_REG wouldn't be set to
0x0300 but to 0.
What is checked is exactly mode->flags, so the problem seems to be upstream.

This is my doubt, it seems mode->flags is not initialized or overriden
at a certain point, this is why I want to debug it with Jtag tomorrow.


mode->flags is correct, just checked with debugger.





If you look at the change made by your patch:
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct
sun4i_tcon *tcon,
  SUN4I_TCON0_BASIC3_H_SYNC(hsync));

 /* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
 val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;

-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
 val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

 regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,

If mode->flags is 0, 


mode->flags is 0xa(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) by 
default if not specified different in panel-simple.c so the signals must 
be active LOW(IO_POL_REG = 0x).



then before your change it would set
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE and
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE bits to 1 (resulting in 0x0300).


And it was wrong, because as I've pointed you above, especially in the 
Thread with all the scope captures, 0x0300 means active HIGH 
H/Vsync, while 0x means active LOW H/Vsync.



If mode->flags is not 0, then after your change it would not set
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE and
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE bits to 1 (resulting in 0x).


If mode->flags is 0x5(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) i.e. 
specified in panel-simple.c the signals must be active HIGH(IO_POL_REG = 
0x0300).


IO_POL_REG = 0x0300 is active HIGH
IO_POL_REG = 0x is active LOW

as I've checked many times and rechecked today lot of times too.


Before this change, TCON0_IO_POL_REG would be 0x0300 (both bits
set to 1) and image displays correctly > After this change, TCON0_IO_POL_REG is 
0x (both bits set to 0)
and image doe

Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

[Giulio Benetti]

Hi Jonathan,

Il 13/12/2018 03:55, Jonathan Liu ha scritto:

Can you precisely point me the sources of:
- u-boot
- kernel
- dts

you're using?

Thanks


U-Boot - git tag v2017.03
Linux - git tag v4.19.6
DTS - see device tree changes in
https://github.com/net147/linux/tree/sun7i-drm-wip but change the
compatible to "innolux,at070tn92"


With Linux v4.19.6 "innolux,at070tn92" doesn't even work and I suspect 
it is because of clock frequency tolerance check for pll setting, so it 
gets discarded from drm resulting in not having a crtc.


Anyway I've just re-checked the signals using another display:
"innolux,at043tn24" that has a more rounded clock frequency, so it's 
accepted by drm and **signals are correct**.
Unfortunately I don't have your same display here to test, so I can't 
help you about that precise panel.


Sorry.
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] drm/sun4i: fix HSYNC and VSYNC polarity

[Giulio Benetti]

Forgot to ask you,

Il 11/12/2018 18:20, Giulio Benetti ha scritto:

Hi Jonathan,

Il 11/12/2018 11:49, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 6 Dec 2018 at 22:00, Giulio Benetti
 wrote:


Hi Jonathan,

Il 06/12/2018 08:29, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
 wrote:


Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.

Invert their settings of IO_POL register.

Signed-off-by: Giulio Benetti 
---
   drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c

index 3c15cf2..aaf911a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct 
sun4i_tcon *tcon,

   SUN4I_TCON0_BASIC3_H_SYNC(hsync));

  /* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
  val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;

-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
  val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

  regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,


I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7"
LCD touchscreen (Innolux AT070TN92) connected to Olimex
A20-OLinuXino-MICRO that the image does not display correctly after
this change.
The image is shifted to the right.

Reverting the change results in the image being displayed correctly on
the screen.

I have in the device tree a "panel" node with compatible =
"innolux,at070tn92" which uses the timings in
drivers/gpu/drm/panel/panel-simple.c.

Any ideas?




Checking Display Datasheet:
https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf 



Page 13 section 3.3.2 you can see it needs active low VS and HS.

You can refer to this Thread and check scope captures about VS and HS
versus TCON0_IOPOL register:
https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html 



There should be something that wrongly sets one of these or both:
mode->flags |= DRM_MODE_FLAG_PHSYNC;
and/or
mode->flags |= DRM_MODE_FLAG_PVSYNC;

Checked in panel-simple.c but it's not there.


flags is 0 because it is not assigned in the struct definition for the 
panel.


I don't think it is 0, because otherwise IO_POL_REG wouldn't be set to 
0x0300 but to 0.
What is checked is exactly mode->flags, so the problem seems to be 
upstream.


This is my doubt, it seems mode->flags is not initialized or overriden 
at a certain point, this is why I want to debug it with Jtag tomorrow.



Before this change, TCON0_IO_POL_REG would be 0x0300 (both bits
set to 1) and image displays correctly > After this change, 
TCON0_IO_POL_REG is 0x (both bits set to 0)

and image doesn't display correctly.

Checked using "devmem2 0x01c0c088" on A20-OLinuXino-MICRO Rev J.


0x0300 as I've triple checked with scope means Positive H/Vsync,
and 0x Negative H/VSync.

Please check on the Thread I've pointed you above where there are all 
the links to the scope captures.


Are you completely sure you're using the correct panel?
This is because if with 0x0300 it works correctly, it means that 
you're using Positive VS and HS but on datasheet on Figure 3.2 it shows 
that they must be negative.


Do you have any chance to measure those signals with a scope?

Tomorrow, while debugging, I'll re-check H/Vsync signals again.

Kind regards


Can you precisely point me the sources of:
- u-boot
- kernel
- dts

you're using?

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

Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

[Giulio Benetti]

Hi Jonathan,

Il 11/12/2018 11:49, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 6 Dec 2018 at 22:00, Giulio Benetti
 wrote:


Hi Jonathan,

Il 06/12/2018 08:29, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
 wrote:


Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.

Invert their settings of IO_POL register.

Signed-off-by: Giulio Benetti 
---
   drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3c15cf2..aaf911a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
   SUN4I_TCON0_BASIC3_H_SYNC(hsync));

  /* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
  val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;

-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
  val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

  regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,


I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7"
LCD touchscreen (Innolux AT070TN92) connected to Olimex
A20-OLinuXino-MICRO that the image does not display correctly after
this change.
The image is shifted to the right.

Reverting the change results in the image being displayed correctly on
the screen.

I have in the device tree a "panel" node with compatible =
"innolux,at070tn92" which uses the timings in
drivers/gpu/drm/panel/panel-simple.c.

Any ideas?




Checking Display Datasheet:
https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf

Page 13 section 3.3.2 you can see it needs active low VS and HS.

You can refer to this Thread and check scope captures about VS and HS
versus TCON0_IOPOL register:
https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html

There should be something that wrongly sets one of these or both:
mode->flags |= DRM_MODE_FLAG_PHSYNC;
and/or
mode->flags |= DRM_MODE_FLAG_PVSYNC;

Checked in panel-simple.c but it's not there.


flags is 0 because it is not assigned in the struct definition for the panel.


I don't think it is 0, because otherwise IO_POL_REG wouldn't be set to 
0x0300 but to 0.

What is checked is exactly mode->flags, so the problem seems to be upstream.

This is my doubt, it seems mode->flags is not initialized or overriden 
at a certain point, this is why I want to debug it with Jtag tomorrow.



Before this change, TCON0_IO_POL_REG would be 0x0300 (both bits
set to 1) and image displays correctly > After this change, TCON0_IO_POL_REG is 
0x (both bits set to 0)
and image doesn't display correctly.

Checked using "devmem2 0x01c0c088" on A20-OLinuXino-MICRO Rev J.


0x0300 as I've triple checked with scope means Positive H/Vsync,
and 0x Negative H/VSync.

Please check on the Thread I've pointed you above where there are all 
the links to the scope captures.


Are you completely sure you're using the correct panel?
This is because if with 0x0300 it works correctly, it means that 
you're using Positive VS and HS but on datasheet on Figure 3.2 it shows 
that they must be negative.


Do you have any chance to measure those signals with a scope?

Tomorrow, while debugging, I'll re-check H/Vsync signals again.

Kind 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] drm/sun4i: fix HSYNC and VSYNC polarity

[Giulio Benetti]

Hi Jonathan,

Il 06/12/2018 08:29, Jonathan Liu ha scritto:

Hi Giulio,

On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
 wrote:


Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.

Invert their settings of IO_POL register.

Signed-off-by: Giulio Benetti 
---
  drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3c15cf2..aaf911a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -389,10 +389,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
  SUN4I_TCON0_BASIC3_H_SYNC(hsync));

 /* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
 val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;

-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
 val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;

 regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,


I am running Linux 4.19.6 and noticed with Olimex LCD-OLinuXino-7TS 7"
LCD touchscreen (Innolux AT070TN92) connected to Olimex
A20-OLinuXino-MICRO that the image does not display correctly after
this change.
The image is shifted to the right.

Reverting the change results in the image being displayed correctly on
the screen.

I have in the device tree a "panel" node with compatible =
"innolux,at070tn92" which uses the timings in
drivers/gpu/drm/panel/panel-simple.c.

Any ideas?


Checking Display Datasheet:
https://www.olimex.com/Products/Retired/A13-LCD7-TS/resources/S700-AT070TN92.pdf

Page 13 section 3.3.2 you can see it needs active low VS and HS.

You can refer to this Thread and check scope captures about VS and HS 
versus TCON0_IOPOL register:

https://lists.freedesktop.org/archives/dri-devel/2018-January/163874.html

There should be something that wrongly sets one of these or both:
mode->flags |= DRM_MODE_FLAG_PHSYNC;
and/or
mode->flags |= DRM_MODE_FLAG_PVSYNC;

Checked in panel-simple.c but it's not there.

At the moment I don't have a board to check it with me, I'll try to do 
it soon, but I'm full with other work at the moment.


If you have the chance to debug you could try to find in which point 
mode->flags gets changed with those 2 flags.


When the problem came out I've noticed the same thing for u-boot too but 
it's been decided to not patch it because in that case every single 
sunxi defconfig had to be changed from:

CONFIG_VIDEO_LCD_MODE="...,sync:3,..."
to:
CONFIG_VIDEO_LCD_MODE="...,sync:0,..."
and it would have been a great mess, probably not worth it:
https://lists.denx.de/pipermail/u-boot/2018-February/321405.html

So keep in mind that TCON driver works differently for HS and 
VS(inverted) polarity in u-boot and linux.


Hope to work this out soon.
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 2/2] drm/sun4i: hdmi: Fix double flag assignation

[Giulio Benetti]

Il 21/10/2018 18:34, Maxime Ripard ha scritto:

The is_double flag is a boolean currently assigned to the value of the d
variable, that is either 1 or 2. It means that this is_double variable is
always set to true, even though the initial intent was to have it set to
true when d is 2.

Fix this.

Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Reported-by: Dan Carpenter 
Signed-off-by: Maxime Ripard 


Reviewed-by: Giulio Benetti 


---
  drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index cd2348554bac..fb985ba1a176 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -52,7 +52,7 @@ static unsigned long sun4i_tmds_calc_divider(unsigned long 
rate,
(rate - tmp_rate) < (rate - best_rate)) {
best_rate = tmp_rate;
best_m = m;
-   is_double = d;
+   is_double = (d == 2) ? true : false;
}
}
    }



--
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 1/2] drm/sun4i: hdmi: Fix unitialized variable

[Giulio Benetti]

Il 21/10/2018 18:34, Maxime Ripard ha scritto:

The is_double variable is used to store, and possibly returning to the
calling function, whether it needs to double the rate of the parent clock
or not.

In the case where it does, the variable is affected, but in the case where
it doesn't we return some uninitialized value. Fix this.

Reported-by: Dan Carpenter 
Signed-off-by: Maxime Ripard 



---
  drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index 3ecffa52c814..cd2348554bac 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -35,7 +35,7 @@ static unsigned long sun4i_tmds_calc_divider(unsigned long 
rate,
  {
unsigned long best_rate = 0;
u8 best_m = 0, m;
-   bool is_double;
+   bool is_double = false;
  
  	for (m = div_offset ?: 1; m < (16 + div_offset); m++) {

u8 d;



--
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: [bug report] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE checking if panel is used.

[Giulio Benetti]

Hello Dan,

Il 11/10/2018 09:16, Dan Carpenter ha scritto:

This is an unreleased Smatch test because:
1) Some things return error pointers depending on the config.
2) Pointless IS_ERR() checks are quite common.


Look forward for new Smatch, very useful.


I haven't looked at the context to see how to fix this.  My guess is
that ->panel can't be NULL nor error pointer, so the check should be
removed.  But again, I haven't looked at the code.


Thanks for pointing as those 2 bugs are already fixed:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=49c5c0769a919549d814de52f7aceaa1c86a3fc7
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=548ae867efb1741fa55cedb5e73d7d0e75acd1f2


Btw, when you're mixing error pointers and NULL then normally NULL is a
special kind of success...  Like maybe you want to enable some hardware
if it's there and the function returns error pointers if memory
allocations fail but NULL if the hardware isn't there and isn't
required.


Yes, what you've pointed me helped me a lot to understand it.

Thank you 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

[PATCH v3 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if NULL

[Giulio Benetti]

If tcon->panel pointer is NULL, trying to dereference from it
(i.e. tcon->panel->connector) will cause a null pointer dereference.

Add tcon->panel null pointer check before calling
sun4i_tcon0_mode_set_dithering().

Signed-off-by: Giulio Benetti 
Fixes: f11adcecbd5f ("drm/sun4i: tcon: Add dithering support for
  RGB565/RGB666 LCD panels")
Reviewed-by: Chen-Yu Tsai 
---
Changes V1->V2:
* None

Changes V2->V3:
* Rewrite commit log

 drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e4b3bd0307ef..f949287d926c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -491,7 +491,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Set dithering if needed */
-   sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
+   if (tcon->panel)
+   sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
 
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
-- 
2.17.1

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

[PATCH v3 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer

[Giulio Benetti]

Since tcon->panel is a pointer returned by of_drm_find_panel() need to
check if it is not NULL, hence a valid pointer.
IS_ERR() instead checks return error values, not NULL pointers.

Substitute "if (!IS_ERR(tcon->panel))" with "if (tcon->panel)".

Signed-off-by: Giulio Benetti 
---
Changes V1->V2:
* correct same bug for all same occurences in drm/sun4i folder

Changes V2->V3:
* Improve commit log

 drivers/gpu/drm/sun4i/sun4i_lvds.c | 4 ++--
 drivers/gpu/drm/sun4i/sun4i_rgb.c  | 4 ++--
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index af7dcb6da351..e7eb0d1e17be 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -75,7 +75,7 @@ static void sun4i_lvds_encoder_enable(struct drm_encoder 
*encoder)
 
DRM_DEBUG_DRIVER("Enabling LVDS output\n");
 
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
drm_panel_prepare(tcon->panel);
drm_panel_enable(tcon->panel);
}
@@ -88,7 +88,7 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder 
*encoder)
 
DRM_DEBUG_DRIVER("Disabling LVDS output\n");
 
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
drm_panel_disable(tcon->panel);
drm_panel_unprepare(tcon->panel);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index bf068da6b12e..f4a22689eb54 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -135,7 +135,7 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder 
*encoder)
 
DRM_DEBUG_DRIVER("Enabling RGB output\n");
 
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
drm_panel_prepare(tcon->panel);
drm_panel_enable(tcon->panel);
}
@@ -148,7 +148,7 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder 
*encoder)
 
DRM_DEBUG_DRIVER("Disabling RGB output\n");
 
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
drm_panel_disable(tcon->panel);
drm_panel_unprepare(tcon->panel);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c78cd35a1294..e4b3bd0307ef 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -555,7 +555,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 * Following code is a way to avoid quirks all around TCON
 * and DOTCLOCK drivers.
 */
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
struct drm_panel *panel = tcon->panel;
struct drm_connector *connector = panel->connector;
struct drm_display_info display_info = connector->display_info;
-- 
2.17.1

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

Re: [PATCH v2 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if null

[Giulio Benetti]

Hi,

Il 04/10/2018 21:56, Maxime Ripard ha scritto:

On Wed, Oct 03, 2018 at 04:24:58PM +0200, Giulio Benetti wrote:

If using tcon with VGA,


We don't have support for VGA at the moment. Or are you talking about
using a VGA bridge?


You're right, in general VGA is not the point.
tcon->panel is retrieved by drm_of_find_panel_or_bridge() and panel can 
be present or not.



tcon->panel will be null(0), this will cause segmentation fault when
trying to dereference tcon->panel->connector.


It's not a segmentation fault, but a null pointer dereference. And
that case will also happen with bridges.


Right.

Going to improve/rewrite commit logs and submit v2 patchset.

Thanks for reviewing.

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

[PATCH v2 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer

[Giulio Benetti]

At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).

Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition to check if it's a pointer not null.

Signed-off-by: Giulio Benetti 
---
Changes V1->V2:
* correct same bug for all same occurences in drm/sun4i folder

 drivers/gpu/drm/sun4i/sun4i_lvds.c | 4 ++--
 drivers/gpu/drm/sun4i/sun4i_rgb.c  | 4 ++--
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index af7dcb6da351..e7eb0d1e17be 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -75,7 +75,7 @@ static void sun4i_lvds_encoder_enable(struct drm_encoder 
*encoder)
 
DRM_DEBUG_DRIVER("Enabling LVDS output\n");
 
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
drm_panel_prepare(tcon->panel);
drm_panel_enable(tcon->panel);
}
@@ -88,7 +88,7 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder 
*encoder)
 
DRM_DEBUG_DRIVER("Disabling LVDS output\n");
 
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
drm_panel_disable(tcon->panel);
drm_panel_unprepare(tcon->panel);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index bf068da6b12e..f4a22689eb54 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -135,7 +135,7 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder 
*encoder)
 
DRM_DEBUG_DRIVER("Enabling RGB output\n");
 
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
drm_panel_prepare(tcon->panel);
drm_panel_enable(tcon->panel);
}
@@ -148,7 +148,7 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder 
*encoder)
 
DRM_DEBUG_DRIVER("Disabling RGB output\n");
 
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
drm_panel_disable(tcon->panel);
drm_panel_unprepare(tcon->panel);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c78cd35a1294..e4b3bd0307ef 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -555,7 +555,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 * Following code is a way to avoid quirks all around TCON
 * and DOTCLOCK drivers.
 */
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
struct drm_panel *panel = tcon->panel;
struct drm_connector *connector = panel->connector;
struct drm_display_info display_info = connector->display_info;
-- 
2.17.1

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

[PATCH v2 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if null

[Giulio Benetti]

If using tcon with VGA, tcon->panel will be null(0), this will cause
segmentation fault when trying to dereference tcon->panel->connector.

Add tcon->panel null check before calling
sun4i_tcon0_mode_set_dithering().

Signed-off-by: Giulio Benetti 
Fixes: f11adcecbd5f ("drm/sun4i: tcon: Add dithering support for
  RGB565/RGB666 LCD panels")
Reviewed-by: Chen-Yu Tsai 
---
Changes V1->V2:
* none

 drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e4b3bd0307ef..f949287d926c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -491,7 +491,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Set dithering if needed */
-   sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
+   if (tcon->panel)
+   sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
 
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
-- 
2.17.1

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

Re: [PATCH 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer

[Giulio Benetti]

Il 03/10/2018 11:43, Chen-Yu Tsai ha scritto:

On Wed, Oct 3, 2018 at 5:59 AM Giulio Benetti
 wrote:


At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).

Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition to check if it's a pointer not null.


There's actually more than one occurance of this error:

drivers/gpu/drm/sun4i/sun4i_lvds.c: if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_lvds.c: if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_rgb.c:  if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_rgb.c:  if (!IS_ERR(tcon->panel)) {

These four are responsible for enabling and disabling the panel.

drivers/gpu/drm/sun4i/sun4i_tcon.c: if (!IS_ERR(tcon->panel)) {

All this looks like it was left over from commit ebc9446135671 ("drm: convert
drivers to use drm_of_find_panel_or_bridge"). We have checks against tcon->panel
in several places and not all of them were converted.



Then, I'm going to send a patchset to correct them.

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

[PATCH 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer

[Giulio Benetti]

At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).

Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition to check if it's a pointer not null.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c78cd35a1294..e4b3bd0307ef 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -555,7 +555,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 * Following code is a way to avoid quirks all around TCON
 * and DOTCLOCK drivers.
 */
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
struct drm_panel *panel = tcon->panel;
struct drm_connector *connector = panel->connector;
struct drm_display_info display_info = connector->display_info;
-- 
2.17.1

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

Re: [bug report] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE checking if panel is used.

[Giulio Benetti]

Il 01/10/2018 11:36, Dan Carpenter ha scritto:

Hello Giulio Benetti,

The patch 490cda5a3c82: "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
checking if panel is used." from Jul 18, 2018, leads to the following
static checker warning:
drivers/gpu/drm/sun4i/sun4i_tcon.c:558 sun4i_tcon0_mode_set_rgb()
warn: 'tcon->panel' isn't an ERR_PTR

drivers/gpu/drm/sun4i/sun4i_tcon.c
481   const struct drm_display_mode 
*mode)
482  {
483  unsigned int bp, hsync, vsync;
484  u8 clk_delay;
485  u32 val = 0;
486
487  WARN_ON(!tcon->quirks->has_channel_0);
488
489  tcon->dclk_min_div = 6;
490  tcon->dclk_max_div = 127;
491  sun4i_tcon0_mode_set_common(tcon, mode);
492
493  /* Set dithering if needed */
494  sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
  ^


Here there should be something like:
if (!tcon->panel) {
sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
}


495
496  /* Adjust clock delay */
497  clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
498  regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
499 SUN4I_TCON0_CTL_CLK_DELAY_MASK,
500 SUN4I_TCON0_CTL_CLK_DELAY(clk_delay));
501
502  /*
503   * This is called a backporch in the register documentation,
504   * but it really is the back porch + hsync
505   */
506  bp = mode->crtc_htotal - mode->crtc_hsync_start;
507  DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch %d\n",
508   mode->crtc_htotal, bp);
509
510  /* Set horizontal display timings */
511  regmap_write(tcon->regs, SUN4I_TCON0_BASIC1_REG,
512   SUN4I_TCON0_BASIC1_H_TOTAL(mode->crtc_htotal) |
513   SUN4I_TCON0_BASIC1_H_BACKPORCH(bp));
514
515  /*
516   * This is called a backporch in the register documentation,
517   * but it really is the back porch + hsync
518   */
519  bp = mode->crtc_vtotal - mode->crtc_vsync_start;
520  DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
521   mode->crtc_vtotal, bp);
522
523  /* Set vertical display timings */
524  regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
525   SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 2) 
|
526   SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
527
528  /* Set Hsync and Vsync length */
529  hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
530  vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
531  DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, vsync);
532  regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
533   SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
534   SUN4I_TCON0_BASIC3_H_SYNC(hsync));
535
536  /* Setup the polarity of the various signals */
537  if (mode->flags & DRM_MODE_FLAG_PHSYNC)
538  val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
539
540  if (mode->flags & DRM_MODE_FLAG_PVSYNC)
541  val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
542
543  /*
544   * On A20 and similar SoCs, the only way to achieve Positive 
Edge
545   * (Rising Edge), is setting dclk clock phase to 2/3(240°).
546   * By default TCON works in Negative Edge(Falling Edge),
547   * this is why phase is set to 0 in that case.
548   * Unfortunately there's no way to logically invert dclk 
through
549   * IO_POL register.
550   * The only acceptable way to work, triple checked with scope,
551   * is using clock phase set to 0° for Negative Edge and set to 
240°
552   * for Positive Edge.
553   * On A33 and similar SoCs there would be a 90° phase option,
554   * but it divides also dclk by 2.
555   * Following code is a way to avoid quirks all around TCON
556   * and DOTCLOCK drivers.
557   */
558  if (!IS_ERR(tcon->panel)) {
  ^^
Unpossible to be an error pointer!


So maybe I should use IS_ERR_OR_NULL() instead of IS_ERR(), or maybe simply:
if (!tcon->panel) {

Right?

Anyway I'm going to test it with "sparse".
Is it the same tool you've used for this?

Re: [bug report] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE checking if panel is used.

[Giulio Benetti]

Il 02/10/2018 15:26, Giulio Benetti ha scritto:

Il 01/10/2018 11:36, Dan Carpenter ha scritto:

Hello Giulio Benetti,

The patch 490cda5a3c82: "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
checking if panel is used." from Jul 18, 2018, leads to the following
static checker warning:
drivers/gpu/drm/sun4i/sun4i_tcon.c:558 sun4i_tcon0_mode_set_rgb()
warn: 'tcon->panel' isn't an ERR_PTR

drivers/gpu/drm/sun4i/sun4i_tcon.c
 481   const struct drm_display_mode 
*mode)
 482  {
 483  unsigned int bp, hsync, vsync;
 484  u8 clk_delay;
 485  u32 val = 0;
 486
 487  WARN_ON(!tcon->quirks->has_channel_0);
 488
 489  tcon->dclk_min_div = 6;
 490  tcon->dclk_max_div = 127;
 491  sun4i_tcon0_mode_set_common(tcon, mode);
 492
 493  /* Set dithering if needed */
 494  sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
   ^


Here there should be something like:
if (!tcon->panel) {
sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
}


 495
 496  /* Adjust clock delay */
 497  clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
 498  regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
 499 SUN4I_TCON0_CTL_CLK_DELAY_MASK,
 500 SUN4I_TCON0_CTL_CLK_DELAY(clk_delay));
 501
 502  /*
 503   * This is called a backporch in the register documentation,
 504   * but it really is the back porch + hsync
 505   */
 506  bp = mode->crtc_htotal - mode->crtc_hsync_start;
 507  DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch 
%d\n",
 508   mode->crtc_htotal, bp);
 509
 510  /* Set horizontal display timings */
 511  regmap_write(tcon->regs, SUN4I_TCON0_BASIC1_REG,
 512   SUN4I_TCON0_BASIC1_H_TOTAL(mode->crtc_htotal) |
 513   SUN4I_TCON0_BASIC1_H_BACKPORCH(bp));
 514
 515  /*
 516   * This is called a backporch in the register documentation,
 517   * but it really is the back porch + hsync
 518   */
 519  bp = mode->crtc_vtotal - mode->crtc_vsync_start;
 520  DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
 521   mode->crtc_vtotal, bp);
 522
 523  /* Set vertical display timings */
 524  regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
 525   SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 
2) |
 526   SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
 527
 528  /* Set Hsync and Vsync length */
 529  hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
 530  vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
 531  DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, 
vsync);
 532  regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
 533   SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
 534   SUN4I_TCON0_BASIC3_H_SYNC(hsync));
 535
 536  /* Setup the polarity of the various signals */
 537  if (mode->flags & DRM_MODE_FLAG_PHSYNC)
 538  val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
 539
 540  if (mode->flags & DRM_MODE_FLAG_PVSYNC)
 541  val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 542
 543  /*
 544   * On A20 and similar SoCs, the only way to achieve Positive 
Edge
 545   * (Rising Edge), is setting dclk clock phase to 2/3(240°).
 546   * By default TCON works in Negative Edge(Falling Edge),
 547   * this is why phase is set to 0 in that case.
 548   * Unfortunately there's no way to logically invert dclk 
through
 549   * IO_POL register.
 550   * The only acceptable way to work, triple checked with scope,
 551   * is using clock phase set to 0° for Negative Edge and set 
to 240°
 552   * for Positive Edge.
 553   * On A33 and similar SoCs there would be a 90° phase option,
 554   * but it divides also dclk by 2.
 555   * Following code is a way to avoid quirks all around TCON
 556   * and DOTCLOCK drivers.
 557   */
 558  if (!IS_ERR(tcon->panel)) {
   ^^
Unpossible to be an error pointer!


So maybe I should use IS_ERR_OR_NULL() instead of IS_ERR(), or maybe simply:
if

[PATCH 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if null

[Giulio Benetti]

If using tcon with VGA, tcon->panel will be null(0), this will cause
segmentation fault when trying to dereference tcon->panel->connector.

Add tcon->panel null check before calling
sun4i_tcon0_mode_set_dithering().

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e4b3bd0307ef..f949287d926c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -491,7 +491,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Set dithering if needed */
-   sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
+   if (tcon->panel)
+   sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
 
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
-- 
2.17.1

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

Re: [bug report] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE checking if panel is used.

[Giulio Benetti]

Il 02/10/2018 16:12, Giulio Benetti ha scritto:

Il 02/10/2018 15:26, Giulio Benetti ha scritto:

Il 01/10/2018 11:36, Dan Carpenter ha scritto:

Hello Giulio Benetti,

The patch 490cda5a3c82: "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
checking if panel is used." from Jul 18, 2018, leads to the following
static checker warning:
drivers/gpu/drm/sun4i/sun4i_tcon.c:558 sun4i_tcon0_mode_set_rgb()
warn: 'tcon->panel' isn't an ERR_PTR

drivers/gpu/drm/sun4i/sun4i_tcon.c
  481   const struct drm_display_mode 
*mode)
  482  {
  483  unsigned int bp, hsync, vsync;
  484  u8 clk_delay;
  485  u32 val = 0;
  486
  487  WARN_ON(!tcon->quirks->has_channel_0);
  488
  489  tcon->dclk_min_div = 6;
  490  tcon->dclk_max_div = 127;
  491  sun4i_tcon0_mode_set_common(tcon, mode);
  492
  493  /* Set dithering if needed */
  494  sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
^


Here there should be something like:
if (!tcon->panel) {
sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
}


  495
  496  /* Adjust clock delay */
  497  clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
  498  regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
  499 SUN4I_TCON0_CTL_CLK_DELAY_MASK,
  500 SUN4I_TCON0_CTL_CLK_DELAY(clk_delay));
  501
  502  /*
  503   * This is called a backporch in the register documentation,
  504   * but it really is the back porch + hsync
  505   */
  506  bp = mode->crtc_htotal - mode->crtc_hsync_start;
  507  DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch 
%d\n",
  508   mode->crtc_htotal, bp);
  509
  510  /* Set horizontal display timings */
  511  regmap_write(tcon->regs, SUN4I_TCON0_BASIC1_REG,
  512   SUN4I_TCON0_BASIC1_H_TOTAL(mode->crtc_htotal) |
  513   SUN4I_TCON0_BASIC1_H_BACKPORCH(bp));
  514
  515  /*
  516   * This is called a backporch in the register documentation,
  517   * but it really is the back porch + hsync
  518   */
  519  bp = mode->crtc_vtotal - mode->crtc_vsync_start;
  520  DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
  521   mode->crtc_vtotal, bp);
  522
  523  /* Set vertical display timings */
  524  regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
  525   SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 
2) |
  526   SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
  527
  528  /* Set Hsync and Vsync length */
  529  hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
  530  vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
  531  DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, 
vsync);
  532  regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
  533   SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
  534   SUN4I_TCON0_BASIC3_H_SYNC(hsync));
  535
  536  /* Setup the polarity of the various signals */
  537  if (mode->flags & DRM_MODE_FLAG_PHSYNC)
  538  val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
  539
  540  if (mode->flags & DRM_MODE_FLAG_PVSYNC)
  541  val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
  542
  543  /*
  544   * On A20 and similar SoCs, the only way to achieve Positive 
Edge
  545   * (Rising Edge), is setting dclk clock phase to 2/3(240°).
  546   * By default TCON works in Negative Edge(Falling Edge),
  547   * this is why phase is set to 0 in that case.
  548   * Unfortunately there's no way to logically invert dclk 
through
  549   * IO_POL register.
  550   * The only acceptable way to work, triple checked with 
scope,
  551   * is using clock phase set to 0° for Negative Edge and set 
to 240°
  552   * for Positive Edge.
  553   * On A33 and similar SoCs there would be a 90° phase option,
  554   * but it divides also dclk by 2.
  555   * Following code is a way to avoid quirks all around TCON
  556   * and DOTCLOCK drivers.
  557   */
  558  if (!IS_ERR(tcon->panel)) {

Re: [PATCH 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer

[Giulio Benetti]

Sorry for sending twice(and top posting), but I was not subscribed to 
dri-devel ML, so patchwork was not aware of these 2 patches.


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

Il 02/10/2018 23:59, Giulio Benetti ha scritto:

At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).

Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition to check if it's a pointer not null.

Signed-off-by: Giulio Benetti 
---
  drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c78cd35a1294..e4b3bd0307ef 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -555,7 +555,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 * Following code is a way to avoid quirks all around TCON
 * and DOTCLOCK drivers.
 */
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
struct drm_panel *panel = tcon->panel;
struct drm_connector *connector = panel->connector;
struct drm_display_info display_info = connector->display_info;


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

[PATCH 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer

[Giulio Benetti]

At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).

Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition to check if it's a pointer not null.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c78cd35a1294..e4b3bd0307ef 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -555,7 +555,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 * Following code is a way to avoid quirks all around TCON
 * and DOTCLOCK drivers.
 */
-   if (!IS_ERR(tcon->panel)) {
+   if (tcon->panel) {
struct drm_panel *panel = tcon->panel;
struct drm_connector *connector = panel->connector;
struct drm_display_info display_info = connector->display_info;
-- 
2.17.1

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

[PATCH 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if null

[Giulio Benetti]

If using tcon with VGA, tcon->panel will be null(0), this will cause
segmentation fault when trying to dereference tcon->panel->connector.

Add tcon->panel null check before calling
sun4i_tcon0_mode_set_dithering().

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e4b3bd0307ef..f949287d926c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -491,7 +491,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Set dithering if needed */
-   sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
+   if (tcon->panel)
+   sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
 
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
-- 
2.17.1

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

Re: [PATCH 0/5] Add CDTech 4.3" and 7" to panel-simple

[Giulio Benetti]

Hello Thierry,

Il 27/09/2018 13:59, Thierry Reding ha scritto:

On Tue, Jul 31, 2018 at 01:11:12AM +0200, Giulio Benetti wrote:

Add CDTech 4.3" S043WQ26H-CT7 support
Add CDTech 7" S070WV95-CT16 support

Giulio Benetti (5):
   dt-bindings: Add vendor prefix for CDTech(H.K.) Electronics Limited
   drm/panel: add panel CDTech S070WV95-CT16 to panel-simple
   dt-bindings: Add CDTech S070WV95-CT16 panel bindings
   drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple
   dt-bindings: Add CDTech S043WQ26H-CT7 panel bindings

  .../display/panel/cdtech,s043wq26h-ct7.txt| 12 
  .../display/panel/cdtech,s070wv95-ct16.txt| 12 
  .../devicetree/bindings/vendor-prefixes.txt   |  1 +
  drivers/gpu/drm/panel/panel-simple.c  | 55 +++
  4 files changed, 80 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
  create mode 100644 
Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt


All applied, thanks. One small note, though: in the future please send
DT bindings patches before the driver patches. This is important because
checkpatch, which is run as pre-commit script, warns about undocumented
compatible strings if you send driver changes before the bindings.


Ok, thanks for both applying and pointing me this important detail.

--
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

[PATCH 2/5] drm/panel: add panel CDTech S070WV95-CT16 to panel-simple

[Giulio Benetti]

This patch adds support for CDTech S070WV95-CT16 800x480 7" panel to DRM
simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..caa5a01eb8e3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -787,6 +787,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 = _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,
@@ -2115,6 +2139,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "boe,nv101wxmn51",
.data = _nv101wxmn51,
+   }, {
+   .compatible = "cdtech,s070wv95-ct16",
+   .data = _s070wv95_ct16,
}, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
-- 
2.17.1

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

[PATCH 5/5] dt-bindings: Add CDTech S043WQ26H-CT7 panel bindings

[Giulio Benetti]

Add documentation for S043WQ26H-CT7 panel

Signed-off-by: Giulio Benetti 
---
 .../bindings/display/panel/cdtech,s043wq26h-ct7.txt  | 12 
 1 file changed, 12 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 ..057f7f3f6dbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
@@ -0,0 +1,12 @@
+CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
+
+Required properties:
+- compatible: should be "cdtech,s043wq26h-ct7"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+- enable-gpios: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.17.1

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

[PATCH 0/5] Add CDTech 4.3" and 7" to panel-simple

[Giulio Benetti]

Add CDTech 4.3" S043WQ26H-CT7 support
Add CDTech 7" S070WV95-CT16 support

Giulio Benetti (5):
  dt-bindings: Add vendor prefix for CDTech(H.K.) Electronics Limited
  drm/panel: add panel CDTech S070WV95-CT16 to panel-simple
  dt-bindings: Add CDTech S070WV95-CT16 panel bindings
  drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple
  dt-bindings: Add CDTech S043WQ26H-CT7 panel bindings

 .../display/panel/cdtech,s043wq26h-ct7.txt| 12 
 .../display/panel/cdtech,s070wv95-ct16.txt| 12 
 .../devicetree/bindings/vendor-prefixes.txt   |  1 +
 drivers/gpu/drm/panel/panel-simple.c  | 55 +++
 4 files changed, 80 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt

-- 
2.17.1

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

[PATCH 4/5] drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple

[Giulio Benetti]

This patch adds support for CDTech S043WQ26H-CT7 480x272 4.3" panel to
DRM simple panel driver.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/panel/panel-simple.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index caa5a01eb8e3..3a6a66c2307d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -787,6 +787,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 = _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,
@@ -2139,6 +2164,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "boe,nv101wxmn51",
.data = _nv101wxmn51,
+   }, {
+   .compatible = "cdtech,s043wq26h-ct7",
+   .data = _s043wq26h_ct7,
}, {
.compatible = "cdtech,s070wv95-ct16",
.data = _s070wv95_ct16,
-- 
2.17.1

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

[PATCH 3/5] dt-bindings: Add CDTech S070WV95-CT16 panel bindings

[Giulio Benetti]

Add documentation for S070WV95-CT16 panel

Signed-off-by: Giulio Benetti 
---
 .../bindings/display/panel/cdtech,s070wv95-ct16.txt  | 12 
 1 file changed, 12 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 ..505615dfa0df
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
@@ -0,0 +1,12 @@
+CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
+
+Required properties:
+- compatible: should be "cdtech,s070wv95-ct16"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+- enable-gpios: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.17.1

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

[PATCH 1/5] dt-bindings: Add vendor prefix for CDTech(H.K.) Electronics Limited

[Giulio Benetti]

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

Website: www.cdtech-lcd.com

Signed-off-by: Giulio Benetti 
---
 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 760d1c11458c..29894c628e00 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -64,6 +64,7 @@ capella   Capella Microsystems, Inc
 cascodaCascoda, Ltd.
 cavium Cavium, Inc.
 cdns   Cadence Design Systems Inc.
+cdtech CDTech(H.K.) Electronics Limited
 ceva   Ceva, Inc.
 chipidea   Chipidea, Inc
 chiponeChipOne
-- 
2.17.1

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

Re: [PATCH] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE checking if panel is used.

[Giulio Benetti]

Hi Paul,

can you give a try to this patch on A13 with VGA DAC?
Unfortunately I don't have an A13 board to test it.

Thanks in advance.

Giulio

Il 18/07/2018 16:23, Giulio Benetti ha scritto:

Handle both positive and negative dclk polarity,
according to bus_flags, taking care of this:

On A20 and similar SoCs, the only way to achieve Positive Edge
(Rising Edge), is setting dclk clock phase to 2/3(240°).
By default TCON works in Negative Edge(Falling Edge), this is why phase
is set to 0 in that case.
Unfortunately there's no way to logically invert dclk through IO_POL
register.
The only acceptable way to work, triple checked with scope,
is using clock phase set to 0° for Negative Edge and set to 240° for
Positive Edge.
On A33 and similar SoCs there would be a 90° phase option, but it divides
also dclk by 2.
This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers
for using A33 90° phase divided by 2 and consequently increase code
complexity.

Check if panel is used. TCON can also handle VGA DAC, then panel could
be empty.

Signed-off-by: Giulio Benetti 
---
  drivers/gpu/drm/sun4i/sun4i_tcon.c | 28 
  1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 8232b39e16ca..5c7d6ae53111 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 
  
@@ -474,6 +475,33 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,

if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
  
+	/*

+* On A20 and similar SoCs, the only way to achieve Positive Edge
+* (Rising Edge), is setting dclk clock phase to 2/3(240°).
+* By default TCON works in Negative Edge(Falling Edge),
+* this is why phase is set to 0 in that case.
+* Unfortunately there's no way to logically invert dclk through
+* IO_POL register.
+* The only acceptable way to work, triple checked with scope,
+* is using clock phase set to 0° for Negative Edge and set to 240°
+* for Positive Edge.
+* On A33 and similar SoCs there would be a 90° phase option,
+* but it divides also dclk by 2.
+* Following code is a way to avoid quirks all around TCON
+* and DOTCLOCK drivers.
+*/
+   if (!IS_ERR(tcon->panel)) {
+   struct drm_panel *panel = tcon->panel;
+   struct drm_connector *connector = panel->connector;
+   struct drm_display_info display_info = connector->display_info;
+
+   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+   clk_set_phase(tcon->dclk, 240);
+
+   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+   clk_set_phase(tcon->dclk, 0);
+   }
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
   val);


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

[PATCH] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE checking if panel is used.

[Giulio Benetti]

Handle both positive and negative dclk polarity,
according to bus_flags, taking care of this:

On A20 and similar SoCs, the only way to achieve Positive Edge
(Rising Edge), is setting dclk clock phase to 2/3(240°).
By default TCON works in Negative Edge(Falling Edge), this is why phase
is set to 0 in that case.
Unfortunately there's no way to logically invert dclk through IO_POL
register.
The only acceptable way to work, triple checked with scope,
is using clock phase set to 0° for Negative Edge and set to 240° for
Positive Edge.
On A33 and similar SoCs there would be a 90° phase option, but it divides
also dclk by 2.
This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers
for using A33 90° phase divided by 2 and consequently increase code
complexity.

Check if panel is used. TCON can also handle VGA DAC, then panel could
be empty.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 8232b39e16ca..5c7d6ae53111 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -474,6 +475,33 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 
+   /*
+* On A20 and similar SoCs, the only way to achieve Positive Edge
+* (Rising Edge), is setting dclk clock phase to 2/3(240°).
+* By default TCON works in Negative Edge(Falling Edge),
+* this is why phase is set to 0 in that case.
+* Unfortunately there's no way to logically invert dclk through
+* IO_POL register.
+* The only acceptable way to work, triple checked with scope,
+* is using clock phase set to 0° for Negative Edge and set to 240°
+* for Positive Edge.
+* On A33 and similar SoCs there would be a 90° phase option,
+* but it divides also dclk by 2.
+* Following code is a way to avoid quirks all around TCON
+* and DOTCLOCK drivers.
+*/
+   if (!IS_ERR(tcon->panel)) {
+   struct drm_panel *panel = tcon->panel;
+   struct drm_connector *connector = panel->connector;
+   struct drm_display_info display_info = connector->display_info;
+
+   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+   clk_set_phase(tcon->dclk, 240);
+
+   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+   clk_set_phase(tcon->dclk, 0);
+   }
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
   val);
-- 
2.17.1

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

Re: [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"

[Giulio Benetti]

Hi Paul,

Il 14/06/2018 09:26, Paul Kocialkowski ha scritto:

Hi,

On Wed, 2018-06-13 at 23:52 +0200, Giulio Benetti wrote:

Hello,

sorry for my ignorance.
I don't know the right patch workflow in the case of "revert commit".
When I fix this bug, should I have to re-submit the previous patch
entire plus bug-fix?

Or do I have to submit patch with bug-fix only?


Yes, that is usually how it works! The revert patch will be picked up by
the maintainer (Maxime), integrated in his tree and eventually merged
into Linus' tree (along with stable trees).

Fixup patches for this will need to take into account the revert patch,
so it becomes equivalent to submitting the same patch with that issue
resolved.


Thanks for explaining me.
I'm going to submit new patch asap.

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

Re: [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"

[Giulio Benetti]

Hello,

sorry for my ignorance.
I don't know the right patch workflow in the case of "revert commit".
When I fix this bug, should I have to re-submit the previous patch 
entire plus bug-fix?

Or do I have to submit patch with bug-fix only?

Thanks in advance to everybody

--
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

Il 13/06/2018 10:16, Paul Kocialkowski ha scritto:

This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70.

The offending commit triggers a run-time fault when accessing the panel
element of the sun4i_tcon structure when no such panel is attached.

It was apparently assumed in said commit that a panel is always used with
the TCON. Although it is often the case, this is not always true.
For instance a bridge might be used instead of a panel.

This issue was discovered using an A13-OLinuXino, that uses the TCON
in RGB mode for a simple DAC-based VGA bridge.

Cc: sta...@vger.kernel.org
Signed-off-by: Paul Kocialkowski 
---
  drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 -
  1 file changed, 25 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c3d92d537240..8045871335b5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,7 +17,6 @@
  #include 
  #include 
  #include 
-#include 
  
  #include 
  
@@ -350,9 +349,6 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon,

  static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
 const struct drm_display_mode *mode)
  {
-   struct drm_panel *panel = tcon->panel;
-   struct drm_connector *connector = panel->connector;
-   struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -410,27 +406,6 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
  
-	/*

-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
-   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
-   clk_set_phase(tcon->dclk, 240);
-
-   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
-   clk_set_phase(tcon->dclk, 0);
-
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
   val);



___
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
___
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 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

[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

[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 
#include 

 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";

ft5x {
compatible = "edt,edt-ft5306";
reg = <0x38>;
interrupt-parent = <>;
interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
reset-gpios = < 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 0x4300 (where dtb is)
# fdt resize 8192
# fdt apply 0x430c (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

[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.




+_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 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.




+_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

[Giulio Benetti]

Hi Maxime, Il 24 apr 2018 10:41, Maxime Ripard <maxime.rip...@bootlin.com> 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, 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" ctpLiNova1 7" ctpLiNova1 10.1" ctpLiNova1 4.3" rtpLiNova1 7" rtpLiNova1 10.1" rtpEvery 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 LiNova3So 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. Sorry if I bother you again but I wanted to understand better. 


> > > +_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? I can't understand why it shouldn't make sense. There is no daughter board. Thank you very much in advance for you patience :) Giulio 




> 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


___
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 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.bene...@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 000..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 <hdego...@redhat.com>
+ * Copyright (c) 2014 FUKAUMI Naoki <nao...@gmail.com>
+ * Copyright (c) 2018 Giulio Benetti <giulio.bene...@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 pe

Re: [v2] drm/sun4i: add lvds mode_valid function

[Giulio Benetti]

Hi everybody,

Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto:

On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman
<doudahwezomiechah...@xff.cz> wrote:

Hello Giulio,

this patch breaks LVDS output on A83T. Without it, modesetting works,
with it there's no output.

Some more info below...

On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:

mode_valid function is missing for lvds.

Add it making it pointed by encoder helper functions.

Signed-off-by: Giulio Benetti <giulio.bene...@micronovasrl.com>
---
  drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 ++
  1 file changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index be3f14d..b4c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder 
*encoder)
   }
  }

+static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct drm_encoder 
*crtc,
+   const struct 
drm_display_mode *mode)
+{
+ struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
+ struct sun4i_tcon *tcon = lvds->tcon;
+ u32 hsync = mode->hsync_end - mode->hsync_start;
+ u32 vsync = mode->vsync_end - mode->vsync_start;
+ unsigned long rate = mode->clock * 1000;
+ long rounded_rate;
+
+ DRM_DEBUG_DRIVER("Validating modes...\n");
+
+ if (hsync < 1)
+ return MODE_HSYNC_NARROW;
+
+ if (hsync > 0x3ff)
+ return MODE_HSYNC_WIDE;
+
+ if ((mode->hdisplay < 1) || (mode->htotal < 1))
+ return MODE_H_ILLEGAL;
+
+ if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
+ return MODE_BAD_HVALUE;
+
+ DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
+
+ if (vsync < 1)
+ return MODE_VSYNC_NARROW;
+
+ if (vsync > 0x3ff)
+ return MODE_VSYNC_WIDE;
+
+ if ((mode->vdisplay < 1) || (mode->vtotal < 1))
+ return MODE_V_ILLEGAL;
+
+ if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
+ return MODE_BAD_VVALUE;
+
+ DRM_DEBUG_DRIVER("Vertical parameters OK\n");
+
+ tcon->dclk_min_div = 7;
+ tcon->dclk_max_div = 7;


Why would validation function change any state anywhere?


+ rounded_rate = clk_round_rate(tcon->dclk, rate);


The issue is here, on A83T TBS A711 tablet, I get...

sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 htotal=1384
   vsync=5 vdisplay=600 vtotal=640 rate=5200 rounded_rate=51857142


+ if (rounded_rate < rate)
+ return MODE_CLOCK_LOW;
+
+ if (rounded_rate > rate)
+ return MODE_CLOCK_HIGH;


... while the previous conditions require an exact match for some reason.

But HW works fine without an exact rate match. Why is exact match required here?


This thread might provide some more info, though we could never get an
agreement.

https://patchwork.kernel.org/patch/9446385/


Thanks for pointing that Thread ChenYu.
So the only chance is to trim frequency according to encoder capabilities.
I agree to block when encoder can't provide frequency specified,
otherwise you could drive you panel at the near the lowest(highest)
frequency and get out of limits for a few without knowing it.

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



ChenYu



thank you,
   Ondrej


+ DRM_DEBUG_DRIVER("Clock rate OK\n");
+
+ return MODE_OK;
+}
+
  static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
   .disable= sun4i_lvds_encoder_disable,
   .enable = sun4i_lvds_encoder_enable,
+ .mode_valid = sun4i_lvds_encoder_mode_valid,
  };

  static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {

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




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

Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

[Giulio Benetti]

Hi,

Il 19/04/2018 14:45, Chen-Yu Tsai ha scritto:

On Thu, Apr 19, 2018 at 8:31 PM, Giulio Benetti
<giulio.bene...@micronovasrl.com> wrote:

Hi,

Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:


This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.



Judging from the code, the real vendor should be CDTech.
Take a look at their website:
http://www.cdtech-lcd.com/en/standardscreen.html

I point you my patch for inserting another similar panel:
https://patchwork.freedesktop.org/patch/211914/

Maybe it would make sense to use CDTech as the vendor,
because maybe Bananapi resells only it.
Or maybe it is a custom panel done for them,
but the same is for other panels I've submitted patches.
Micronova srl custom, but vendor is CDTech.

What do you think?


That might be true. But for people without access to the vendors,
this is horribly hard to figure out. People are only going to look
at whatever marking there is on the LCD panel, and whatever the
seller says. This panel has the model number stickered on, but the
PCB attached to it only has the Banana Pi logo.


Ah ok, my fault, I didn't see it has a PCB attached with Banana Pi logo.
Also it makes a lot of sense what you say about people looking for display.



And given it's a custom piece, probably OEM or ODM, the real
manufacturer matters less. You don't mention "Foxconn" as the
vendor of the iPhone, do you?


:) that's right.

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



ChenYu



--
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




This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>
---
   .../display/panel/bananapi,s070wv20-ct16.txt  |  7 ++
   drivers/gpu/drm/panel/panel-simple.c  | 25 +++
   2 files changed, 32 insertions(+)
   create mode 100644
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt

diff --git
a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
new file mode 100644
index ..2ec35ce36e9a
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -0,0 +1,7 @@
+Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+
+Required properties:
+- compatible: should be "bananapi,s070wv20-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 cbf1ab404ee7..9bc037f74d6c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
 },
   };
   +static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 40,
+   .hsync_end = 800 + 40 + 48,
+   .htotal = 800 + 40 + 48 + 40,
+   .vdisplay = 480,
+   .vsync_start = 480 + 13,
+   .vsync_end = 480 + 13 + 3,
+   .vtotal = 480 + 13 + 3 + 29,
+};
+
+static const struct panel_desc bananapi_s070wv20_ct16 = {
+   .modes = _s070wv20_ct16_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+};
+
   static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
 {
 .clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[]
= {
 }, {
 .compatible = "avic,tm070ddh03",
 .data = _tm070ddh03,
+   }, {
+   .compatible = "bananapi,s070wv20-ct16",
+   .data = _s070wv20_ct16,
 }, {
 .compatible = "boe,nv101wxmn51",
 .data = _nv101wxmn51,






--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@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

Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

[Giulio Benetti]

Hi,

Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:

This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.


Judging from the code, the real vendor should be CDTech.
Take a look at their website:
http://www.cdtech-lcd.com/en/standardscreen.html

I point you my patch for inserting another similar panel:
https://patchwork.freedesktop.org/patch/211914/

Maybe it would make sense to use CDTech as the vendor,
because maybe Bananapi resells only it.
Or maybe it is a custom panel done for them,
but the same is for other panels I've submitted patches.
Micronova srl custom, but vendor is CDTech.

What do you think?

--
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



This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>
---
  .../display/panel/bananapi,s070wv20-ct16.txt  |  7 ++
  drivers/gpu/drm/panel/panel-simple.c  | 25 +++
  2 files changed, 32 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt 
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
new file mode 100644
index ..2ec35ce36e9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -0,0 +1,7 @@
+Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+
+Required properties:
+- compatible: should be "bananapi,s070wv20-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 cbf1ab404ee7..9bc037f74d6c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
  };
  
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {

+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 40,
+   .hsync_end = 800 + 40 + 48,
+   .htotal = 800 + 40 + 48 + 40,
+   .vdisplay = 480,
+   .vsync_start = 480 + 13,
+   .vsync_end = 480 + 13 + 3,
+   .vtotal = 480 + 13 + 3 + 29,
+};
+
+static const struct panel_desc bananapi_s070wv20_ct16 = {
+   .modes = _s070wv20_ct16_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+};
+
  static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
+   }, {
+   .compatible = "bananapi,s070wv20-ct16",
+   .data = _s070wv20_ct16,
}, {
.compatible = "boe,nv101wxmn51",
.data = _nv101wxmn51,





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

Re: [linux-sunxi] Re: [PATCH 2/3] ARM: dts: sun7i: Add RGB666 pins definition

[Giulio Benetti]

Hi,

Il 12/04/2018 01:09, Paul Kocialkowski ha scritto:

Hi,

Le jeudi 12 avril 2018 à 00:22 +0200, Giulio Benetti a écrit :

Hi,

Il 10/04/2018 23:31, Paul Kocialkowski ha scritto:

This adds the pins definition for RGB666 LCD panels on the A20. It
was
imported from the A33 definition, that concernes the same set of
pins.

Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
---
   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 e529e4ff2174..f46af8675cfa 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -781,6 +781,14 @@
function = "ir1";
};
   
+			lcd_rgb666_pins: lcd_rgb666@0 {


I point you to this Thread and back:
https://lists.freedesktop.org/archives/dri-devel/2018-March/170688.htm
l

I did the same for rgb888, so good part is discussed.

IMHO I would:
- call lcd0_rgb666_pins, since this is for LCD0 interface
- same as above, call lcd0-rgb666, take care about using "-" instad
of
"_" that can cause DTC warnings.
- remove @0 since only this set can achieve LCD0 RGB666, and I
don't think there will be other combinations.


I even responded to that discussion but overlooked these aspects when
crafting this patch. Thanks for the summary :)


You're welcome, I've forgotten you've been involved discussing
that patch so i've pointed you something yours :)
Anyway it should help.

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




Kind 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



+   pins = "PD2", "PD3", "PD4", "PD5",
"PD6", "PD7",
+  "PD10", "PD11", "PD12",
"PD13", "PD14", "PD15",
+  "PD18", "PD19", "PD20",
"PD21", "PD22", "PD23",
+  "PD24", "PD25", "PD26",
"PD27";
+   function = "lcd0";
+   };
+
mmc0_pins_a: mmc0@0 {
pins = "PF0", "PF1", "PF2",
   "PF3", "PF4", "PF5";






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

Re: [PATCH 2/3] ARM: dts: sun7i: Add RGB666 pins definition

[Giulio Benetti]

Hi,

Il 10/04/2018 23:31, Paul Kocialkowski ha scritto:

This adds the pins definition for RGB666 LCD panels on the A20. It was
imported from the A33 definition, that concernes the same set of pins.

Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
---
  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 e529e4ff2174..f46af8675cfa 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -781,6 +781,14 @@
function = "ir1";
};
  
+			lcd_rgb666_pins: lcd_rgb666@0 {


I point you to this Thread and back:
https://lists.freedesktop.org/archives/dri-devel/2018-March/170688.html

I did the same for rgb888, so good part is discussed.

IMHO I would:
- call lcd0_rgb666_pins, since this is for LCD0 interface
- same as above, call lcd0-rgb666, take care about using "-" instad of 
"_" that can cause DTC warnings.

- remove @0 since only this set can achieve LCD0 RGB666, and I
  don't think there will be other combinations.

Kind 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



+   pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+  "PD10", "PD11", "PD12", "PD13", "PD14", 
"PD15",
+  "PD18", "PD19", "PD20", "PD21", "PD22", 
"PD23",
+  "PD24", "PD25", "PD26", "PD27";
+   function = "lcd0";
+   };
+
mmc0_pins_a: mmc0@0 {
pins = "PF0", "PF1", "PF2",
   "PF3", "PF4", "PF5";




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

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


In any case,

Reviewed-by: Rob Herring <r...@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@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

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

[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.bene...@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
 cascodaCascoda, Ltd.
 cavium Cavium, Inc.
 cdns   Cadence Design Systems Inc.
+cdtech CDTech(H.K.) Electronics Limited
 ceva   Ceva, Inc.
 chipidea   Chipidea, Inc
 chiponeChipOne
-- 
2.7.4

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