[PATCH] [RFC] drm/i915/dp: DP PHY compliance for EHL/JSL

2020-09-03 Thread Vidya Srinivas
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.

v2: Rebased patch on top of Khaled's (yet to be merged):
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+

[PATCH 3/3] [RFC] drm/i915/dp: DP PHY compliance for EHL/JSL

2020-09-03 Thread Vidya Srinivas
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.

v2: Rebased patch on top of Khaled's (yet to be merged):
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+

[PATCH 2/3] drm/i915/dp: TPS4 PHY test pattern compliance support

2020-09-03 Thread Vidya Srinivas
From: Khaled Almahallawy 

Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.

v2: uniform bit names TP4a/b/c (Manasi)

Signed-off-by: Khaled Almahallawy 
Reviewed-by: Manasi Navare 
Tested-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 --
 drivers/gpu/drm/i915/i915_reg.h |  4 
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 04231ca5643b..a8a3ffcef5dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5403,7 +5403,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
-   u32 pattern_val;
+   u32 pattern_val, dp_tp_ctl;
 
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
@@ -5443,7 +5443,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
/*
 * FIXME: Ideally pattern should come from DPCD 0x24A. As
 * current firmware of DPR-100 could not set it, so hardcoding
@@ -5455,6 +5455,16 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
+   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
+   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
+   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   dp_tp_ctl = intel_de_read(dev_priv, 
TGL_DP_TP_CTL(pipe));
+   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
+   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
+   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
+   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
dp_tp_ctl);
+   break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab4b1abd4364..4850890918dc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9974,6 +9974,10 @@ enum skl_power_gate {
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
-- 
2.7.4

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


[PATCH 1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

2020-09-03 Thread Vidya Srinivas
From: Khaled Almahallawy 

Add the missing CP2520 pattern 2 and 3 phy compliance patterns

v2: cosemtic changes

Reviewed-by: Manasi Navare  (v1)
Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 include/drm/drm_dp_helper.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d0fb78c6aca6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
return err;
 
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
   >hbr2_reset,
   sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e2d2df5e869e..73285b4c25a0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -708,7 +708,9 @@
 # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
 # define DP_PHY_TEST_PATTERN_PRBS7  0x3
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT10x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT20x6
+# define DP_PHY_TEST_PATTERN_CP2520_PAT30x7
 
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
-- 
2.7.4

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


[PATCH 2/3] drm/i915/dp: TPS4 PHY test pattern compliance support

2020-09-03 Thread Vidya Srinivas
From: Khaled Almahallawy 

Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.

v2: uniform bit names TP4a/b/c (Manasi)

Signed-off-by: Khaled Almahallawy 
Reviewed-by: Manasi Navare 
Tested-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 --
 drivers/gpu/drm/i915/i915_reg.h |  4 
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 04231ca5643b..a8a3ffcef5dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5403,7 +5403,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
-   u32 pattern_val;
+   u32 pattern_val, dp_tp_ctl;
 
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
@@ -5443,7 +5443,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
/*
 * FIXME: Ideally pattern should come from DPCD 0x24A. As
 * current firmware of DPR-100 could not set it, so hardcoding
@@ -5455,6 +5455,16 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
+   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
+   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
+   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   dp_tp_ctl = intel_de_read(dev_priv, 
TGL_DP_TP_CTL(pipe));
+   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
+   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
+   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
+   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
dp_tp_ctl);
+   break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab4b1abd4364..4850890918dc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9974,6 +9974,10 @@ enum skl_power_gate {
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
-- 
2.7.4

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


[PATCH 3/3] [RFC] drm/i915/dp: DP PHY compliance for EHL/JSL

2020-09-03 Thread Vidya Srinivas
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.

v2: Rebased patch on top of Khaled's (yet to be merged):
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+

[PATCH 1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

2020-09-03 Thread Vidya Srinivas
From: Khaled Almahallawy 

Add the missing CP2520 pattern 2 and 3 phy compliance patterns

v2: cosemtic changes

Reviewed-by: Manasi Navare  (v1)
Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 include/drm/drm_dp_helper.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d0fb78c6aca6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
return err;
 
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
   >hbr2_reset,
   sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e2d2df5e869e..73285b4c25a0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -708,7 +708,9 @@
 # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
 # define DP_PHY_TEST_PATTERN_PRBS7  0x3
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT10x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT20x6
+# define DP_PHY_TEST_PATTERN_CP2520_PAT30x7
 
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
-- 
2.7.4

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


[PATCH 3/3] [RFC] drm/i915/dp: DP PHY compliance for EHL/JSL

2020-09-03 Thread Vidya Srinivas
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.

v2: Rebased patch on top of Khaled's (yet to be merged):
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+

[PATCH 2/3] drm/i915/dp: TPS4 PHY test pattern compliance support

2020-09-03 Thread Vidya Srinivas
From: Khaled Almahallawy 

Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.

v2: uniform bit names TP4a/b/c (Manasi)

Signed-off-by: Khaled Almahallawy 
Reviewed-by: Manasi Navare 
Tested-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 --
 drivers/gpu/drm/i915/i915_reg.h |  4 
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 04231ca5643b..a8a3ffcef5dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5403,7 +5403,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
-   u32 pattern_val;
+   u32 pattern_val, dp_tp_ctl;
 
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
@@ -5443,7 +5443,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
/*
 * FIXME: Ideally pattern should come from DPCD 0x24A. As
 * current firmware of DPR-100 could not set it, so hardcoding
@@ -5455,6 +5455,16 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
+   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
+   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
+   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   dp_tp_ctl = intel_de_read(dev_priv, 
TGL_DP_TP_CTL(pipe));
+   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
+   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
+   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
+   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
dp_tp_ctl);
+   break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab4b1abd4364..4850890918dc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9974,6 +9974,10 @@ enum skl_power_gate {
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
-- 
2.7.4

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


[PATCH 1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

2020-09-03 Thread Vidya Srinivas
From: Khaled Almahallawy 

Add the missing CP2520 pattern 2 and 3 phy compliance patterns

v2: cosemtic changes

Reviewed-by: Manasi Navare  (v1)
Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 include/drm/drm_dp_helper.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d0fb78c6aca6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
return err;
 
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
   >hbr2_reset,
   sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e2d2df5e869e..73285b4c25a0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -708,7 +708,9 @@
 # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
 # define DP_PHY_TEST_PATTERN_PRBS7  0x3
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT10x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT20x6
+# define DP_PHY_TEST_PATTERN_CP2520_PAT30x7
 
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
-- 
2.7.4

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


[PATCH] drm/i915/dp: DP PHY compliance for EHL/JSL

2020-09-03 Thread Vidya Srinivas
v2: Rebased patch on top of:
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
@@ -5478,22 +5498,32 @@ intel_dp_autotest_phy_ddi_disable(struct intel_dp 
*intel_dp)
struct 

[PATCH 1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

2020-09-03 Thread Vidya Srinivas
From: Khaled Almahallawy 

Add the missing CP2520 pattern 2 and 3 phy compliance patterns

v2: cosemtic changes

Reviewed-by: Manasi Navare  (v1)
Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 include/drm/drm_dp_helper.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d0fb78c6aca6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
return err;
 
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
   >hbr2_reset,
   sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e2d2df5e869e..73285b4c25a0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -708,7 +708,9 @@
 # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
 # define DP_PHY_TEST_PATTERN_PRBS7  0x3
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT10x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT20x6
+# define DP_PHY_TEST_PATTERN_CP2520_PAT30x7
 
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
-- 
2.7.4

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


[PATCH 3/3] [RFC] drm/i915/dp: DP PHY compliance for EHL/JSL

2020-09-03 Thread Vidya Srinivas
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.

v2: Rebased patch on top of Khaled's (yet to be merged):
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL

Signed-off-by: Khaled Almahallawy 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 81 +
 drivers/gpu/drm/i915/i915_reg.h | 18 ++--
 2 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a8a3ffcef5dc..1773f3d5d0f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5405,25 +5405,32 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
enum pipe pipe = crtc->pipe;
u32 pattern_val, dp_tp_ctl;
 
+   i915_reg_t dp_comp_reg;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   dp_comp_reg = EHL_DDI_DP_COMP_CTL(dig_port->base.port);
+   else if (IS_TIGERLAKE(dev_priv))
+   dp_comp_reg = DDI_DP_COMP_CTL(pipe);
+
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   intel_de_write(dev_priv, dp_comp_reg, 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
@@ -5432,14 +5439,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 * current firmware of DPR-100 could not set it, so hardcoding
 * now for complaince test.
 */
-   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 
0x0f83e0f8 0xf83e\n");
+   DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern \
+ 0x3e0f83e0 0x0f83e0f8 0xf83e\n");
pattern_val = 0x3e0f83e0;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 0),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), 
pattern_val);
pattern_val = 0x0f83e0f8;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 1),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), 
pattern_val);
pattern_val = 0xf83e;
-   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+   if (IS_ELKHARTLAKE(dev_priv))
+   intel_de_write(dev_priv, 
EHL_DDI_DP_COMP_PAT(dig_port->base.port, 2),
+  pattern_val);
+   else
+   intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), 
pattern_val);
+   intel_de_write(dev_priv, dp_comp_reg,
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
@@ -5451,7 +5471,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
 */
DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
-   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+

[PATCH 2/3] drm/i915/dp: TPS4 PHY test pattern compliance support

2020-09-03 Thread Vidya Srinivas
From: Khaled Almahallawy 

Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.

v2: uniform bit names TP4a/b/c (Manasi)

Signed-off-by: Khaled Almahallawy 
Reviewed-by: Manasi Navare 
Tested-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 --
 drivers/gpu/drm/i915/i915_reg.h |  4 
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 04231ca5643b..a8a3ffcef5dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5403,7 +5403,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
-   u32 pattern_val;
+   u32 pattern_val, dp_tp_ctl;
 
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
@@ -5443,7 +5443,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
/*
 * FIXME: Ideally pattern should come from DPCD 0x24A. As
 * current firmware of DPR-100 could not set it, so hardcoding
@@ -5455,6 +5455,16 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
+   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
+   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
+   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   dp_tp_ctl = intel_de_read(dev_priv, 
TGL_DP_TP_CTL(pipe));
+   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
+   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
+   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
+   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
dp_tp_ctl);
+   break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab4b1abd4364..4850890918dc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9974,6 +9974,10 @@ enum skl_power_gate {
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
-- 
2.7.4

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


[git pull] drm fixes for 5.9-rc4

2020-09-03 Thread Dave Airlie
Hi Linus,

Not much going on this week, nouveau has a display hw bug workaround,
amdgpu has some PM fixes and CIK regression fixes, one single radeon
PLL fix, and a couple of i915 display fixes.

Dave.

drm-fixes-2020-09-04:
drm fixes for 5.9-rc4

amdgpu:
- Fix for 32bit systems
- SW CTF fix
- Update for Sienna Cichlid
- CIK bug fixes

radeon:
- PLL fix

i915:
- Clang build warning fix
- HDCP fixes

nouveau:
- display fixes
The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:

  Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-04

for you to fetch changes up to d37d56920004cae612fa32d1f92aaacca5e145f7:

  Merge branch 'linux-5.9' of git://github.com/skeggsb/linux into
drm-fixes (2020-09-04 11:14:49 +1000)


drm fixes for 5.9-rc4

amdgpu:
- Fix for 32bit systems
- SW CTF fix
- Update for Sienna Cichlid
- CIK bug fixes

radeon:
- PLL fix

i915:
- Clang build warning fix
- HDCP fixes

nouveau:
- display fixes


Ben Skeggs (3):
  drm/nouveau/kms/nv50-: add some whitespace before debug message
  drm/nouveau/kms/nv50-gp1xx: disable notifies again after core update
  drm/nouveau/kms/nv50-gp1xx: add WAR for EVO push buffer HW bug

Dave Airlie (3):
  Merge tag 'amd-drm-fixes-5.9-2020-09-03' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2020-09-03' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'linux-5.9' of git://github.com/skeggsb/linux into drm-fixes

Evan Quan (1):
  drm/amd/pm: avoid false alarm due to confusing
softwareshutdowntemp setting

Jiansong Chen (1):
  drm/amd/pm: enable MP0 DPM for sienna_cichlid

Kai-Heng Feng (1):
  drm/radeon: Prefer lower feedback dividers

Kevin Wang (1):
  drm/amd/pm: fix is_dpm_running() run error on 32bit system

Lyude Paul (1):
  drm/nouveau/kms/gv100-: Include correct push header in crcc37d.c

Nathan Chancellor (1):
  drm/i915/display: Ensure that ret is always initialized in
icl_combo_phy_verify_state

Sandeep Raghuraman (2):
  drm/amdgpu: Specify get_argument function for ci_smu_funcs
  drm/amdgpu: Fix bug in reporting voltage for CIK

Sean Paul (2):
  drm/i915: Fix sha_text population code
  drm/i915: Clear the repeater bit on HDCP disable

 drivers/gpu/drm/amd/powerplay/arcturus_ppt.c   | 10 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  3 +-
 .../gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c   | 14 --
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 10 +--
 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c | 14 +++---
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c   |  2 ++
 drivers/gpu/drm/i915/display/intel_combo_phy.c |  4 +--
 drivers/gpu/drm/i915/display/intel_hdcp.c  | 32 ++
 drivers/gpu/drm/nouveau/dispnv50/core507d.c|  5 +++-
 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c|  6 
 drivers/gpu/drm/nouveau/include/nvif/push507c.h|  2 +-
 drivers/gpu/drm/radeon/radeon_display.c|  2 +-
 include/drm/drm_hdcp.h |  3 ++
 14 files changed, 84 insertions(+), 25 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge

2020-09-03 Thread Laurent Pinchart
Hi Tomi,

On Tue, Sep 01, 2020 at 10:46:03AM +0300, Tomi Valkeinen wrote:
> Hi Swapnil,
> 
> On 31/08/2020 11:23, Swapnil Jakhade wrote:
> 
> > +static int cdns_mhdp_validate_mode_params(struct cdns_mhdp_device *mhdp,
> > + const struct drm_display_mode *mode,
> > + struct drm_bridge_state *bridge_state)
> > +{
> > +   u32 tu_size = 30, line_thresh1, line_thresh2, line_thresh = 0;
> > +   u32 rate, vs, vs_f, required_bandwidth, available_bandwidth;
> > +   struct cdns_mhdp_bridge_state *state;
> > +   int pxlclock;
> > +   u32 bpp;
> > +
> > +   state = to_cdns_mhdp_bridge_state(bridge_state);
> > +
> > +   pxlclock = mode->crtc_clock;
> > +
> > +   /* Get rate in MSymbols per second per lane */
> > +   rate = mhdp->link.rate / 1000;
> > +
> > +   bpp = cdns_mhdp_get_bpp(>display_fmt);
> 
> None of the above are used when calling cdns_mhdp_bandwidth_ok(). For 
> clarity, I'd move the above
> lines a bit closer to where they are needed, as currently it makes me think 
> the above values are
> used when checking the bandwidth.
> 
> > +   if (!cdns_mhdp_bandwidth_ok(mhdp, mode, mhdp->link.num_lanes,
> > +   mhdp->link.rate)) {
> > +   dev_err(mhdp->dev, "%s: Not enough BW for %s (%u lanes at %u 
> > Mbps)\n",
> > +   __func__, mode->name, mhdp->link.num_lanes,
> > +   mhdp->link.rate / 100);
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* find optimal tu_size */
> > +   required_bandwidth = pxlclock * bpp / 8;
> > +   available_bandwidth = mhdp->link.num_lanes * rate;
> > +   do {
> > +   tu_size += 2;
> > +
> > +   vs_f = tu_size * required_bandwidth / available_bandwidth;
> > +   vs = vs_f / 1000;
> > +   vs_f = vs_f % 1000;
> > +   /* Downspreading is unused currently */
> > +   } while ((vs == 1 || ((vs_f > 850 || vs_f < 100) && vs_f != 0) ||
> > +tu_size - vs < 2) && tu_size < 64);
> > +
> > +   if (vs > 64) {
> > +   dev_err(mhdp->dev,
> > +   "%s: No space for framing %s (%u lanes at %u Mbps)\n",
> > +   __func__, mode->name, mhdp->link.num_lanes,
> > +   mhdp->link.rate / 100);
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (vs == tu_size)
> > +   vs = tu_size - 1;
> > +
> > +   line_thresh1 = ((vs + 1) << 5) * 8 / bpp;
> > +   line_thresh2 = (pxlclock << 5) / 1000 / rate * (vs + 1) - (1 << 5);
> > +   line_thresh = line_thresh1 - line_thresh2 / mhdp->link.num_lanes;
> > +   line_thresh = (line_thresh >> 5) + 2;
> > +
> > +   state->vs = vs;
> > +   state->tu_size = tu_size;
> > +   state->line_thresh = line_thresh;
> > +
> > +   return 0;
> > +}
> > +
> > +static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
> > + struct drm_bridge_state *bridge_state,
> > + struct drm_crtc_state *crtc_state,
> > + struct drm_connector_state *conn_state)
> > +{
> > +   struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
> > +   const struct drm_display_mode *mode = _state->adjusted_mode;
> > +   int ret;
> > +
> > +   mutex_lock(>link_mutex);
> > +
> > +   if (!mhdp->plugged) {
> > +   mhdp->link.rate = mhdp->host.link_rate;
> > +   mhdp->link.num_lanes = mhdp->host.lanes_cnt;
> > +   }
> > +
> > +   ret = cdns_mhdp_validate_mode_params(mhdp, mode, bridge_state);
> > +
> > +   mutex_unlock(>link_mutex);
> > +
> > +   return ret;
> > +}
> 
> Laurent mentioned that atomic_check should not change state. Note that
> cdns_mhdp_validate_mode_params also changes state, as it calculates tu_size, 
> vs and line_thresh.

.atomic_check() isn't allowed to change any global state, which means
both hardware state and data in cdns_mhdp_device. The drm_bridge_state
(and thus the cdns_mhdp_bridge_state) can be modified as it stores the
state for the atomic commit being checked.

> There seems to be issues with mode changes, but I think the first step would 
> be to clarify the
> related code a bit. cdns_mhdp_validate_mode_params() is misnamed, I think it 
> should be renamed to
> calculate_tu or something like that.
> 
> cdns_mhdp_bandwidth_ok() should take display_fmt or bpp as a parameter, as 
> currently it digs that up
> from the current state.
> 
> Probably cdns_mhdp_validate_mode_params() would be better if it doesn't write 
> the result to the
> state, but returns the values. That way it could also be used to verify if 
> suitable settings can be
> found, without changing the state.

This use case is actually a very good example of proper usage of the
atomic state :-) .atomic_check() has to perform computations to verify
the atomic commit, and storing the results in the commit's state
prevents duplicating the same calculation at .atomic_commit() time.

> The are two issues I see with some testing, which are probably related.
> 
> The first 

[PATCH 4/4] drm/msm: Disable the RPTR shadow

2020-09-03 Thread Jordan Crouse
Disable the RPTR shadow across all targets. It will be selectively
re-enabled later for targets that need it.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c   |  5 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 10 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 10 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 11 --
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  7 +++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 27 ++---
 6 files changed, 43 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 6021f8d9efd1..48fa49f69d6d 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -164,6 +164,11 @@ static int a2xx_hw_init(struct msm_gpu *gpu)
if (ret)
return ret;
 
+   gpu_write(gpu, REG_AXXX_CP_RB_CNTL,
+   MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
+   gpu_write(gpu, REG_AXXX_CP_RB_BASE, lower_32_bits(gpu->rb[0]->iova));
+
/* NOTE: PM4/micro-engine firmware registers look to be the same
 * for a2xx and a3xx.. we could possibly push that part down to
 * adreno_gpu base class.  Or push both PM4 and PFP but
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 0a5ea9f56cb8..f6471145a7a6 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -211,6 +211,16 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
if (ret)
return ret;
 
+   /*
+* Use the default ringbuffer size and block size but disable the RPTR
+* shadow
+*/
+   gpu_write(gpu, REG_AXXX_CP_RB_CNTL,
+   MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
+   /* Set the ringbuffer address */
+   gpu_write(gpu, REG_AXXX_CP_RB_BASE, lower_32_bits(gpu->rb[0]->iova));
+
/* setup access protection: */
gpu_write(gpu, REG_A3XX_CP_PROTECT_CTRL, 0x0007);
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index b9b26b2bf9c5..954753600625 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -267,6 +267,16 @@ static int a4xx_hw_init(struct msm_gpu *gpu)
if (ret)
return ret;
 
+   /*
+* Use the default ringbuffer size and block size but disable the RPTR
+* shadow
+*/
+   gpu_write(gpu, REG_A4XX_CP_RB_CNTL,
+   MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
+   /* Set the ringbuffer address */
+   gpu_write(gpu, REG_A4XX_CP_RB_BASE, lower_32_bits(gpu->rb[0]->iova));
+
/* Load PM4: */
ptr = (uint32_t *)(adreno_gpu->fw[ADRENO_FW_PM4]->data);
len = adreno_gpu->fw[ADRENO_FW_PM4]->size / 4;
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index e718f964d590..ce3c0b5c167b 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -703,8 +703,6 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
if (ret)
return ret;
 
-   a5xx_preempt_hw_init(gpu);
-
if (!adreno_is_a510(adreno_gpu))
a5xx_gpmu_ucode_init(gpu);
 
@@ -712,6 +710,15 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
if (ret)
return ret;
 
+   /* Set the ringbuffer address */
+   gpu_write64(gpu, REG_A5XX_CP_RB_BASE, REG_A5XX_CP_RB_BASE_HI,
+   gpu->rb[0]->iova);
+
+   gpu_write(gpu, REG_A5XX_CP_RB_CNTL,
+   MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
+   a5xx_preempt_hw_init(gpu);
+
/* Disable the interrupts through the initial bringup stage */
gpu_write(gpu, REG_A5XX_RBBM_INT_0_MASK, A5XX_INT_MASK);
 
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 406efaac95a7..74bc27eb4203 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -695,6 +695,13 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
if (ret)
goto out;
 
+   /* Set the ringbuffer address */
+   gpu_write64(gpu, REG_A6XX_CP_RB_BASE, REG_A6XX_CP_RB_BASE_HI,
+   gpu->rb[0]->iova);
+
+   gpu_write(gpu, REG_A6XX_CP_RB_CNTL,
+   MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
/* Always come up on rb 0 */
a6xx_gpu->cur_ring = gpu->rb[0];
 
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index d2dbb6968cba..459f10a3710b 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -400,26 +400,6 @@ int adreno_hw_init(struct msm_gpu *gpu)
ring->memptrs->rptr = 0;
}
 
-   /*
-* Setup REG_CP_RB_CNTL.  The same value is 

[PATCH 1/4] drm/msm: Split the a5xx preemption record

2020-09-03 Thread Jordan Crouse
The main a5xx preemption record can be marked as privileged to
protect it from user access but the counters storage needs to be
remain unprivileged. Split the buffers and mark the critical memory
as privileged.

Cc: sta...@vger.kernel.org
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  1 +
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 25 ++-
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
index 54868d4e3958..1e5b1a15a70f 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
@@ -31,6 +31,7 @@ struct a5xx_gpu {
struct msm_ringbuffer *next_ring;
 
struct drm_gem_object *preempt_bo[MSM_GPU_MAX_RINGS];
+   struct drm_gem_object *preempt_counters_bo[MSM_GPU_MAX_RINGS];
struct a5xx_preempt_record *preempt[MSM_GPU_MAX_RINGS];
uint64_t preempt_iova[MSM_GPU_MAX_RINGS];
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c 
b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
index 9cf9353a7ff1..9f3fe177b00e 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
@@ -226,19 +226,31 @@ static int preempt_init_ring(struct a5xx_gpu *a5xx_gpu,
struct adreno_gpu *adreno_gpu = _gpu->base;
struct msm_gpu *gpu = _gpu->base;
struct a5xx_preempt_record *ptr;
-   struct drm_gem_object *bo = NULL;
-   u64 iova = 0;
+   void *counters;
+   struct drm_gem_object *bo = NULL, *counters_bo = NULL;
+   u64 iova = 0, counters_iova = 0;
 
ptr = msm_gem_kernel_new(gpu->dev,
A5XX_PREEMPT_RECORD_SIZE + A5XX_PREEMPT_COUNTER_SIZE,
-   MSM_BO_UNCACHED, gpu->aspace, , );
+   MSM_BO_UNCACHED | MSM_BO_MAP_PRIV, gpu->aspace, , );
 
if (IS_ERR(ptr))
return PTR_ERR(ptr);
 
+   /* The buffer to store counters needs to be unprivileged */
+   counters = msm_gem_kernel_new(gpu->dev,
+   A5XX_PREEMPT_COUNTER_SIZE,
+   MSM_BO_UNCACHED, gpu->aspace, _bo, _iova);
+   if (IS_ERR(counters)) {
+   msm_gem_kernel_put(bo, gpu->aspace, true);
+   return PTR_ERR(counters);
+   }
+
msm_gem_object_set_name(bo, "preempt");
+   msm_gem_object_set_name(counters_bo, "preempt_counters");
 
a5xx_gpu->preempt_bo[ring->id] = bo;
+   a5xx_gpu->preempt_counters_bo[ring->id] = counters_bo;
a5xx_gpu->preempt_iova[ring->id] = iova;
a5xx_gpu->preempt[ring->id] = ptr;
 
@@ -249,7 +261,7 @@ static int preempt_init_ring(struct a5xx_gpu *a5xx_gpu,
ptr->data = 0;
ptr->cntl = MSM_GPU_RB_CNTL_DEFAULT;
ptr->rptr_addr = rbmemptr(ring, rptr);
-   ptr->counter = iova + A5XX_PREEMPT_RECORD_SIZE;
+   ptr->counter = counters_iova;
 
return 0;
 }
@@ -260,8 +272,11 @@ void a5xx_preempt_fini(struct msm_gpu *gpu)
struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
int i;
 
-   for (i = 0; i < gpu->nr_rings; i++)
+   for (i = 0; i < gpu->nr_rings; i++) {
msm_gem_kernel_put(a5xx_gpu->preempt_bo[i], gpu->aspace, true);
+   msm_gem_kernel_put(a5xx_gpu->preempt_counters_bo[i],
+   gpu->aspace, true);
+   }
 }
 
 void a5xx_preempt_init(struct msm_gpu *gpu)
-- 
2.25.1

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


[PATCH 2/4] drm/msm: Enable expanded apriv support for a650

2020-09-03 Thread Jordan Crouse
a650 supports expanded apriv support that allows us to map critical buffers
(ringbuffer and memstore) as as privileged to protect them from corruption.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c |  6 +-
 drivers/gpu/drm/msm/msm_gpu.c |  2 +-
 drivers/gpu/drm/msm/msm_gpu.h | 11 +++
 drivers/gpu/drm/msm/msm_ringbuffer.c  |  4 ++--
 4 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c5a3e4d4c007..406efaac95a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -678,7 +678,8 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
A6XX_PROTECT_RDONLY(0x980, 0x4));
gpu_write(gpu, REG_A6XX_CP_PROTECT(25), A6XX_PROTECT_RW(0xa630, 0x0));
 
-   if (adreno_is_a650(adreno_gpu)) {
+   /* Enable expanded apriv for targets that support it */
+   if (gpu->hw_apriv) {
gpu_write(gpu, REG_A6XX_CP_APRIV_CNTL,
(1 << 6) | (1 << 5) | (1 << 3) | (1 << 2) | (1 << 1));
}
@@ -1056,6 +1057,9 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = NULL;
adreno_gpu->reg_offsets = a6xx_register_offsets;
 
+   if (adreno_is_a650(adreno_gpu))
+   adreno_gpu->base.hw_apriv = true;
+
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index d5645472b25d..57ddc9438351 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -908,7 +908,7 @@ int msm_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
 
memptrs = msm_gem_kernel_new(drm,
sizeof(struct msm_rbmemptrs) * nr_rings,
-   MSM_BO_UNCACHED, gpu->aspace, >memptrs_bo,
+   check_apriv(gpu, MSM_BO_UNCACHED), gpu->aspace, 
>memptrs_bo,
_iova);
 
if (IS_ERR(memptrs)) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 0db117a7339b..37cffac4cbe3 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -15,6 +15,7 @@
 #include "msm_drv.h"
 #include "msm_fence.h"
 #include "msm_ringbuffer.h"
+#include "msm_gem.h"
 
 struct msm_gem_submit;
 struct msm_gpu_perfcntr;
@@ -139,6 +140,8 @@ struct msm_gpu {
} devfreq;
 
struct msm_gpu_state *crashstate;
+   /* True if the hardware supports expanded apriv (a650 and newer) */
+   bool hw_apriv;
 };
 
 /* It turns out that all targets use the same ringbuffer size */
@@ -327,4 +330,12 @@ static inline void msm_gpu_crashstate_put(struct msm_gpu 
*gpu)
mutex_unlock(>dev->struct_mutex);
 }
 
+/*
+ * Simple macro to semi-cleanly add the MAP_PRIV flag for targets that can
+ * support expanded privileges
+ */
+#define check_apriv(gpu, flags) \
+   (((gpu)->hw_apriv ? MSM_BO_MAP_PRIV : 0) | (flags))
+
+
 #endif /* __MSM_GPU_H__ */
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c 
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 39ecb5a18431..935bf9b1d941 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -27,8 +27,8 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu 
*gpu, int id,
ring->id = id;
 
ring->start = msm_gem_kernel_new(gpu->dev, MSM_GPU_RINGBUFFER_SZ,
-   MSM_BO_WC | MSM_BO_GPU_READONLY, gpu->aspace, >bo,
-   >iova);
+   check_apriv(gpu, MSM_BO_WC | MSM_BO_GPU_READONLY),
+   gpu->aspace, >bo, >iova);
 
if (IS_ERR(ring->start)) {
ret = PTR_ERR(ring->start);
-- 
2.25.1

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


[PATCH 0/4] drm/msm: Protect the RPTR shadow

2020-09-03 Thread Jordan Crouse
On Adreno GPUs there is an option to shadow the RPTR register in GPU accessible
memory. The shadow memory allows the kernel driver to query the value of the
RPTR for each ringbuffer even if it is preempted out or if the GPU is turned off
during aggressive power management.

There are risks to using the RPTR shadow. If it is in GPU accessible memory it
could be read or written by any GPU operation. All versions of the GPU hardware
except A650 requires the shadow to be in unprivileged memory which opens it
to risk.

This series does two things. First, it marks as many buffers as possible as
privileged. For a5xx these are some preemption buffers and on a650 this includes
all global buffers (such as the ringbuffer and memstore). I've sent these
patches before but they tie in well with this series so I've included them.

Then we disable the RPTR shadow across all targets. For all targets except for
a5xx the RPTR shadow isn't needed so there isn't a loss of functionality. a5xx
does need it for preemption so that has to be temporarily disabled.

Later changes will re-enable the shadow for those targets that can safely
mitigate the risks.

Jordan Crouse (4):
  drm/msm: Split the a5xx preemption record
  drm/msm: Enable expanded apriv support for a650
  drm/msm: Disable premption on all 5xx targets
  drm/msm: Disable the RPTR shadow

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c |  5 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 10 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 10 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 14 +---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  1 +
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 25 -
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 ++-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   | 27 ++-
 drivers/gpu/drm/msm/msm_gpu.c |  2 +-
 drivers/gpu/drm/msm/msm_gpu.h | 11 +
 drivers/gpu/drm/msm/msm_ringbuffer.c  |  4 ++--
 11 files changed, 85 insertions(+), 37 deletions(-)

-- 
2.25.1

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


[PATCH 3/4] drm/msm: Disable preemption on all 5xx targets

2020-09-03 Thread Jordan Crouse
Temporarily disable preemption on a5xx targets pending some improvements
to protect the RPTR shadow from being corrupted.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 9e63a190642c..e718f964d590 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1511,7 +1511,8 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
 
check_speed_bin(>dev);
 
-   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
+   /* Restricting nr_rings to 1 to temporarily disable preemption */
+   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
if (ret) {
a5xx_destroy(&(a5xx_gpu->base.base));
return ERR_PTR(ret);
-- 
2.25.1

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


[PATCH 0/1] Convert to using devm_drm_dev_alloc()

2020-09-03 Thread Luben Tuikov
This is based on top of Daniel's documentation
patch and it applies cleanly onto amd-staging-drm-next.
I'm also running this live.

Luben Tuikov (1):
  drm/amdgpu: Convert to using devm_drm_dev_alloc()

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

-- 
2.28.0.394.ge197136389

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


[PATCH 1/1] drm/amdgpu: Convert to using devm_drm_dev_alloc()

2020-09-03 Thread Luben Tuikov
Convert to using devm_drm_dev_alloc(),
as drm_dev_init() is going away.

Signed-off-by: Luben Tuikov 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 146a85c8df1c..06d994187c24 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1142,18 +1142,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
if (ret)
return ret;
 
-   adev = kzalloc(sizeof(*adev), GFP_KERNEL);
-   if (!adev)
-   return -ENOMEM;
+   adev = devm_drm_dev_alloc(>dev, _driver, typeof(*adev), ddev);
+   if (IS_ERR(adev))
+   return PTR_ERR(adev);
 
adev->dev  = >dev;
adev->pdev = pdev;
ddev = adev_to_drm(adev);
-   ret = drm_dev_init(ddev, _driver, >dev);
-   if (ret)
-   goto err_free;
-
-   drmm_add_final_kfree(ddev, adev);
 
if (!supports_atomic)
ddev->driver_features &= ~DRIVER_ATOMIC;
-- 
2.28.0.394.ge197136389

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


Re: [PATCH v5 0/7] make hdmi work on bananapi-r2

2020-09-03 Thread Chun-Kuang Hu
Frank Wunderlich  於 2020年9月3日 週四 下午11:07寫道:
>
> Hi
>
> Any opinion about DTS Patches? Which maintainer will include it in tree? Is 
> any ack/review needed?

According to maintainer list [1], the maintainer is

ARM/Mediatek SoC support
M: Matthias Brugger 
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L: linux-media...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
W: https://mtk.bcnfs.org/
C: irc://chat.freenode.net/linux-mediatek
F: arch/arm/boot/dts/mt6*
F: arch/arm/boot/dts/mt7*
F: arch/arm/boot/dts/mt8*
F: arch/arm/mach-mediatek/
F: arch/arm64/boot/dts/mediatek/
F: drivers/soc/mediatek/
N: mtk
N: mt[678]
K: mediatek


Regards,
Chun-Kuang.

[1] https://www.kernel.org/doc/linux/MAINTAINERS

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


[PATCH 3/4] drm/msm/dp: add debugfs nodes for video pattern tests

2020-09-03 Thread Abhinav Kumar
Add the debugfs nodes needed for the video pattern
compliance tests to MSM DP driver.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dp/dp_debug.c | 184 ++
 drivers/gpu/drm/msm/dp/dp_link.h  |  23 
 2 files changed, 207 insertions(+)

diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c 
b/drivers/gpu/drm/msm/dp/dp_debug.c
index 099e989f214d..16861aade93b 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.c
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -203,17 +203,174 @@ static ssize_t dp_debug_read_info(struct file *file, 
char __user *user_buff,
return -EINVAL;
 }
 
+static int dp_test_data_show(struct seq_file *m, void *data)
+{
+   struct drm_device *dev;
+   struct dp_debug_private *debug;
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+   u32 bpc;
+
+   debug = m->private;
+   dev = debug->drm_dev;
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+
+   if (connector->connector_type !=
+   DRM_MODE_CONNECTOR_DisplayPort)
+   continue;
+
+   if (connector->status == connector_status_connected) {
+   bpc = debug->link->test_video.test_bit_depth;
+   seq_printf(m, "hdisplay: %d\n",
+   debug->link->test_video.test_h_width);
+   seq_printf(m, "vdisplay: %d\n",
+   debug->link->test_video.test_v_height);
+   seq_printf(m, "bpc: %u\n",
+   dp_link_bit_depth_to_bpc(bpc));
+   } else
+   seq_puts(m, "0");
+   }
+
+   drm_connector_list_iter_end(_iter);
+
+   return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(dp_test_data);
+
+static int dp_test_type_show(struct seq_file *m, void *data)
+{
+   struct dp_debug_private *debug = m->private;
+   struct drm_device *dev = debug->drm_dev;
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+
+   if (connector->connector_type !=
+   DRM_MODE_CONNECTOR_DisplayPort)
+   continue;
+
+   if (connector->status == connector_status_connected)
+   seq_printf(m, "%02lx", DP_TEST_LINK_VIDEO_PATTERN);
+   else
+   seq_puts(m, "0");
+   }
+   drm_connector_list_iter_end(_iter);
+
+   return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(dp_test_type);
+
+static ssize_t dp_test_active_write(struct file *file,
+   const char __user *ubuf,
+   size_t len, loff_t *offp)
+{
+   char *input_buffer;
+   int status = 0;
+   struct dp_debug_private *debug;
+   struct drm_device *dev;
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+   int val = 0;
+
+   debug = ((struct seq_file *)file->private_data)->private;
+   dev = debug->drm_dev;
+
+   if (len == 0)
+   return 0;
+
+   input_buffer = memdup_user_nul(ubuf, len);
+   if (IS_ERR(input_buffer))
+   return PTR_ERR(input_buffer);
+
+   DRM_DEBUG_DRIVER("Copied %d bytes from user\n", (unsigned int)len);
+
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+   if (connector->connector_type !=
+   DRM_MODE_CONNECTOR_DisplayPort)
+   continue;
+
+   if (connector->status == connector_status_connected) {
+   status = kstrtoint(input_buffer, 10, );
+   if (status < 0)
+   break;
+   DRM_DEBUG_DRIVER("Got %d for test active\n", val);
+   /* To prevent erroneous activation of the compliance
+* testing code, only accept an actual value of 1 here
+*/
+   if (val == 1)
+   debug->panel->video_test = true;
+   else
+   debug->panel->video_test = false;
+   }
+   }
+   drm_connector_list_iter_end(_iter);
+   kfree(input_buffer);
+   if (status < 0)
+   return status;
+
+   *offp += len;
+   return len;
+}
+
+static int dp_test_active_show(struct seq_file *m, void *data)
+{
+   struct dp_debug_private *debug = m->private;
+   struct drm_device *dev = debug->drm_dev;
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+   if 

[PATCH 4/4] drm/msm/dp: remove mode hard-coding in case of DP CTS

2020-09-03 Thread Abhinav Kumar
No need to fix the number of resolutions to one during the video
pattern CTS test. The userspace test client will handle both
the hotplug as well as picking the right resolution for the test.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dp/dp_display.c |  3 --
 drivers/gpu/drm/msm/dp/dp_link.c|  2 +-
 drivers/gpu/drm/msm/dp/dp_panel.c   | 46 +
 3 files changed, 2 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 2c20898ce77b..bc6560e875aa 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -419,10 +419,7 @@ static int dp_display_usbpd_disconnect_cb(struct device 
*dev)
 static void dp_display_handle_video_request(struct dp_display_private *dp)
 {
if (dp->link->sink_request & DP_TEST_LINK_VIDEO_PATTERN) {
-   /* force disconnect followed by connect */
-   dp->usbpd->connect(dp->usbpd, false);
dp->panel->video_test = true;
-   dp->usbpd->connect(dp->usbpd, true);
dp_link_send_test_response(dp->link);
}
 }
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index 3cbae92deff0..ac0e1daea913 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -1059,8 +1059,8 @@ int dp_link_process_request(struct dp_link *dp_link)
}
 
if (dp_link_is_video_pattern_requested(link)) {
+   ret = 0;
dp_link->sink_request |= DP_TEST_LINK_VIDEO_PATTERN;
-   return -EINVAL;
}
 
if (dp_link_is_audio_pattern_requested(link)) {
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 7cdf37c525d8..1515217395a4 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -128,46 +128,6 @@ static u32 dp_panel_get_supported_bpp(struct dp_panel 
*dp_panel,
return bpp;
 }
 
-static void dp_panel_set_test_mode(struct dp_panel_private *panel,
-   struct dp_display_mode *mode)
-{
-   struct drm_display_mode *drm_mode = NULL;
-   struct dp_link_test_video *test_info = NULL;
-
-   drm_mode = >drm_mode;
-   test_info = >link->test_video;
-
-   drm_mode->hdisplay = test_info->test_h_width;
-   drm_mode->hsync_start = drm_mode->hdisplay + test_info->test_h_total -
-   (test_info->test_h_start + test_info->test_h_width);
-   drm_mode->hsync_end = drm_mode->hsync_start +
-   test_info->test_hsync_width;
-   drm_mode->htotal = drm_mode->hsync_end + test_info->test_h_start -
-   test_info->test_hsync_width;
-
-   drm_mode->vdisplay = test_info->test_v_height;
-   drm_mode->vsync_start = drm_mode->vdisplay + test_info->test_v_total -
-   (test_info->test_v_start + test_info->test_v_height);
-   drm_mode->vsync_end = drm_mode->vsync_start +
-   test_info->test_vsync_width;
-   drm_mode->vtotal = drm_mode->vsync_end + test_info->test_v_start -
-   test_info->test_vsync_width;
-
-   drm_mode->clock = test_info->test_h_total *
-   test_info->test_v_total * test_info->test_rr_n;
-
-   drm_mode->type = 0x48;
-   drm_mode_set_name(drm_mode);
-
-   if (test_info->test_rr_d == 0)
-   drm_mode->clock /= 1000;
-   else
-   drm_mode->clock /= 1001;
-
-   if (test_info->test_h_width == 640)
-   drm_mode->clock = 25170;
-}
-
 static int dp_panel_update_modes(struct drm_connector *connector,
struct edid *edid)
 {
@@ -294,12 +254,8 @@ int dp_panel_get_modes(struct dp_panel *dp_panel,
 
panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
 
-   if (dp_panel->video_test) {
-   dp_panel_set_test_mode(panel, mode);
-   return 1;
-   } else if (dp_panel->edid) {
+   if (dp_panel->edid)
return dp_panel_update_modes(connector, dp_panel->edid);
-   }
 
return 0;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH 1/4] drm/msm/dp: add debugfs support to DP driver

2020-09-03 Thread Abhinav Kumar
To prepare the MSM DP driver for running video pattern
compliance tests introduce debugfs module for it.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/Makefile|   3 +-
 drivers/gpu/drm/msm/dp/dp_debug.c   | 310 
 drivers/gpu/drm/msm/dp/dp_debug.h   |  71 +++
 drivers/gpu/drm/msm/dp/dp_display.c |  13 ++
 4 files changed, 396 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/msm/dp/dp_debug.c
 create mode 100644 drivers/gpu/drm/msm/dp/dp_debug.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index db1bdd35bbf5..c9dda1413c33 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -96,7 +96,8 @@ msm-y := \
msm_gpu_tracepoints.o \
msm_gpummu.o
 
-msm-$(CONFIG_DEBUG_FS) += adreno/a5xx_debugfs.o
+msm-$(CONFIG_DEBUG_FS) += adreno/a5xx_debugfs.o \
+   dp/dp_debug.o
 
 msm-$(CONFIG_DRM_MSM_GPU_STATE)+= adreno/a6xx_gpu_state.o
 
diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c 
b/drivers/gpu/drm/msm/dp/dp_debug.c
new file mode 100644
index ..92019f3e1a1f
--- /dev/null
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -0,0 +1,310 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2017-2020, The Linux Foundation. All rights reserved.
+ */
+
+#define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
+
+#include 
+#include 
+
+#include "dp_parser.h"
+#include "dp_catalog.h"
+#include "dp_aux.h"
+#include "dp_ctrl.h"
+#include "dp_debug.h"
+#include "dp_display.h"
+
+#define DEBUG_NAME "drm_dp"
+
+struct dp_debug_private {
+   struct dentry *root;
+
+   struct dp_usbpd *usbpd;
+   struct dp_link *link;
+   struct dp_panel *panel;
+   struct drm_connector **connector;
+   struct device *dev;
+
+   struct dp_debug dp_debug;
+};
+
+static int dp_debug_check_buffer_overflow(int rc, int *max_size, int *len)
+{
+   if (rc >= *max_size) {
+   DRM_ERROR("buffer overflow\n");
+   return -EINVAL;
+   }
+   *len += rc;
+   *max_size = SZ_4K - *len;
+
+   return 0;
+}
+
+static ssize_t dp_debug_read_info(struct file *file, char __user *user_buff,
+   size_t count, loff_t *ppos)
+{
+   struct dp_debug_private *debug = file->private_data;
+   char *buf;
+   u32 len = 0, rc = 0;
+   u64 lclk = 0;
+   u32 max_size = SZ_4K;
+   u32 link_params_rate;
+   struct drm_display_mode *drm_mode;
+
+   if (!debug)
+   return -ENODEV;
+
+   if (*ppos)
+   return 0;
+
+   buf = kzalloc(SZ_4K, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   drm_mode = >panel->dp_mode.drm_mode;
+
+   rc = snprintf(buf + len, max_size, "\tname = %s\n", DEBUG_NAME);
+   if (dp_debug_check_buffer_overflow(rc, _size, ))
+   goto error;
+
+   rc = snprintf(buf + len, max_size,
+   "\tdp_panel\n\t\tmax_pclk_khz = %d\n",
+   debug->panel->max_pclk_khz);
+   if (dp_debug_check_buffer_overflow(rc, _size, ))
+   goto error;
+
+   rc = snprintf(buf + len, max_size,
+   "\tdrm_dp_link\n\t\trate = %u\n",
+   debug->panel->link_info.rate);
+   if (dp_debug_check_buffer_overflow(rc, _size, ))
+   goto error;
+
+   rc = snprintf(buf + len, max_size,
+"\t\tnum_lanes = %u\n",
+   debug->panel->link_info.num_lanes);
+   if (dp_debug_check_buffer_overflow(rc, _size, ))
+   goto error;
+
+   rc = snprintf(buf + len, max_size,
+   "\t\tcapabilities = %lu\n",
+   debug->panel->link_info.capabilities);
+   if (dp_debug_check_buffer_overflow(rc, _size, ))
+   goto error;
+
+   rc = snprintf(buf + len, max_size,
+   "\tdp_panel_info:\n\t\tactive = %dx%d\n",
+   drm_mode->hdisplay,
+   drm_mode->vdisplay);
+   if (dp_debug_check_buffer_overflow(rc, _size, ))
+   goto error;
+
+   rc = snprintf(buf + len, max_size,
+   "\t\tback_porch = %dx%d\n",
+   drm_mode->htotal - drm_mode->hsync_end,
+   drm_mode->vtotal - drm_mode->vsync_end);
+   if (dp_debug_check_buffer_overflow(rc, _size, ))
+   goto error;
+
+   rc = snprintf(buf + len, max_size,
+   "\t\tfront_porch = %dx%d\n",
+   drm_mode->hsync_start - drm_mode->hdisplay,
+   drm_mode->vsync_start - drm_mode->vdisplay);
+   if (dp_debug_check_buffer_overflow(rc, _size, ))
+   goto error;
+
+   rc = snprintf(buf + len, max_size,
+   "\t\tsync_width = %dx%d\n",
+   drm_mode->hsync_end - drm_mode->hsync_start,
+   drm_mode->vsync_end - drm_mode->vsync_start);
+   if 

[PATCH 0/4] Add support for video pattern DP CTS to MSM DP

2020-09-03 Thread Abhinav Kumar
Add support for video pattern Display Port Compliance tests to
MSM DP driver. The userspace component of this shall be part of another
series in the igt mailing list.
This depends on series [1] , [2] and [3] which add basic Display Port
support to MSM chipsets.

[1] https://patchwork.kernel.org/project/dri-devel/list/?series=339847
[2] https://patchwork.kernel.org/project/dri-devel/list/?series=339997
[3] https://patchwork.kernel.org/project/dri-devel/list/?series=341175

Abhinav Kumar (4):
  drm/msm/dp: add debugfs support to DP driver
  drm/msm/dp: move debugfs node to /sys/kernel/debug/dri/*/
  drm/msm/dp: add debugfs nodes for video pattern tests
  drm/msm/dp: remove mode hard-coding in case of DP CTS

 drivers/gpu/drm/msm/Makefile|   3 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |   7 +
 drivers/gpu/drm/msm/dp/dp_debug.c   | 485 
 drivers/gpu/drm/msm/dp/dp_debug.h   |  74 
 drivers/gpu/drm/msm/dp/dp_display.c |  28 +-
 drivers/gpu/drm/msm/dp/dp_link.c|   2 +-
 drivers/gpu/drm/msm/dp/dp_link.h|  23 ++
 drivers/gpu/drm/msm/dp/dp_panel.c   |  46 +--
 drivers/gpu/drm/msm/msm_drv.h   |   2 +
 9 files changed, 617 insertions(+), 53 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dp/dp_debug.c
 create mode 100644 drivers/gpu/drm/msm/dp/dp_debug.h

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH 2/4] drm/msm/dp: move debugfs node to /sys/kernel/debug/dri/*/

2020-09-03 Thread Abhinav Kumar
Move the MSM DP debugfs node from /sys/kernel/debug/drm_dp
to /sys/kernel/debug/dri/*/ as required for video pattern
compliance test suite.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  7 +
 drivers/gpu/drm/msm/dp/dp_debug.c   | 31 --
 drivers/gpu/drm/msm/dp/dp_debug.h   |  5 +++-
 drivers/gpu/drm/msm/dp/dp_display.c | 34 +++--
 drivers/gpu/drm/msm/msm_drv.h   |  2 ++
 5 files changed, 44 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index bcb5ee50568c..db9e2761085b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -195,10 +195,15 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, 
struct drm_minor *minor)
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
void *p = dpu_hw_util_get_log_mask_ptr();
struct dentry *entry;
+   struct drm_device *dev;
+   struct msm_drm_private *priv;
 
if (!p)
return -EINVAL;
 
+   dev = dpu_kms->dev;
+   priv = dev->dev_private;
+
entry = debugfs_create_dir("debug", minor->debugfs_root);
 
debugfs_create_x32(DPU_DEBUGFS_HWMASKNAME, 0600, entry, p);
@@ -207,6 +212,8 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, struct 
drm_minor *minor)
dpu_debugfs_vbif_init(dpu_kms, entry);
dpu_debugfs_core_irq_init(dpu_kms, entry);
 
+   msm_dp_debugfs_init(priv->dp, minor);
+
return dpu_core_perf_debugfs_init(dpu_kms, entry);
 }
 #endif
diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c 
b/drivers/gpu/drm/msm/dp/dp_debug.c
index 92019f3e1a1f..099e989f214d 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.c
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 
 #include "dp_parser.h"
 #include "dp_catalog.h"
@@ -15,7 +16,7 @@
 #include "dp_debug.h"
 #include "dp_display.h"
 
-#define DEBUG_NAME "drm_dp"
+#define DEBUG_NAME "msm_dp"
 
 struct dp_debug_private {
struct dentry *root;
@@ -25,6 +26,7 @@ struct dp_debug_private {
struct dp_panel *panel;
struct drm_connector **connector;
struct device *dev;
+   struct drm_device *drm_dev;
 
struct dp_debug dp_debug;
 };
@@ -206,41 +208,29 @@ static const struct file_operations dp_debug_fops = {
.read = dp_debug_read_info,
 };
 
-static int dp_debug_init(struct dp_debug *dp_debug)
+static int dp_debug_init(struct dp_debug *dp_debug, struct drm_minor *minor)
 {
int rc = 0;
struct dp_debug_private *debug = container_of(dp_debug,
struct dp_debug_private, dp_debug);
-   struct dentry *dir, *file;
+   struct dentry *file;
 
-   dir = debugfs_create_dir(DEBUG_NAME, NULL);
-   if (IS_ERR_OR_NULL(dir)) {
-   rc = PTR_ERR(dir);
-   DRM_ERROR("[%s] debugfs create dir failed, rc = %d\n",
- DEBUG_NAME, rc);
-   goto error;
-   }
-
-   file = debugfs_create_file("dp_debug", 0444, dir,
+   file = debugfs_create_file("dp_debug", 0444, minor->debugfs_root,
debug, _debug_fops);
if (IS_ERR_OR_NULL(file)) {
rc = PTR_ERR(file);
DRM_ERROR("[%s] debugfs create file failed, rc=%d\n",
  DEBUG_NAME, rc);
-   goto error_remove_dir;
}
 
-   debug->root = dir;
-   return rc;
- error_remove_dir:
-   debugfs_remove(dir);
- error:
+   debug->root = minor->debugfs_root;
+
return rc;
 }
 
 struct dp_debug *dp_debug_get(struct device *dev, struct dp_panel *panel,
struct dp_usbpd *usbpd, struct dp_link *link,
-   struct drm_connector **connector)
+   struct drm_connector **connector, struct drm_minor *minor)
 {
int rc = 0;
struct dp_debug_private *debug;
@@ -263,6 +253,7 @@ struct dp_debug *dp_debug_get(struct device *dev, struct 
dp_panel *panel,
debug->link = link;
debug->panel = panel;
debug->dev = dev;
+   debug->drm_dev = minor->dev;
debug->connector = connector;
 
dp_debug = >dp_debug;
@@ -270,7 +261,7 @@ struct dp_debug *dp_debug_get(struct device *dev, struct 
dp_panel *panel,
dp_debug->hdisplay = 0;
dp_debug->vrefresh = 0;
 
-   rc = dp_debug_init(dp_debug);
+   rc = dp_debug_init(dp_debug, minor);
if (rc) {
devm_kfree(dev, debug);
goto error;
diff --git a/drivers/gpu/drm/msm/dp/dp_debug.h 
b/drivers/gpu/drm/msm/dp/dp_debug.h
index fddf827ac089..377e166fd0ea 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.h
+++ b/drivers/gpu/drm/msm/dp/dp_debug.h
@@ -35,6 +35,7 @@ struct dp_debug {
  * @usbpd: instance of usbpd module
  * @link: instance of link module
  * @connector: double pointer to display connector
+ * @minor: pointer to 

[pull] amdgpu, amdkfd, radeon, scheduler drm-next-5.10

2020-09-03 Thread Alex Deucher
Hi Dave, Daniel,

First batch of new stuff for 5.10.  Forgot to mention in the tag, switch
amdgpu from using drm_dev_alloc to drm_dev_init.  Will need a follow up
patch to switch to devm_drm_dev_alloc.

The following changes since commit 922e7455bb6122696b0420172700ea2b4e2f5739:

  Revert "drm/amd/display: Expose connector VRR range via debugfs" (2020-07-21 
20:21:30 -0400)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.10-2020-09-03

for you to fetch changes up to 11bc98bd71fe2e0cb572988519e51bca9d58a18a:

  drm/amdgpu/mmhub2.0: print client id string for mmhub (2020-09-03 14:48:34 
-0400)


amd-drm-next-5.10-2020-09-03:

amdgpu:
- RAS fixes
- Sienna Cichlid updates
- Navy Flounder updates
- DCE6 (SI) support in DC
- Enable plane rotation
- Rework pre-OS vram reservation handling during driver init
- Add standard interface to dump GPU metrics table from SMU
- Rework tiling and tmz state handling in atomic commits
- Pstate fixes
- Add voltage and power hwmon interfaces for renoir
- SW CTF fixes
- S/G display fix for Raven
- Print client strings for vmfaults for vega and newer
- Manual fan control fixes
- Display updates
- Reorg power management directory structure
- Misc bug fixes
- Misc code cleanups

amdkfd:
- Topology fixes
- Add SMI events for thermal throttling and GPU resets

radeon:
- switch from pci_* to dma_* for dma allocations
- PLL fix

Scheduler:
- Clean up priority levels

UAPI:
- amdgpu INFO IOCTL query update for TMZ state
  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6049
- amdkfd SMI event interface updates
  https://github.com/RadeonOpenCompute/rocm_smi_lib/tree/therm_thrott


Alex Deucher (50):
  drm/amdgpu/powerplay: add some documentation about memory clock
  drm/amdgpu: add some required DCE6 registers (v7)
  drm/amdgpu/si: initial support for GPU reset
  Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers"
  drm/amdgpu/smu: rework i2c adpater registration
  drm/amdgpu: handle bo size 0 in amdgpu_bo_create_kernel_at (v2)
  drm/amdgpu: use create_at for the stolen pre-OS buffer
  drm/amdgpu: use a define for the memory size of the vga emulator
  drm/amdgpu: move stolen vga bo from amdgpu to amdgpu.gmc
  drm/amdgpu: move keep stolen memory check into gmc core
  drm/amdgpu: add support for extended stolen vga memory
  drm/amdgpu/gmc: add new helper to get the FB size used by pre-OS console
  drm/amdgpu/gmc6: switch to using amdgpu_gmc_get_vbios_allocations
  drm/amdgpu/gmc7: switch to using amdgpu_gmc_get_vbios_allocations
  drm/amdgpu/gmc8: switch to using amdgpu_gmc_get_vbios_allocations
  drm/amdgpu/gmc9: switch to using amdgpu_gmc_get_vbios_allocations
  drm/amdgpu/gmc10: switch to using amdgpu_gmc_get_vbios_allocations
  drm/amdgpu: drop the CPU pointers for the stolen vga bos
  drm/amdgpu/gmc: disable keep_stolen_vga_memory on arcturus
  drm/amdgpu: move stolen memory from gmc to mman
  drm/amdgpu: move IP discovery data to mman
  drm/amdgpu: move vram usage by vbios to mman (v2)
  drm/amdgpu/display: drop unused function
  drm/amdgpu: print where we get the vbios image from
  drm/amdgpu: note what type of reset we are using
  drm/amdgpu: drop log message in amdgpu_dpm_baco_reset()
  drm/amdgpu/pm: remove duplicate check
  drm/amdgpu/swsmu: implement voltage metrics for RENOIR
  drm/amdgpu/swsmu: implement power metrics for RENOIR
  drm/amdgpu/pm: only hide average power on SI and pre-RENOIR APUs
  drm/amdgpu: fix up DCHUBBUB_SDPIF_MMIO_CNTRL_0 handling
  drm/amdgpu: add an asic callback for pre asic init
  drm/amdgpu: add pre_asic_init callback for SI
  drm/amdgpu: add pre_asic_init callback for CIK
  drm/amdgpu: add pre_asic_init callback for VI
  drm/amdgpu: add pre_asic_init callback for SOC15
  drm/amdgpu: add pre_asic_init callback for navi
  drm/amdgpu: add a wrapper for atom asic_init
  drm/amdgpu: report DC not supported if virtual display is enabled (v2)
  drm/amdgpu: Fix buffer overflow in INFO ioctl
  drm/amdgpu/swsmu: add new callback for getting fan parameters
  drm/amdgpu/swsmu: add get_fan_parameters callbacks for smu11 asics
  drm/amdgpu/swsmu: drop get_fan_speed_percent (v2)
  drm/amdgpu/swsmu: drop set_fan_speed_percent (v2)
  drm/amdgpu/swsmu: add smu11 helper to get manual fan speed (v2)
  drm/amdgpu/swsmu: handle manual fan readback on SMU11
  drm/amdgpu/gmc9: print client id string for gfxhub
  drm/amdgpu/gmc10: print client id string for gfxhub
  drm/amdgpu/gmc9: print client id string for mmhub
  drm/amdgpu/mmhub2.0: print client id string for mmhub

Alex Dewar (2):
  drm/amd/pm: Remove unnecessary cast
  drm/amd/pm: use kmemdup() rather than 

Re: [PATCH v2 22/23] drm/virtio: implement blob resources: resource create blob ioctl

2020-09-03 Thread Gurchetan Singh
On Thu, Sep 3, 2020 at 2:11 PM Chia-I Wu  wrote:

> On Wed, Sep 2, 2020 at 2:09 PM Gurchetan Singh
>  wrote:
> >
> > From: Gerd Hoffmann 
> >
> > Implement resource create blob as specified.
> >
> > Signed-off-by: Gerd Hoffmann 
> > Co-developed-by: Gurchetan Singh 
> > Signed-off-by: Gurchetan Singh 
> > Acked-by: Tomeu Vizoso 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_drv.h|   4 +-
> >  drivers/gpu/drm/virtio/virtgpu_ioctl.c  | 136 
> >  drivers/gpu/drm/virtio/virtgpu_object.c |   5 +-
> >  drivers/gpu/drm/virtio/virtgpu_vram.c   |   2 +
> >  4 files changed, 144 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > index 6162865c162df..d2ea199dbdb90 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > @@ -257,8 +257,8 @@ struct virtio_gpu_fpriv {
> > struct mutex context_lock;
> >  };
> >
> > -/* virtgpu_ioctl.c */
> > -#define DRM_VIRTIO_NUM_IOCTLS 10
> > +/* virtio_ioctl.c */
> > +#define DRM_VIRTIO_NUM_IOCTLS 11
> >  extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
> >  void virtio_gpu_create_context(struct drm_device *dev, struct drm_file
> *file);
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > index 7dbe24248a200..442cbca59c8a5 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > @@ -34,6 +34,10 @@
> >
> >  #include "virtgpu_drv.h"
> >
> > +#define VIRTGPU_BLOB_FLAG_USE_MASK (VIRTGPU_BLOB_FLAG_USE_MAPPABLE | \
> > +   VIRTGPU_BLOB_FLAG_USE_SHAREABLE | \
> > +   VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE)
> > +
> >  void virtio_gpu_create_context(struct drm_device *dev, struct drm_file
> *file)
> >  {
> > struct virtio_gpu_device *vgdev = dev->dev_private;
> > @@ -520,6 +524,134 @@ static int virtio_gpu_get_caps_ioctl(struct
> drm_device *dev,
> > return 0;
> >  }
> >
> > +static int verify_blob(struct virtio_gpu_device *vgdev,
> > +  struct virtio_gpu_fpriv *vfpriv,
> > +  struct virtio_gpu_object_params *params,
> > +  struct drm_virtgpu_resource_create_blob *rc_blob,
> > +  bool *guest_blob, bool *host3d_blob)
> > +{
> > +   if (!vgdev->has_resource_blob)
> > +   return -EINVAL;
> > +
> > +   if ((rc_blob->blob_flags & ~VIRTGPU_BLOB_FLAG_USE_MASK) ||
> > +   !rc_blob->blob_flags)
> > +   return -EINVAL;
> > +
> > +   if (rc_blob->blob_flags & VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE) {
> > +   if (!vgdev->has_resource_assign_uuid)
> > +   return -EINVAL;
> > +   }
> > +
> > +   switch (rc_blob->blob_mem) {
> > +   case VIRTGPU_BLOB_MEM_GUEST:
> > +   *guest_blob = true;
> > +   break;
> > +   case VIRTGPU_BLOB_MEM_HOST3D_GUEST:
> > +   *guest_blob = true;
> > +   fallthrough;
> > +   case VIRTGPU_BLOB_MEM_HOST3D:
> > +   *host3d_blob = true;
> > +   break;
> > +   default:
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (*host3d_blob) {
> > +   if (!vgdev->has_virgl_3d)
> > +   return -EINVAL;
> > +
> > +   /* Must be dword aligned. */
> > +   if (rc_blob->cmd_size % 4 != 0)
> > +   return -EINVAL;
> > +
> > +   params->ctx_id = vfpriv->ctx_id;
> > +   params->blob_id = rc_blob->blob_id;
> > +   } else {
> > +   if (rc_blob->blob_id != 0)
> > +   return -EINVAL;
> > +
> > +   if (rc_blob->cmd_size != 0)
> > +   return -EINVAL;
> > +   }
> > +
> > +   params->blob_mem = rc_blob->blob_mem;
> > +   params->size = rc_blob->size;
> > +   params->blob = true;
> > +   params->blob_flags = rc_blob->blob_flags;
> > +   return 0;
> > +}
> > +
> > +static int virtio_gpu_resource_create_blob(struct drm_device *dev,
> > +  void *data, struct drm_file
> *file)
> > +{
> > +   int ret = 0;
> > +   uint32_t handle = 0;
> > +   bool guest_blob = false;
> > +   bool host3d_blob = false;
> > +   struct drm_gem_object *obj;
> > +   struct virtio_gpu_object *bo;
> > +   struct virtio_gpu_object_params params = { 0 };
> > +   struct virtio_gpu_device *vgdev = dev->dev_private;
> > +   struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
> > +   struct drm_virtgpu_resource_create_blob *rc_blob = data;
> > +
> > +   if (verify_blob(vgdev, vfpriv, , rc_blob,
> > +   _blob, _blob))
> > +   return -EINVAL;
> > +
> > +   if (vgdev->has_virgl_3d)
> > +   

Re: [PATCH 01/16] drm/encoder: remove obsolete documentation of bridge

2020-09-03 Thread Laurent Pinchart
Hi Michael,

Thank you for the patch.

On Thu, Sep 03, 2020 at 06:57:02PM +0200, Michael Tretter wrote:
> In commit 05193dc38197 ("drm/bridge: Make the bridge chain a
> double-linked list") the bridge has been removed and replaced by a
> private field. Remove the leftover documentation of the removed field.
> 
> Signed-off-by: Michael Tretter 

Reviewed-by: Laurent Pinchart 

> ---
>  include/drm/drm_encoder.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> index a60f5f1555ac..5dfa5f7a80a7 100644
> --- a/include/drm/drm_encoder.h
> +++ b/include/drm/drm_encoder.h
> @@ -89,7 +89,6 @@ struct drm_encoder_funcs {
>   * @head: list management
>   * @base: base KMS object
>   * @name: human readable name, can be overwritten by the driver
> - * @bridge: bridge associated to the encoder
>   * @funcs: control functions
>   * @helper_private: mid-layer private data
>   *

-- 
Regards,

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


Re: [PATCH] drm/komeda: Drop local dma_parms

2020-09-03 Thread Robin Murphy

On 2020-09-03 21:36, Robin Murphy wrote:

Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.

Signed-off-by: Robin Murphy 
---

FYI, get_maintainer.pl seems to be choking on your L: entry somehow,
since it just shows " (open list:ARM KOMEDA DRM-KMS DRIVER)" without the
description or address, not sure what's up with that.

  drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 1 -
  drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 --
  2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 1d767473ba8a..e7bb905062d9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -261,7 +261,6 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
goto disable_clk;
}

-   dev->dma_parms = >dma_parms;
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));


Oops, I missed my "Also the DMA segment size is simply a size, not a 
bitmask" bit here - ideally this should be changed to UINT_MAX while 
we're cleaning up. Maybe that could just be fixed up when applying, but 
let me know if you'd like a resend.


Cheers,
Robin.


mdev->iommu = iommu_get_domain_for_dev(mdev->dev);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index ce27f2f27c24..5b536f0cb548 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -163,8 +163,6 @@ struct komeda_dev {
struct device *dev;
/** @reg_base: the base address of komeda io space */
u32 __iomem   *reg_base;
-   /** @dma_parms: the dma parameters of komeda */
-   struct device_dma_parameters dma_parms;

/** @chip: the basic chip information */
struct komeda_chip_info chip;
--
2.28.0.dirty
___
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 v2 22/23] drm/virtio: implement blob resources: resource create blob ioctl

2020-09-03 Thread Chia-I Wu
On Wed, Sep 2, 2020 at 2:09 PM Gurchetan Singh
 wrote:
>
> From: Gerd Hoffmann 
>
> Implement resource create blob as specified.
>
> Signed-off-by: Gerd Hoffmann 
> Co-developed-by: Gurchetan Singh 
> Signed-off-by: Gurchetan Singh 
> Acked-by: Tomeu Vizoso 
> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.h|   4 +-
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c  | 136 
>  drivers/gpu/drm/virtio/virtgpu_object.c |   5 +-
>  drivers/gpu/drm/virtio/virtgpu_vram.c   |   2 +
>  4 files changed, 144 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 6162865c162df..d2ea199dbdb90 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -257,8 +257,8 @@ struct virtio_gpu_fpriv {
> struct mutex context_lock;
>  };
>
> -/* virtgpu_ioctl.c */
> -#define DRM_VIRTIO_NUM_IOCTLS 10
> +/* virtio_ioctl.c */
> +#define DRM_VIRTIO_NUM_IOCTLS 11
>  extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
>  void virtio_gpu_create_context(struct drm_device *dev, struct drm_file 
> *file);
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 7dbe24248a200..442cbca59c8a5 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -34,6 +34,10 @@
>
>  #include "virtgpu_drv.h"
>
> +#define VIRTGPU_BLOB_FLAG_USE_MASK (VIRTGPU_BLOB_FLAG_USE_MAPPABLE | \
> +   VIRTGPU_BLOB_FLAG_USE_SHAREABLE | \
> +   VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE)
> +
>  void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file)
>  {
> struct virtio_gpu_device *vgdev = dev->dev_private;
> @@ -520,6 +524,134 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device 
> *dev,
> return 0;
>  }
>
> +static int verify_blob(struct virtio_gpu_device *vgdev,
> +  struct virtio_gpu_fpriv *vfpriv,
> +  struct virtio_gpu_object_params *params,
> +  struct drm_virtgpu_resource_create_blob *rc_blob,
> +  bool *guest_blob, bool *host3d_blob)
> +{
> +   if (!vgdev->has_resource_blob)
> +   return -EINVAL;
> +
> +   if ((rc_blob->blob_flags & ~VIRTGPU_BLOB_FLAG_USE_MASK) ||
> +   !rc_blob->blob_flags)
> +   return -EINVAL;
> +
> +   if (rc_blob->blob_flags & VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE) {
> +   if (!vgdev->has_resource_assign_uuid)
> +   return -EINVAL;
> +   }
> +
> +   switch (rc_blob->blob_mem) {
> +   case VIRTGPU_BLOB_MEM_GUEST:
> +   *guest_blob = true;
> +   break;
> +   case VIRTGPU_BLOB_MEM_HOST3D_GUEST:
> +   *guest_blob = true;
> +   fallthrough;
> +   case VIRTGPU_BLOB_MEM_HOST3D:
> +   *host3d_blob = true;
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   if (*host3d_blob) {
> +   if (!vgdev->has_virgl_3d)
> +   return -EINVAL;
> +
> +   /* Must be dword aligned. */
> +   if (rc_blob->cmd_size % 4 != 0)
> +   return -EINVAL;
> +
> +   params->ctx_id = vfpriv->ctx_id;
> +   params->blob_id = rc_blob->blob_id;
> +   } else {
> +   if (rc_blob->blob_id != 0)
> +   return -EINVAL;
> +
> +   if (rc_blob->cmd_size != 0)
> +   return -EINVAL;
> +   }
> +
> +   params->blob_mem = rc_blob->blob_mem;
> +   params->size = rc_blob->size;
> +   params->blob = true;
> +   params->blob_flags = rc_blob->blob_flags;
> +   return 0;
> +}
> +
> +static int virtio_gpu_resource_create_blob(struct drm_device *dev,
> +  void *data, struct drm_file *file)
> +{
> +   int ret = 0;
> +   uint32_t handle = 0;
> +   bool guest_blob = false;
> +   bool host3d_blob = false;
> +   struct drm_gem_object *obj;
> +   struct virtio_gpu_object *bo;
> +   struct virtio_gpu_object_params params = { 0 };
> +   struct virtio_gpu_device *vgdev = dev->dev_private;
> +   struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
> +   struct drm_virtgpu_resource_create_blob *rc_blob = data;
> +
> +   if (verify_blob(vgdev, vfpriv, , rc_blob,
> +   _blob, _blob))
> +   return -EINVAL;
> +
> +   if (vgdev->has_virgl_3d)
> +   virtio_gpu_create_context(dev, file);
> +
> +   if (rc_blob->cmd_size) {
> +   void *buf;
> +
> +   buf = memdup_user(u64_to_user_ptr(rc_blob->cmd),
> + rc_blob->cmd_size);
> +
> +   if (IS_ERR(buf))
> +   return PTR_ERR(buf);
> +
> 

[PATCH] drm/msm: Drop local dma_parms

2020-09-03 Thread Robin Murphy
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.

Also the DMA segment size is simply a size, not a bitmask.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/msm/msm_drv.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7d641c7e3514..2b73d29642b7 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -453,15 +453,7 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
if (ret)
goto err_msm_uninit;
 
-   if (!dev->dma_parms) {
-   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
- GFP_KERNEL);
-   if (!dev->dma_parms) {
-   ret = -ENOMEM;
-   goto err_msm_uninit;
-   }
-   }
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+   dma_set_max_seg_size(dev, UINT_MAX);
 
msm_gem_shrinker_init(ddev);
 
-- 
2.28.0.dirty

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


[PATCH] drm/mediatek: Drop local dma_parms

2020-09-03 Thread Robin Murphy
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.

Also the DMA segment size is simply a size, not a bitmask.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 23 +++
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |  2 --
 2 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 040a8f393fe2..3941f6f6b003 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -221,21 +221,10 @@ static int mtk_drm_kms_init(struct drm_device *drm)
 * Configure the DMA segment size to make sure we get contiguous IOVA
 * when importing PRIME buffers.
 */
-   if (!dma_dev->dma_parms) {
-   private->dma_parms_allocated = true;
-   dma_dev->dma_parms =
-   devm_kzalloc(drm->dev, sizeof(*dma_dev->dma_parms),
-GFP_KERNEL);
-   }
-   if (!dma_dev->dma_parms) {
-   ret = -ENOMEM;
-   goto err_component_unbind;
-   }
-
-   ret = dma_set_max_seg_size(dma_dev, (unsigned int)DMA_BIT_MASK(32));
+   ret = dma_set_max_seg_size(dma_dev, UINT_MAX);
if (ret) {
dev_err(dma_dev, "Failed to set DMA segment size\n");
-   goto err_unset_dma_parms;
+   goto err_component_unbind;
}
 
/*
@@ -246,16 +235,13 @@ static int mtk_drm_kms_init(struct drm_device *drm)
drm->irq_enabled = true;
ret = drm_vblank_init(drm, MAX_CRTC);
if (ret < 0)
-   goto err_unset_dma_parms;
+   goto err_component_unbind;
 
drm_kms_helper_poll_init(drm);
drm_mode_config_reset(drm);
 
return 0;
 
-err_unset_dma_parms:
-   if (private->dma_parms_allocated)
-   dma_dev->dma_parms = NULL;
 err_component_unbind:
component_unbind_all(drm->dev, drm);
 
@@ -269,9 +255,6 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
drm_kms_helper_poll_fini(drm);
drm_atomic_helper_shutdown(drm);
 
-   if (private->dma_parms_allocated)
-   private->dma_dev->dma_parms = NULL;
-
component_unbind_all(drm->dev, drm);
 }
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index b5be63e53176..6afd0b5f2b92 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -44,8 +44,6 @@ struct mtk_drm_private {
struct mtk_ddp_comp *ddp_comp[DDP_COMPONENT_ID_MAX];
const struct mtk_mmsys_driver_data *data;
struct drm_atomic_state *suspend_state;
-
-   bool dma_parms_allocated;
 };
 
 extern struct platform_driver mtk_ddp_driver;
-- 
2.28.0.dirty

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


[PATCH] drm/exynos: Drop local dma_parms

2020-09-03 Thread Robin Murphy
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.

Also the DMA segment size is simply a size, not a bitmask.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/exynos/exynos_drm_dma.c | 26 +
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c 
b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index 58b89ec11b0e..9f25a5ebbf7d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -31,23 +31,6 @@
 #define EXYNOS_DEV_ADDR_START  0x2000
 #define EXYNOS_DEV_ADDR_SIZE   0x4000
 
-static inline int configure_dma_max_seg_size(struct device *dev)
-{
-   if (!dev->dma_parms)
-   dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
-   if (!dev->dma_parms)
-   return -ENOMEM;
-
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-   return 0;
-}
-
-static inline void clear_dma_max_seg_size(struct device *dev)
-{
-   kfree(dev->dma_parms);
-   dev->dma_parms = NULL;
-}
-
 /*
  * drm_iommu_attach_device- attach device to iommu mapping
  *
@@ -69,9 +52,7 @@ static int drm_iommu_attach_device(struct drm_device *drm_dev,
return -EINVAL;
}
 
-   ret = configure_dma_max_seg_size(subdrv_dev);
-   if (ret)
-   return ret;
+   dma_set_max_seg_size(subdrv_dev, UINT_MAX);
 
if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)) {
/*
@@ -89,9 +70,6 @@ static int drm_iommu_attach_device(struct drm_device *drm_dev,
ret = iommu_attach_device(priv->mapping, subdrv_dev);
}
 
-   if (ret)
-   clear_dma_max_seg_size(subdrv_dev);
-
return ret;
 }
 
@@ -114,8 +92,6 @@ static void drm_iommu_detach_device(struct drm_device 
*drm_dev,
arm_iommu_attach_device(subdrv_dev, *dma_priv);
} else if (IS_ENABLED(CONFIG_IOMMU_DMA))
iommu_detach_device(priv->mapping, subdrv_dev);
-
-   clear_dma_max_seg_size(subdrv_dev);
 }
 
 int exynos_drm_register_dma(struct drm_device *drm, struct device *dev,
-- 
2.28.0.dirty

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


Re: [PATCH] drm/managed: Cleanup of unused functions and polishing docs

2020-09-03 Thread Luben Tuikov
On 2020-09-03 10:26 a.m., Daniel Vetter wrote:
> On Wed, Sep 02, 2020 at 09:26:27AM +0200, Daniel Vetter wrote:
>> Following functions are only used internally, not by drivers:
>> - devm_drm_dev_init
>>
>> Also, now that we have a very slick and polished way to allocate a
>> drm_device with devm_drm_dev_alloc, update all the docs to reflect the
>> new reality. Mostly this consists of deleting old and misleading
>> hints. Two main ones:
>>
>> - it is no longer required that the drm_device base class is first in
>>   the structure. devm_drm_dev_alloc can cope with it being anywhere
>>
>> - obviously embedded now strongly recommends using devm_drm_dev_alloc
>>
>> v2: Fix typos (Noralf)
>>
>> v3: Split out the removal of drm_dev_init, that's blocked on some
>> discussions on how to convert vgem/vkms/i915-selftests. Adjust commit
>> message to reflect that.
>>
>> Cc: Noralf Trønnes 
>> Acked-by: Noralf Trønnes  (v2)
>> Acked-by: Sam Ravnborg 
>> Cc: Luben Tuikov 
>> Cc: amd-...@lists.freedesktop.org
>> Signed-off-by: Daniel Vetter 
> 
> Ok pushed that now to drm-misc-next. I'm also working on getting the
> remaining bits of the basic drm managed conversion resubmitted. That was
> unfortunately massively sidelined for the dma-fence discussions.
> 
> Quick heads-up:
> drmm_add_final_kfree and drm_dev_init will both disappear, please use
> devm_drm_dev_alloc.

Hi Daniel,

In drm_drv.c, in the "DOC: driver instance overview" section,
it would help a lot, if you could add/summarize/clarify,
succinctly, the two paths, device instantiation:

devm_drm_dev_alloc(); ...
drm_dev_init(); ...
drm_dev_register(); ...

And, device destruction, and where/how the "release"
method of drm_driver plays out.

The allocation part is mostly there, that's good,
but the release/destruction part is not. That is,
the platform driver callbacks are there, but not
the DRM driver part. In this patch, there is no
mention of drm_dev_init(), and the documentation
update of this patch doesn't mention it, while
it is being used by at least one driver.

If, on the other hand, you're thinking of removing
the "release" callback, a lucid explanation on
kref reaching 0--what should be done by DRM
and what should be done by drivers, would be very nice
and helpful to low-level DRM device driver maintainers/writers.

Also, consider renaming "drm_add_action()" to something
qualifying the action: either a bitmask as an argument,
or right in the name, "drm_add_action_release()", else
one begs the question "What action?"

It would be helpful, to describe the order of "release"
actions on kref reaching 0, and what is expected of
DRM and what of drivers, in the order of the expected
callbacks.

Regards,
Luben


> 
> Cheers, Daniel
> 
>> ---
>>  .../driver-api/driver-model/devres.rst|  2 +-
>>  drivers/gpu/drm/drm_drv.c | 78 +--
>>  drivers/gpu/drm/drm_managed.c |  2 +-
>>  include/drm/drm_device.h  |  2 +-
>>  include/drm/drm_drv.h | 16 ++--
>>  5 files changed, 30 insertions(+), 70 deletions(-)
>>
>> diff --git a/Documentation/driver-api/driver-model/devres.rst 
>> b/Documentation/driver-api/driver-model/devres.rst
>> index efc21134..aa4d2420f79e 100644
>> --- a/Documentation/driver-api/driver-model/devres.rst
>> +++ b/Documentation/driver-api/driver-model/devres.rst
>> @@ -263,7 +263,7 @@ DMA
>>dmam_pool_destroy()
>>  
>>  DRM
>> -  devm_drm_dev_init()
>> +  devm_drm_dev_alloc()
>>  
>>  GPIO
>>devm_gpiod_get()
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index d4506f7a234e..7c1689842ec0 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -240,13 +240,13 @@ void drm_minor_release(struct drm_minor *minor)
>>   * DOC: driver instance overview
>>   *
>>   * A device instance for a drm driver is represented by  drm_device. 
>> This
>> - * is initialized with drm_dev_init(), usually from bus-specific ->probe()
>> - * callbacks implemented by the driver. The driver then needs to initialize 
>> all
>> - * the various subsystems for the drm device like memory management, vblank
>> - * handling, modesetting support and intial output configuration plus 
>> obviously
>> - * initialize all the corresponding hardware bits. Finally when everything 
>> is up
>> - * and running and ready for userspace the device instance can be published
>> - * using drm_dev_register().
>> + * is allocated and initialized with devm_drm_dev_alloc(), usually from
>> + * bus-specific ->probe() callbacks implemented by the driver. The driver 
>> then
>> + * needs to initialize all the various subsystems for the drm device like 
>> memory
>> + * management, vblank handling, modesetting support and initial output
>> + * configuration plus obviously initialize all the corresponding hardware 
>> bits.
>> + * Finally when everything is up and running and ready for userspace the 
>> device
>> + * 

[PATCH] drm/etnaviv: Drop local dma_parms

2020-09-03 Thread Robin Murphy
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index a9a3afaef9a1..79b3bcd9f444 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -535,7 +535,6 @@ static int etnaviv_bind(struct device *dev)
}
drm->dev_private = priv;
 
-   dev->dma_parms = >dma_parms;
dma_set_max_seg_size(dev, SZ_2G);
 
mutex_init(>gem_lock);
@@ -585,8 +584,6 @@ static void etnaviv_unbind(struct device *dev)
 
component_unbind_all(dev, drm);
 
-   dev->dma_parms = NULL;
-
etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
 
drm->dev_private = NULL;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 4d8dc9236e5f..7db607817c0c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -33,7 +33,6 @@ struct etnaviv_file_private {
 
 struct etnaviv_drm_private {
int num_gpus;
-   struct device_dma_parameters dma_parms;
struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
gfp_t shm_gfp_mask;
 
-- 
2.28.0.dirty

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


[PATCH] drm/komeda: Drop local dma_parms

2020-09-03 Thread Robin Murphy
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.

Signed-off-by: Robin Murphy 
---

FYI, get_maintainer.pl seems to be choking on your L: entry somehow,
since it just shows " (open list:ARM KOMEDA DRM-KMS DRIVER)" without the
description or address, not sure what's up with that.

 drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 1 -
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 1d767473ba8a..e7bb905062d9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -261,7 +261,6 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
goto disable_clk;
}

-   dev->dma_parms = >dma_parms;
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));

mdev->iommu = iommu_get_domain_for_dev(mdev->dev);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index ce27f2f27c24..5b536f0cb548 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -163,8 +163,6 @@ struct komeda_dev {
struct device *dev;
/** @reg_base: the base address of komeda io space */
u32 __iomem   *reg_base;
-   /** @dma_parms: the dma parameters of komeda */
-   struct device_dma_parameters dma_parms;

/** @chip: the basic chip information */
struct komeda_chip_info chip;
--
2.28.0.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 00/16] drm/exynos: Convert driver to drm bridge

2020-09-03 Thread Krzysztof Kozlowski
On Thu, 3 Sep 2020 at 18:57, Michael Tretter  wrote:
>
> Hello,
>
> the Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of
> the Exynos Decon. The driver for the LCDIF does not use the component
> framework, but uses drm bridges.
>
> This series converts the Exynos MIPI DSI into a drm bridge and makes it usable
> with such drivers. Although the driver is converted, it still supports the
> component framework API to stay compliant with the Exynos DRM driver.
>
> Unfortunately, I don't have any Exynos SoC to actually test the series.  I
> tested the driver with a few additional unfinished patches on the i.MX8M Mini
> EVK, but somebody should definitely verify that the driver is still working on
> Exynos hardware.

Hi Michael,

+Cc maintainers and folks in Samsung.

Please follow the script/get_maintainers.pl to get the list of
maintainers of the Exynos DRM drivers. First they could provide you
with testing, second they might be the people merging the driver.

Unfortunately I cannot provide proper testing as none of my boards
have a display attached. :)

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


[radeon-alex:amd-staging-drm-next 4/5] drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:272:15: warning: initialized field overwritten

2020-09-03 Thread kernel test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   d57d5c9c09cfb661eb0e8a9c41020aa71771dd7d
commit: e2ef6329fc53a026198a3788db088f85820690b6 [4/5] drm/amdgpu/gmc9: print 
client id string for mmhub
config: i386-randconfig-a012-20200902 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
git checkout e2ef6329fc53a026198a3788db088f85820690b6
# save the attached .config to linux build tree
make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:272:15: warning: initialized field 
>> overwritten [-Woverride-init]
 272 |  [32+15][1] = "SDMA1",
 |   ^~~
   drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:272:15: note: (near initialization for 
'mmhub_client_ids_arcturus[47][1]')
   drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:383:23: warning: 
'ecc_umc_mcumc_status_addrs' defined but not used [-Wunused-const-variable=]
 383 | static const uint32_t ecc_umc_mcumc_status_addrs[] = {
 |   ^~
   In file included from drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:29:
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:195:19: warning: 'no_system_mem_limit' 
defined but not used [-Wunused-const-variable=]
 195 | static const bool no_system_mem_limit;
 |   ^~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:194:19: warning: 'debug_evictions' 
defined but not used [-Wunused-const-variable=]
 194 | static const bool debug_evictions; /* = false */
 |   ^~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:193:18: warning: 'sched_policy' defined 
but not used [-Wunused-const-variable=]
 193 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
 |  ^~~~
   In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from 
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:65,
from drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:29:
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning: 
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
  76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
 |^~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning: 
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
  75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
 |^~~~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:74:32: warning: 
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
  74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
 |^~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:73:32: warning: 
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
  73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
 |^~~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:72:32: warning: 
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
  72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
 |^~~

git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next
git checkout e2ef6329fc53a026198a3788db088f85820690b6
vim +272 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c

   242  
   243  static const char *mmhub_client_ids_arcturus[][2] = {
   244  [2][0] = "MP1",
   245  [3][0] = "MP0",
   246  [10][0] = "UTCL2",
   247  [13][0] = "OSS",
   248  [14][0] = "HDP",
   249  [15][0] = "SDMA0",
   250  [32+15][0] = "SDMA1",
   251  [64+15][0] = "SDMA2",
   252  [96+15][0] = "SDMA3",
   253  [128+15][0] = "SDMA4",
   254  [160+11][0] = "JPEG",
   255  [160+12][0] = "VCN",
   256  [160+13][0] = "VCNU",
   257  [160+15][0] = "SDMA5",
   258  [192+10][0] = "UTCL2",
   259  [192+11][0] = "JPEG1",
   260  [192+12][0] = "VCN1",
   261  [192+13][0] = "VCN1U",
   262  [192+15][0] = "SDMA6",
   263  [224+15][0] = "SDMA7",
   264  [0][1] = "DBGU1",
   265  [1][1] = "XDP",
   266  [2][1] = "MP1",
   267  [3][1] = "MP0",
   268  [13][1] = "OSS",
   269  [14][1] = "HDP",
   270  [15][1] = "SDMA0",
   271

[PATCH v2 3/6] dt-bindings: gpu: arm, mali-utgard: Correct Maxime's email

2020-09-03 Thread Krzysztof Kozlowski
Update the address of Maxime Ripard as one in @free-electrons.com does
not work.

Cc: Maxime Ripard 
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Maxime Ripard 

---

Changes since v1:
1. Add Ack
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
index 30d421e6ba38..eceaa176bd57 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -8,7 +8,7 @@ title: ARM Mali Utgard GPU
 
 maintainers:
   - Rob Herring 
-  - Maxime Ripard 
+  - Maxime Ripard 
   - Heiko Stuebner 
 
 properties:
-- 
2.17.1

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


[PATCH v2 6/6] arm64: dts: exynos: Align OPP table name with dt-schema

2020-09-03 Thread Krzysztof Kozlowski
Device tree nodes should have hyphens instead of underscores.  This is
also expected by the bindings.

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. New patch
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index b2eebdd88c3c..9651bb9fdadc 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1087,7 +1087,7 @@
operating-points-v2 = <_opp_table>;
status = "disabled";
 
-   gpu_opp_table: opp_table {
+   gpu_opp_table: opp-table {
compatible = "operating-points-v2";
 
opp-16000 {
-- 
2.17.1

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


[PATCH v2 5/6] ARM: dts: exynos: Align OPP table name with dt-schema

2020-09-03 Thread Krzysztof Kozlowski
Device tree nodes should have hyphens instead of underscores.  This is
also expected by the bindings.

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. New patch
---
 arch/arm/boot/dts/exynos4412.dtsi | 16 
 arch/arm/boot/dts/exynos5250.dtsi |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index c74b1be12671..e76881dc0014 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -76,7 +76,7 @@
};
};
 
-   cpu0_opp_table: opp_table0 {
+   cpu0_opp_table: opp-table0 {
compatible = "operating-points-v2";
opp-shared;
 
@@ -402,7 +402,7 @@
status = "disabled";
};
 
-   bus_dmc_opp_table: opp_table1 {
+   bus_dmc_opp_table: opp-table1 {
compatible = "operating-points-v2";
opp-shared;
 
@@ -429,7 +429,7 @@
};
};
 
-   bus_acp_opp_table: opp_table2 {
+   bus_acp_opp_table: opp-table2 {
compatible = "operating-points-v2";
opp-shared;
 
@@ -495,7 +495,7 @@
status = "disabled";
};
 
-   bus_leftbus_opp_table: opp_table3 {
+   bus_leftbus_opp_table: opp-table3 {
compatible = "operating-points-v2";
opp-shared;
 
@@ -518,7 +518,7 @@
};
};
 
-   bus_display_opp_table: opp_table4 {
+   bus_display_opp_table: opp-table4 {
compatible = "operating-points-v2";
opp-shared;
 
@@ -530,7 +530,7 @@
};
};
 
-   bus_fsys_opp_table: opp_table5 {
+   bus_fsys_opp_table: opp-table5 {
compatible = "operating-points-v2";
opp-shared;
 
@@ -542,7 +542,7 @@
};
};
 
-   bus_peri_opp_table: opp_table6 {
+   bus_peri_opp_table: opp-table6 {
compatible = "operating-points-v2";
opp-shared;
 
@@ -734,7 +734,7 @@
  "pmu";
operating-points-v2 = <_opp_table>;
 
-   gpu_opp_table: opp_table {
+   gpu_opp_table: opp-table {
compatible = "operating-points-v2";
 
opp-16000 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index e09db3cecbff..bd2d8835dd36 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -330,7 +330,7 @@
power-domains = <_g3d>;
status = "disabled";
 
-   gpu_opp_table: gpu-opp-table {
+   gpu_opp_table: opp-table {
compatible = "operating-points-v2";
 
opp-1 {
-- 
2.17.1

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


[PATCH v2 4/6] dt-bindings: gpu: samsung-rotator: Add missing properties

2020-09-03 Thread Krzysztof Kozlowski
Add common properties appearing in DTSes (iommus, power-domains) to fix
dtbs_check warnings like:

  arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281:
'iommus', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+'

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Add properties instead of using unevaluated
---
 Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml 
b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
index 665c6e3b31d3..f480174fe0d3 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
+++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
@@ -22,6 +22,9 @@ properties:
   interrupts:
 maxItems: 1
 
+  iommus: true
+  power-domains: true
+
   clocks:
 maxItems: 1
 
-- 
2.17.1

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


[PATCH v2 2/6] dt-bindings: gpu: arm, mali-utgard: Add missing properties

2020-09-03 Thread Krzysztof Kozlowski
Add common properties appearing in DTSes (opp-table) to fix dtbs_check
warnings like:

  arch/arm/boot/dts/exynos4210-i9100.dt.yaml: gpu@1300:
'opp-table' does not match any of the regexes: 'pinctrl-[0-9]+'

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Add properties instead of using unevaluated
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
index d4d785790eaa..30d421e6ba38 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -101,6 +101,8 @@ properties:
 
   mali-supply: true
 
+  opp-table: true
+
   power-domains:
 maxItems: 1
 
-- 
2.17.1

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


[PATCH v2 1/6] dt-bindings: gpu: arm, mali-midgard: Add missing properties

2020-09-03 Thread Krzysztof Kozlowski
Add common properties appearing in DTSes (opp-table) to fix dtbs_check
warnings like:

  arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac:
'opp-table' does not match any of the regexes: 'pinctrl-[0-9]+'

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Add properties instead of using unevaluated
---
 Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index 80d519a76db2..e9c42b59f30f 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -74,6 +74,7 @@ properties:
   - const: bus
 
   mali-supply: true
+  opp-table: true
 
   power-domains:
 maxItems: 1
-- 
2.17.1

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


Re: [PATCH 0/3] Use implicit kref infra

2020-09-03 Thread Luben Tuikov
On 2020-09-02 9:57 p.m., Pan, Xinhui wrote:
> 
> 
>> 2020年9月2日 22:50,Tuikov, Luben  写道:
>>
>> On 2020-09-02 00:43, Pan, Xinhui wrote:
>>>
>>>
 2020年9月2日 11:46,Tuikov, Luben  写道:

 On 2020-09-01 21:42, Pan, Xinhui wrote:
> If you take a look at the below function, you should not use driver's 
> release to free adev. As dev is embedded in adev.

 Do you mean "look at the function below", using "below" as an adverb?
 "below" is not an adjective.

 I know dev is embedded in adev--I did that patchset.

>
> 809 static void drm_dev_release(struct kref *ref)
> 810 {
> 811 struct drm_device *dev = container_of(ref, struct drm_device, 
> ref);
> 812
> 813 if (dev->driver->release)
> 814 dev->driver->release(dev);
> 815 
> 816 drm_managed_release(dev);
> 817 
> 818 kfree(dev->managed.final_kfree);
> 819 }

 That's simple--this comes from change c6603c740e0e3
 and it should be reverted. Simple as that.

 The version before this change was absolutely correct:

 static void drm_dev_release(struct kref *ref)
 {
if (dev->driver->release)
dev->driver->release(dev);
else
drm_dev_fini(dev);
 }

 Meaning, "the kref is now 0"--> if the driver
 has a release, call it, else use our own.
 But note that nothing can be assumed after this point,
 about the existence of "dev".

 It is exactly because struct drm_device is statically
 embedded into a container, struct amdgpu_device,
 that this change above should be reverted.

 This is very similar to how fops has open/release
 but no close. That is, the "release" is called
 only when the last kref is released, i.e. when
 kref goes from non-zero to zero.

 This uses the kref infrastructure which has been
 around for about 20 years in the Linux kernel.

 I suggest reading the comments
 in drm_dev.c mostly, "DOC: driver instance overview"
 starting at line 240 onwards. This is right above
 drm_put_dev(). There is actually an example of a driver
 in the comment. Also the comment to drm_dev_init().

 Now, take a look at this:

 /**
 * drm_dev_put - Drop reference of a DRM device
 * @dev: device to drop reference of or NULL
 *
 * This decreases the ref-count of @dev by one. The device is destroyed if 
 the
 * ref-count drops to zero.
 */
 void drm_dev_put(struct drm_device *dev)
 {
   if (dev)
   kref_put(>ref, drm_dev_release);
 }
 EXPORT_SYMBOL(drm_dev_put);

 Two things:

 1. It is us, who kzalloc the amdgpu device, which contains
 the drm_device (you'll see this discussed in the reading
 material I pointed to above). We do this because we're
 probing the PCI device whether we'll work it it or not.

>>>
>>> that is true.
>>
>> Of course it's true--good morning!
>>
>>> My understanding of the drm core code is like something below.
>>
>> Let me stop you right there--just read the documentation I pointed
>> to you at.
>>
>>> struct B { 
>>> strcut A 
>>> }
>>> we initialize A firstly and initialize B in the end. But destroy B firstly 
>>> and destory A in the end.
>>
>> No!
>> B, which is the amdgpu_device struct "exists" before A, which is the DRM 
>> struct.
>> This is why DRM recommends to _embed_ it into the driver's own device struct,
>> as the documentation I pointed you to at.
>>
> I think you are misleading me here.  A pci dev as you said below can act as 
> many roles, a drm dev, a tty dev, etc.
> say, struct B{
> struct A;
> struct TTY;
> struct printer;
> ...
> }
> but TTY or other members has nothing to do with our discussion.
> 
> B of course exists before A. but the code logic is not that. code below is 
> really rare in drm world.
> create_B()
> {
>   init B members
>   return create_A()
> }
> So usually B have more work to do after it initialize A.
> then code should like below
> create_B()
> {
>   init B base members
>   create_A()
>   init B extended members
> }
> 
> 
> For release part.
> release B extended member
> release A
> release B base member
> 
> a good design should not have the so-called extended and base members 
> existing in the release process.
> Now have a look at the drm core code.
> it expects driver to do release process like below.
> release B
> cleanup work of A
> 
> as long as the cleanup work of A exists, we can not do a pure release of B.
> 
> So if you want to follow the ruls of kref, you have to rework the drm core 
> code first. only after that, we can do a pure release of B.
> 
> What I am confused is that, kfer sits in drm dev. why adev must be destroyed 
> too when drm dev is going to be destroyed.
> adev is not equal to drm dev.
> I think struct below is more fit for the logic.
> 

[PATCH 00/16] drm/exynos: Convert driver to drm bridge

2020-09-03 Thread Michael Tretter
Hello,

the Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of
the Exynos Decon. The driver for the LCDIF does not use the component
framework, but uses drm bridges.

This series converts the Exynos MIPI DSI into a drm bridge and makes it usable
with such drivers. Although the driver is converted, it still supports the
component framework API to stay compliant with the Exynos DRM driver.

Unfortunately, I don't have any Exynos SoC to actually test the series.  I
tested the driver with a few additional unfinished patches on the i.MX8M Mini
EVK, but somebody should definitely verify that the driver is still working on
Exynos hardware.

Patch 1 is a quick documentation fix.

Patches 2 to 6 implement the drm bridge interface.

Patches 7 to 12 rework the driver to make it easier to split platform specific
from common code.

Patches 13 and 14 add callbacks to handle the tearing effect interrupt and to
tell the Exynos DRM driver, if the MIPI DSI bridge is using command or video
mode. I am not too happy with these callbacks and any suggestion for a better
solution is very welcome.

Patches 15 and 16 finally split and move the drm bridge driver out of the
Exynos DRM driver.

Michael


Michael Tretter (16):
  drm/encoder: remove obsolete documentation of bridge
  drm/exynos: extract helper functions for probe
  drm/exynos: remove in_bridge_node from exynos_dsi
  drm/exynos: implement a drm bridge
  drm/exynos: convert encoder functions to bridge function
  drm/exynos: configure mode on drm bridge
  drm/exynos: get encoder from bridge whenever possible
  drm/exynos: use exynos_dsi as drvdata
  drm/exynos: call probe helper from bind
  drm/exynos: move dsi host registration to probe helper
  drm/exynos: shift register values to fields on write
  drm/exynos: use identifier instead of register offsets
  drm/exynos: add callback for tearing effect handler
  drm/exynos: add callback for enabling i80 mode
  drm/exynos: split out platform specific code
  drm/exynos: move bridge driver to bridges

 drivers/gpu/drm/bridge/Kconfig  |7 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/samsung-dsim.c   | 1797 ++
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1843 ++-
 include/drm/bridge/samsung-dsim.h   |   57 +
 include/drm/drm_encoder.h   |1 -
 6 files changed, 1967 insertions(+), 1739 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.20.1

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


[PATCH 01/16] drm/encoder: remove obsolete documentation of bridge

2020-09-03 Thread Michael Tretter
In commit 05193dc38197 ("drm/bridge: Make the bridge chain a
double-linked list") the bridge has been removed and replaced by a
private field. Remove the leftover documentation of the removed field.

Signed-off-by: Michael Tretter 
---
 include/drm/drm_encoder.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index a60f5f1555ac..5dfa5f7a80a7 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -89,7 +89,6 @@ struct drm_encoder_funcs {
  * @head: list management
  * @base: base KMS object
  * @name: human readable name, can be overwritten by the driver
- * @bridge: bridge associated to the encoder
  * @funcs: control functions
  * @helper_private: mid-layer private data
  *
-- 
2.20.1

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


[PATCH 08/16] drm/exynos: use exynos_dsi as drvdata

2020-09-03 Thread Michael Tretter
Use the exynos_dsi as drvdata instead of the encoder to further decouple
the driver from the encoder.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 51ec37304a69..2e8142464b74 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -290,11 +290,6 @@ struct exynos_dsi {
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
 #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
 
-static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
-{
-   return container_of(e, struct exynos_dsi, encoder);
-}
-
 enum reg_idx {
DSIM_STATUS_REG,/* Status register */
DSIM_SWRST_REG, /* Software reset register */
@@ -1738,8 +1733,8 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
 static int exynos_dsi_bind(struct device *dev, struct device *master,
void *data)
 {
-   struct drm_encoder *encoder = dev_get_drvdata(dev);
-   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
+   struct exynos_dsi *dsi = dev_get_drvdata(dev);
+   struct drm_encoder *encoder = >encoder;
struct drm_device *drm_dev = data;
struct device_node *in_bridge_node;
struct drm_bridge *in_bridge;
@@ -1769,8 +1764,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
 static void exynos_dsi_unbind(struct device *dev, struct device *master,
void *data)
 {
-   struct drm_encoder *encoder = dev_get_drvdata(dev);
-   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
+   struct exynos_dsi *dsi = dev_get_drvdata(dev);
 
exynos_dsi_disable(dsi);
 
@@ -1896,15 +1890,14 @@ static int exynos_dsi_probe(struct platform_device 
*pdev)
dsi = __exynos_dsi_probe(pdev);
if (IS_ERR(dsi))
return PTR_ERR(dsi);
-   platform_set_drvdata(pdev, >encoder);
+   platform_set_drvdata(pdev, dsi);
 
return component_add(>dev, _dsi_component_ops);
 }
 
 static int exynos_dsi_remove(struct platform_device *pdev)
 {
-   struct drm_encoder *encoder = platform_get_drvdata(pdev);
-   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
+   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
 
__exynos_dsi_remove(dsi);
 
@@ -1915,8 +1908,7 @@ static int exynos_dsi_remove(struct platform_device *pdev)
 
 static int __maybe_unused exynos_dsi_suspend(struct device *dev)
 {
-   struct drm_encoder *encoder = dev_get_drvdata(dev);
-   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
+   struct exynos_dsi *dsi = dev_get_drvdata(dev);
const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
int ret, i;
 
@@ -1946,8 +1938,7 @@ static int __maybe_unused exynos_dsi_suspend(struct 
device *dev)
 
 static int __maybe_unused exynos_dsi_resume(struct device *dev)
 {
-   struct drm_encoder *encoder = dev_get_drvdata(dev);
-   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
+   struct exynos_dsi *dsi = dev_get_drvdata(dev);
const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
int ret, i;
 
-- 
2.20.1

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


[PATCH 06/16] drm/exynos: configure mode on drm bridge

2020-09-03 Thread Michael Tretter
The driver uses the encoder to get the mode that shall be configured.
This is not possible, if the driver is used as a bridge, because the
encoder might not be used.

Use the mode_set function to get the display mode.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 31d62c10614a..657de5407190 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -275,6 +275,8 @@ struct exynos_dsi {
u32 mode_flags;
u32 format;
 
+   struct drm_display_mode mode;
+
int state;
struct drm_property *brightness;
struct completion completed;
@@ -883,7 +885,7 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 
 static void exynos_dsi_set_display_mode(struct exynos_dsi *dsi)
 {
-   struct drm_display_mode *m = >encoder.crtc->state->adjusted_mode;
+   struct drm_display_mode *m = >mode;
unsigned int num_bits_resol = dsi->driver_data->num_bits_resol;
u32 reg;
 
@@ -1544,10 +1546,21 @@ static void exynos_dsi_bridge_disable(struct drm_bridge 
*bridge)
exynos_dsi_disable(dsi);
 }
 
+static void exynos_dsi_bridge_mode_set(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode,
+  const struct drm_display_mode 
*adjusted_mode)
+{
+   struct exynos_dsi *dsi = bridge->driver_private;
+
+   /* The mode is set when actually enabling the device. */
+   drm_mode_copy(>mode, adjusted_mode);
+}
+
 static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
.attach = exynos_dsi_bridge_attach,
.enable = exynos_dsi_bridge_enable,
.disable = exynos_dsi_bridge_disable,
+   .mode_set = exynos_dsi_bridge_mode_set,
 };
 
 MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
-- 
2.20.1

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


[PATCH 03/16] drm/exynos: remove in_bridge_node from exynos_dsi

2020-09-03 Thread Michael Tretter
We do not need to keep a reference to the in_bridge_node, but we can
simply drop it, once we found and attached the previous bridge.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 32f999dfd8c1..ddbda33dea91 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -282,7 +282,6 @@ struct exynos_dsi {
struct list_head transfer_list;
 
const struct exynos_dsi_driver_data *driver_data;
-   struct device_node *in_bridge_node;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1687,8 +1686,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
 
-   dsi->in_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
-
return 0;
 }
 
@@ -1698,6 +1695,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
struct drm_encoder *encoder = dev_get_drvdata(dev);
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_device *drm_dev = data;
+   struct device_node *in_bridge_node;
struct drm_bridge *in_bridge;
int ret;
 
@@ -1709,10 +1707,12 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
if (ret < 0)
return ret;
 
-   if (dsi->in_bridge_node) {
-   in_bridge = of_drm_find_bridge(dsi->in_bridge_node);
+   in_bridge_node = of_graph_get_remote_node(dev->of_node, DSI_PORT_IN, 0);
+   if (in_bridge_node) {
+   in_bridge = of_drm_find_bridge(in_bridge_node);
if (in_bridge)
drm_bridge_attach(encoder, in_bridge, NULL, 0);
+   of_node_put(in_bridge_node);
}
 
return mipi_dsi_host_register(>dsi_host);
@@ -1828,8 +1828,6 @@ static struct exynos_dsi *__exynos_dsi_probe(struct 
platform_device *pdev)
 
 static void __exynos_dsi_remove(struct exynos_dsi *dsi)
 {
-   of_node_put(dsi->in_bridge_node);
-
pm_runtime_disable(dsi->dev);
 }
 
-- 
2.20.1

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


[PATCH 09/16] drm/exynos: call probe helper from bind

2020-09-03 Thread Michael Tretter
The probe shall only register the driver at the component framework. The
actual probing happens when the driver is bound.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 27 +
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2e8142464b74..7485097472dc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1730,16 +1730,26 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
return 0;
 }
 
+static struct exynos_dsi *__exynos_dsi_probe(struct platform_device *pdev);
+static void __exynos_dsi_remove(struct exynos_dsi *dsi);
+
 static int exynos_dsi_bind(struct device *dev, struct device *master,
void *data)
 {
-   struct exynos_dsi *dsi = dev_get_drvdata(dev);
-   struct drm_encoder *encoder = >encoder;
+   struct platform_device *pdev = to_platform_device(dev);
+   struct exynos_dsi *dsi;
+   struct drm_encoder *encoder;
struct drm_device *drm_dev = data;
struct device_node *in_bridge_node;
struct drm_bridge *in_bridge;
int ret;
 
+   dsi = __exynos_dsi_probe(pdev);
+   if (IS_ERR(dsi))
+   return PTR_ERR(dsi);
+   platform_set_drvdata(pdev, dsi);
+
+   encoder = >encoder;
drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
 
ret = exynos_drm_set_possible_crtcs(encoder, EXYNOS_DISPLAY_TYPE_LCD);
@@ -1768,6 +1778,8 @@ static void exynos_dsi_unbind(struct device *dev, struct 
device *master,
 
exynos_dsi_disable(dsi);
 
+   __exynos_dsi_remove(dsi);
+
mipi_dsi_host_unregister(>dsi_host);
 }
 
@@ -1885,22 +1897,11 @@ static void __exynos_dsi_remove(struct exynos_dsi *dsi)
 
 static int exynos_dsi_probe(struct platform_device *pdev)
 {
-   struct exynos_dsi *dsi;
-
-   dsi = __exynos_dsi_probe(pdev);
-   if (IS_ERR(dsi))
-   return PTR_ERR(dsi);
-   platform_set_drvdata(pdev, dsi);
-
return component_add(>dev, _dsi_component_ops);
 }
 
 static int exynos_dsi_remove(struct platform_device *pdev)
 {
-   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
-
-   __exynos_dsi_remove(dsi);
-
component_del(>dev, _dsi_component_ops);
 
return 0;
-- 
2.20.1

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


[PATCH 04/16] drm/exynos: implement a drm bridge

2020-09-03 Thread Michael Tretter
Make the exynos_dsi driver a full drm bridge that can be found and used
from other drivers.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 45 +++--
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index ddbda33dea91..4d19630f33e7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -253,6 +253,7 @@ struct exynos_dsi_driver_data {
 
 struct exynos_dsi {
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
struct drm_panel *panel;
@@ -1523,19 +1524,43 @@ static const struct drm_encoder_helper_funcs 
exynos_dsi_encoder_helper_funcs = {
.disable = exynos_dsi_disable,
 };
 
+static int exynos_dsi_bridge_attach(struct drm_bridge *bridge,
+   enum drm_bridge_attach_flags flags)
+{
+   struct exynos_dsi *dsi = bridge->driver_private;
+
+   if (!bridge->encoder) {
+   dev_err(dsi->dev, "missing encoder\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
+   .attach = exynos_dsi_bridge_attach,
+};
+
 MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
 
 static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
  struct mipi_dsi_device *device)
 {
struct exynos_dsi *dsi = host_to_dsi(host);
-   struct drm_encoder *encoder = >encoder;
-   struct drm_device *drm = encoder->dev;
+   struct drm_bridge *bridge = >bridge;
+   struct drm_encoder *encoder;
+   struct drm_device *drm;
struct drm_bridge *out_bridge;
 
+   if (!bridge->encoder)
+   return -EPROBE_DEFER;
+
+   encoder = bridge->encoder;
+   drm = encoder->dev;
+
out_bridge  = of_drm_find_bridge(device->dev.of_node);
if (out_bridge) {
-   drm_bridge_attach(encoder, out_bridge, NULL, 0);
+   drm_bridge_attach(encoder, out_bridge, bridge, 0);
dsi->out_bridge = out_bridge;
list_splice_init(>bridge_chain, >bridge_chain);
} else {
@@ -1715,6 +1740,10 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
of_node_put(in_bridge_node);
}
 
+   ret = drm_bridge_attach(encoder, >bridge, in_bridge, 0);
+   if (ret)
+   return ret;
+
return mipi_dsi_host_register(>dsi_host);
 }
 
@@ -1740,6 +1769,7 @@ static struct exynos_dsi *__exynos_dsi_probe(struct 
platform_device *pdev)
struct resource *res;
struct exynos_dsi *dsi;
int ret, i;
+   struct drm_bridge *bridge;
 
dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
@@ -1823,11 +1853,20 @@ static struct exynos_dsi *__exynos_dsi_probe(struct 
platform_device *pdev)
 
pm_runtime_enable(dev);
 
+   bridge = >bridge;
+   bridge->driver_private = dsi;
+   bridge->funcs = _dsi_bridge_funcs;
+   bridge->of_node = dev->of_node;
+
+   drm_bridge_add(bridge);
+
return dsi;
 }
 
 static void __exynos_dsi_remove(struct exynos_dsi *dsi)
 {
+   drm_bridge_remove(>bridge);
+
pm_runtime_disable(dsi->dev);
 }
 
-- 
2.20.1

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


[PATCH 14/16] drm/exynos: add callback for enabling i80 mode

2020-09-03 Thread Michael Tretter
Display controllers need to know if the MIPI DSI bridge is running in
command or video mode. Allow platform drivers to register a callback for
being notified about the used mode.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 993402f1f7c7..a9dac66c834f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -255,6 +255,7 @@ struct exynos_dsi_driver_data {
unsigned int num_bits_resol;
const unsigned int *reg_values;
void (*te_handler)(struct drm_encoder *encoder);
+   void (*set_command_node)(struct drm_encoder *encoder, bool enable);
 };
 
 struct exynos_dsi {
@@ -471,6 +472,19 @@ static void exynos_dsi_te_handler(struct drm_encoder 
*encoder)
exynos_drm_crtc_te_handler(encoder->crtc);
 }
 
+static void exynos_dsi_set_command_mode(struct drm_encoder *encoder,
+   bool enable)
+{
+   struct drm_device *drm = encoder->dev;
+   struct exynos_drm_crtc *crtc;
+
+   crtc = exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD);
+   if (IS_ERR(crtc))
+   return;
+
+   crtc->i80_mode = enable;
+}
+
 static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
.reg_ofs = EXYNOS_REG_OFS,
.plltmr_reg = 0x50,
@@ -482,6 +496,7 @@ static const struct exynos_dsi_driver_data 
exynos3_dsi_driver_data = {
.num_bits_resol = 11,
.reg_values = reg_values,
.te_handler = exynos_dsi_te_handler,
+   .set_command_node = exynos_dsi_set_command_mode,
 };
 
 static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
@@ -495,6 +510,7 @@ static const struct exynos_dsi_driver_data 
exynos4_dsi_driver_data = {
.num_bits_resol = 11,
.reg_values = reg_values,
.te_handler = exynos_dsi_te_handler,
+   .set_command_node = exynos_dsi_set_command_mode,
 };
 
 static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
@@ -506,6 +522,7 @@ static const struct exynos_dsi_driver_data 
exynos5_dsi_driver_data = {
.num_bits_resol = 11,
.reg_values = reg_values,
.te_handler = exynos_dsi_te_handler,
+   .set_command_node = exynos_dsi_set_command_mode,
 };
 
 static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
@@ -518,6 +535,7 @@ static const struct exynos_dsi_driver_data 
exynos5433_dsi_driver_data = {
.num_bits_resol = 12,
.reg_values = exynos5433_reg_values,
.te_handler = exynos_dsi_te_handler,
+   .set_command_node = exynos_dsi_set_command_mode,
 };
 
 static const struct exynos_dsi_driver_data exynos5422_dsi_driver_data = {
@@ -530,6 +548,7 @@ static const struct exynos_dsi_driver_data 
exynos5422_dsi_driver_data = {
.num_bits_resol = 12,
.reg_values = exynos5422_reg_values,
.te_handler = exynos_dsi_te_handler,
+   .set_command_node = exynos_dsi_set_command_mode,
 };
 
 static const struct of_device_id exynos_dsi_of_match[] = {
@@ -1651,8 +1670,9 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host 
*host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
-   exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
-   !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
+   if (dsi->driver_data->set_command_node)
+   dsi->driver_data->set_command_node(encoder,
+   !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO));
 
mutex_unlock(>mode_config.mutex);
 
-- 
2.20.1

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


[PATCH 13/16] drm/exynos: add callback for tearing effect handler

2020-09-03 Thread Michael Tretter
The tearing effect interrupts are not handled by the MIPI DSI bridge
driver, but the display controller driver.

Allow platforms to register a callback for the tearing effect interrupt.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 287bc6e9b3ca..993402f1f7c7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,6 +254,7 @@ struct exynos_dsi_driver_data {
unsigned int wait_for_reset;
unsigned int num_bits_resol;
const unsigned int *reg_values;
+   void (*te_handler)(struct drm_encoder *encoder);
 };
 
 struct exynos_dsi {
@@ -465,6 +466,11 @@ static const unsigned int exynos5433_reg_values[] = {
[PHYTIMING_HS_TRAIL] = 0x0c,
 };
 
+static void exynos_dsi_te_handler(struct drm_encoder *encoder)
+{
+   exynos_drm_crtc_te_handler(encoder->crtc);
+}
+
 static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
.reg_ofs = EXYNOS_REG_OFS,
.plltmr_reg = 0x50,
@@ -475,6 +481,7 @@ static const struct exynos_dsi_driver_data 
exynos3_dsi_driver_data = {
.wait_for_reset = 1,
.num_bits_resol = 11,
.reg_values = reg_values,
+   .te_handler = exynos_dsi_te_handler,
 };
 
 static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
@@ -487,6 +494,7 @@ static const struct exynos_dsi_driver_data 
exynos4_dsi_driver_data = {
.wait_for_reset = 1,
.num_bits_resol = 11,
.reg_values = reg_values,
+   .te_handler = exynos_dsi_te_handler,
 };
 
 static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
@@ -497,6 +505,7 @@ static const struct exynos_dsi_driver_data 
exynos5_dsi_driver_data = {
.wait_for_reset = 1,
.num_bits_resol = 11,
.reg_values = reg_values,
+   .te_handler = exynos_dsi_te_handler,
 };
 
 static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
@@ -508,6 +517,7 @@ static const struct exynos_dsi_driver_data 
exynos5433_dsi_driver_data = {
.wait_for_reset = 0,
.num_bits_resol = 12,
.reg_values = exynos5433_reg_values,
+   .te_handler = exynos_dsi_te_handler,
 };
 
 static const struct exynos_dsi_driver_data exynos5422_dsi_driver_data = {
@@ -519,6 +529,7 @@ static const struct exynos_dsi_driver_data 
exynos5422_dsi_driver_data = {
.wait_for_reset = 1,
.num_bits_resol = 12,
.reg_values = exynos5422_reg_values,
+   .te_handler = exynos_dsi_te_handler,
 };
 
 static const struct of_device_id exynos_dsi_of_match[] = {
@@ -1305,11 +1316,13 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
 
 static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 {
-   struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
+   struct exynos_dsi *dsi = dev_id;
+   const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
struct drm_encoder *encoder = dsi->bridge.encoder;
 
-   if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
-   exynos_drm_crtc_te_handler(encoder->crtc);
+   if (driver_data->te_handler &&
+   (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE))
+   driver_data->te_handler(encoder);
 
return IRQ_HANDLED;
 }
-- 
2.20.1

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


[PATCH 10/16] drm/exynos: move dsi host registration to probe helper

2020-09-03 Thread Michael Tretter
The bind/unbind API will be only used with the component framework, but
the mipi dsi host is always required. Therefore, move it to the shared
probe helper function.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7485097472dc..3bf4ae0fe6cc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1768,7 +1768,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
if (ret)
return ret;
 
-   return mipi_dsi_host_register(>dsi_host);
+   return 0;
 }
 
 static void exynos_dsi_unbind(struct device *dev, struct device *master,
@@ -1779,8 +1779,6 @@ static void exynos_dsi_unbind(struct device *dev, struct 
device *master,
exynos_dsi_disable(dsi);
 
__exynos_dsi_remove(dsi);
-
-   mipi_dsi_host_unregister(>dsi_host);
 }
 
 static const struct component_ops exynos_dsi_component_ops = {
@@ -1878,6 +1876,10 @@ static struct exynos_dsi *__exynos_dsi_probe(struct 
platform_device *pdev)
 
pm_runtime_enable(dev);
 
+   ret = mipi_dsi_host_register(>dsi_host);
+   if (ret)
+   return ERR_PTR(ret);
+
bridge = >bridge;
bridge->driver_private = dsi;
bridge->funcs = _dsi_bridge_funcs;
@@ -1892,6 +1894,8 @@ static void __exynos_dsi_remove(struct exynos_dsi *dsi)
 {
drm_bridge_remove(>bridge);
 
+   mipi_dsi_host_unregister(>dsi_host);
+
pm_runtime_disable(dsi->dev);
 }
 
-- 
2.20.1

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


[PATCH 15/16] drm/exynos: split out platform specific code

2020-09-03 Thread Michael Tretter
Split the driver into the drm bridge driver and the exynos platform
specific driver.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/Makefile   |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 312 ++
 drivers/gpu/drm/exynos/exynos_drm_dsi.h   |  57 
 drivers/gpu/drm/exynos/exynos_drm_dsi_pltfm.c | 307 +
 4 files changed, 393 insertions(+), 285 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.h
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi_pltfm.c

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 2fd2f3ee4fcf..add70b336935 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -11,7 +11,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS5433_DECON)   += exynos5433_drm_decon.o
 exynosdrm-$(CONFIG_DRM_EXYNOS7_DECON)  += exynos7_drm_decon.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DPI) += exynos_drm_dpi.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o 
exynos_drm_dsi_pltfm.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DP)  += exynos_dp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)   += exynos_mixer.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index a9dac66c834f..a6ff6326e8f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -32,8 +32,7 @@
 #include 
 #include 
 
-#include "exynos_drm_crtc.h"
-#include "exynos_drm_drv.h"
+#include "exynos_drm_dsi.h"
 
 /* returns true iff both arguments logically differs */
 #define NEQV(a, b) (!(a) ^ !(b))
@@ -44,10 +43,6 @@
 #define DSIM_TX_READY_HS_CLK   (1 << 10)
 #define DSIM_PLL_STABLE(1 << 31)
 
-/* DSIM_SWRST */
-#define DSIM_FUNCRST   (1 << 16)
-#define DSIM_SWRST (1 << 0)
-
 /* DSIM_TIMEOUT */
 #define DSIM_LPDR_TIMEOUT(x)   ((x) << 0)
 #define DSIM_BTA_TIMEOUT(x)((x) << 16)
@@ -239,25 +234,6 @@ struct exynos_dsi_transfer {
 #define DSIM_STATE_CMD_LPM BIT(2)
 #define DSIM_STATE_VIDOUT_AVAILABLEBIT(3)
 
-enum exynos_reg_offset {
-   EXYNOS_REG_OFS,
-   EXYNOS5433_REG_OFS
-};
-
-struct exynos_dsi_driver_data {
-   enum exynos_reg_offset reg_ofs;
-   unsigned int plltmr_reg;
-   unsigned int has_freqband:1;
-   unsigned int has_clklane_stop:1;
-   unsigned int num_clks;
-   unsigned int max_freq;
-   unsigned int wait_for_reset;
-   unsigned int num_bits_resol;
-   const unsigned int *reg_values;
-   void (*te_handler)(struct drm_encoder *encoder);
-   void (*set_command_node)(struct drm_encoder *encoder, bool enable);
-};
-
 struct exynos_dsi {
struct drm_encoder encoder;
struct drm_bridge bridge;
@@ -395,176 +371,6 @@ static inline u32 exynos_dsi_read(struct exynos_dsi *dsi, 
enum reg_idx idx)
return readl(dsi->reg_base + reg_ofs[idx]);
 }
 
-enum reg_value_idx {
-   RESET_TYPE,
-   PLL_TIMER,
-   STOP_STATE_CNT,
-   PHYCTRL_ULPS_EXIT,
-   PHYCTRL_VREG_LP,
-   PHYCTRL_SLEW_UP,
-   PHYTIMING_LPX,
-   PHYTIMING_HS_EXIT,
-   PHYTIMING_CLK_PREPARE,
-   PHYTIMING_CLK_ZERO,
-   PHYTIMING_CLK_POST,
-   PHYTIMING_CLK_TRAIL,
-   PHYTIMING_HS_PREPARE,
-   PHYTIMING_HS_ZERO,
-   PHYTIMING_HS_TRAIL
-};
-
-static const unsigned int reg_values[] = {
-   [RESET_TYPE] = DSIM_SWRST,
-   [PLL_TIMER] = 500,
-   [STOP_STATE_CNT] = 0xf,
-   [PHYCTRL_ULPS_EXIT] = 0x0af,
-   [PHYCTRL_VREG_LP] = 0,
-   [PHYCTRL_SLEW_UP] = 0,
-   [PHYTIMING_LPX] = 0x06,
-   [PHYTIMING_HS_EXIT] = 0x0b,
-   [PHYTIMING_CLK_PREPARE] = 0x07,
-   [PHYTIMING_CLK_ZERO] = 0x27,
-   [PHYTIMING_CLK_POST] = 0x0d,
-   [PHYTIMING_CLK_TRAIL] = 0x08,
-   [PHYTIMING_HS_PREPARE] = 0x09,
-   [PHYTIMING_HS_ZERO] = 0x0d,
-   [PHYTIMING_HS_TRAIL] = 0x0b,
-};
-
-static const unsigned int exynos5422_reg_values[] = {
-   [RESET_TYPE] = DSIM_SWRST,
-   [PLL_TIMER] = 500,
-   [STOP_STATE_CNT] = 0xf,
-   [PHYCTRL_ULPS_EXIT] = 0xaf,
-   [PHYCTRL_VREG_LP] = 0,
-   [PHYCTRL_SLEW_UP] = 0,
-   [PHYTIMING_LPX] = 0x08,
-   [PHYTIMING_HS_EXIT] = 0x0d,
-   [PHYTIMING_CLK_PREPARE] = 0x09,
-   [PHYTIMING_CLK_ZERO] = 0x30,
-   [PHYTIMING_CLK_POST] = 0x0e,
-   [PHYTIMING_CLK_TRAIL] = 0x0a,
-   [PHYTIMING_HS_PREPARE] = 0x0c,
-   [PHYTIMING_HS_ZERO] = 0x11,
-   [PHYTIMING_HS_TRAIL] = 0x0d,
-};
-
-static const unsigned int exynos5433_reg_values[] = {
-   [RESET_TYPE] = DSIM_FUNCRST,
-   [PLL_TIMER] = 22200,
-   [STOP_STATE_CNT] = 0xa,
-   [PHYCTRL_ULPS_EXIT] = 0x190,
-   [PHYCTRL_VREG_LP] = 1,
-   [PHYCTRL_SLEW_UP] = 1,
-   [PHYTIMING_LPX] = 

[PATCH 12/16] drm/exynos: use identifier instead of register offsets

2020-09-03 Thread Michael Tretter
Different revisions of the MIPI-DSI PHY have slightly different register
layouts. Currently, the register layout was stored per platform, which
makes it necessary to define the layout for each new platform.

Keep the register layout in the driver and use identifiers to specify
which register layout shall be used on a platform.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 54 -
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 21db18ae0772..287bc6e9b3ca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -239,8 +239,13 @@ struct exynos_dsi_transfer {
 #define DSIM_STATE_CMD_LPM BIT(2)
 #define DSIM_STATE_VIDOUT_AVAILABLEBIT(3)
 
+enum exynos_reg_offset {
+   EXYNOS_REG_OFS,
+   EXYNOS5433_REG_OFS
+};
+
 struct exynos_dsi_driver_data {
-   const unsigned int *reg_ofs;
+   enum exynos_reg_offset reg_ofs;
unsigned int plltmr_reg;
unsigned int has_freqband:1;
unsigned int has_clklane_stop:1;
@@ -315,18 +320,6 @@ enum reg_idx {
NUM_REGS
 };
 
-static inline void exynos_dsi_write(struct exynos_dsi *dsi, enum reg_idx idx,
-   u32 val)
-{
-
-   writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
-}
-
-static inline u32 exynos_dsi_read(struct exynos_dsi *dsi, enum reg_idx idx)
-{
-   return readl(dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
-}
-
 static const unsigned int exynos_reg_ofs[] = {
[DSIM_STATUS_REG] =  0x00,
[DSIM_SWRST_REG] =  0x04,
@@ -375,6 +368,31 @@ static const unsigned int exynos5433_reg_ofs[] = {
[DSIM_PHYTIMING2_REG] = 0xBC,
 };
 
+static inline void exynos_dsi_write(struct exynos_dsi *dsi, enum reg_idx idx,
+   u32 val)
+{
+   const unsigned int *reg_ofs;
+
+   if (dsi->driver_data->reg_ofs == EXYNOS5433_REG_OFS)
+   reg_ofs = exynos5433_reg_ofs;
+   else
+   reg_ofs = exynos_reg_ofs;
+
+   writel(val, dsi->reg_base + reg_ofs[idx]);
+}
+
+static inline u32 exynos_dsi_read(struct exynos_dsi *dsi, enum reg_idx idx)
+{
+   const unsigned int *reg_ofs;
+
+   if (dsi->driver_data->reg_ofs == EXYNOS5433_REG_OFS)
+   reg_ofs = exynos5433_reg_ofs;
+   else
+   reg_ofs = exynos_reg_ofs;
+
+   return readl(dsi->reg_base + reg_ofs[idx]);
+}
+
 enum reg_value_idx {
RESET_TYPE,
PLL_TIMER,
@@ -448,7 +466,7 @@ static const unsigned int exynos5433_reg_values[] = {
 };
 
 static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
-   .reg_ofs = exynos_reg_ofs,
+   .reg_ofs = EXYNOS_REG_OFS,
.plltmr_reg = 0x50,
.has_freqband = 1,
.has_clklane_stop = 1,
@@ -460,7 +478,7 @@ static const struct exynos_dsi_driver_data 
exynos3_dsi_driver_data = {
 };
 
 static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
-   .reg_ofs = exynos_reg_ofs,
+   .reg_ofs = EXYNOS_REG_OFS,
.plltmr_reg = 0x50,
.has_freqband = 1,
.has_clklane_stop = 1,
@@ -472,7 +490,7 @@ static const struct exynos_dsi_driver_data 
exynos4_dsi_driver_data = {
 };
 
 static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
-   .reg_ofs = exynos_reg_ofs,
+   .reg_ofs = EXYNOS_REG_OFS,
.plltmr_reg = 0x58,
.num_clks = 2,
.max_freq = 1000,
@@ -482,7 +500,7 @@ static const struct exynos_dsi_driver_data 
exynos5_dsi_driver_data = {
 };
 
 static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
-   .reg_ofs = exynos5433_reg_ofs,
+   .reg_ofs = EXYNOS5433_REG_OFS,
.plltmr_reg = 0xa0,
.has_clklane_stop = 1,
.num_clks = 5,
@@ -493,7 +511,7 @@ static const struct exynos_dsi_driver_data 
exynos5433_dsi_driver_data = {
 };
 
 static const struct exynos_dsi_driver_data exynos5422_dsi_driver_data = {
-   .reg_ofs = exynos5433_reg_ofs,
+   .reg_ofs = EXYNOS5433_REG_OFS,
.plltmr_reg = 0xa0,
.has_clklane_stop = 1,
.num_clks = 2,
-- 
2.20.1

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


[PATCH 02/16] drm/exynos: extract helper functions for probe

2020-09-03 Thread Michael Tretter
As the driver shall be usable with drivers that use the component
framework and drivers that don't, split the common probing code into a
separate function that can be called from different locations.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 54 ++---
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index b38e9b592b8a..32f999dfd8c1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1734,7 +1734,7 @@ static const struct component_ops 
exynos_dsi_component_ops = {
.unbind = exynos_dsi_unbind,
 };
 
-static int exynos_dsi_probe(struct platform_device *pdev)
+static struct exynos_dsi *__exynos_dsi_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct resource *res;
@@ -1743,7 +1743,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 
dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
 
/* To be checked as invalid one */
dsi->te_gpio = -ENOENT;
@@ -1766,14 +1766,14 @@ static int exynos_dsi_probe(struct platform_device 
*pdev)
if (ret) {
if (ret != -EPROBE_DEFER)
dev_info(dev, "failed to get regulators: %d\n", ret);
-   return ret;
+   return ERR_PTR(ret);
}
 
dsi->clks = devm_kcalloc(dev,
dsi->driver_data->num_clks, sizeof(*dsi->clks),
GFP_KERNEL);
if (!dsi->clks)
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
 
for (i = 0; i < dsi->driver_data->num_clks; i++) {
dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
@@ -1787,7 +1787,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 
dev_info(dev, "failed to get the clock: %s\n",
clk_names[i]);
-   return PTR_ERR(dsi->clks[i]);
+   return ERR_PTR(PTR_ERR(dsi->clks[i]));
}
}
 
@@ -1795,18 +1795,18 @@ static int exynos_dsi_probe(struct platform_device 
*pdev)
dsi->reg_base = devm_ioremap_resource(dev, res);
if (IS_ERR(dsi->reg_base)) {
dev_err(dev, "failed to remap io region\n");
-   return PTR_ERR(dsi->reg_base);
+   return dsi->reg_base;
}
 
dsi->phy = devm_phy_get(dev, "dsim");
if (IS_ERR(dsi->phy)) {
dev_info(dev, "failed to get dsim phy\n");
-   return PTR_ERR(dsi->phy);
+   return ERR_PTR(PTR_ERR(dsi->phy));
}
 
dsi->irq = platform_get_irq(pdev, 0);
if (dsi->irq < 0)
-   return dsi->irq;
+   return ERR_PTR(dsi->irq);
 
irq_set_status_flags(dsi->irq, IRQ_NOAUTOEN);
ret = devm_request_threaded_irq(dev, dsi->irq, NULL,
@@ -1814,37 +1814,43 @@ static int exynos_dsi_probe(struct platform_device 
*pdev)
dev_name(dev), dsi);
if (ret) {
dev_err(dev, "failed to request dsi irq\n");
-   return ret;
+   return ERR_PTR(ret);
}
 
ret = exynos_dsi_parse_dt(dsi);
if (ret)
-   return ret;
-
-   platform_set_drvdata(pdev, >encoder);
+   return ERR_PTR(ret);
 
pm_runtime_enable(dev);
 
-   ret = component_add(dev, _dsi_component_ops);
-   if (ret)
-   goto err_disable_runtime;
-
-   return 0;
+   return dsi;
+}
 
-err_disable_runtime:
-   pm_runtime_disable(dev);
+static void __exynos_dsi_remove(struct exynos_dsi *dsi)
+{
of_node_put(dsi->in_bridge_node);
 
-   return ret;
+   pm_runtime_disable(dsi->dev);
 }
 
-static int exynos_dsi_remove(struct platform_device *pdev)
+static int exynos_dsi_probe(struct platform_device *pdev)
 {
-   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
+   struct exynos_dsi *dsi;
 
-   of_node_put(dsi->in_bridge_node);
+   dsi = __exynos_dsi_probe(pdev);
+   if (IS_ERR(dsi))
+   return PTR_ERR(dsi);
+   platform_set_drvdata(pdev, >encoder);
+
+   return component_add(>dev, _dsi_component_ops);
+}
+
+static int exynos_dsi_remove(struct platform_device *pdev)
+{
+   struct drm_encoder *encoder = platform_get_drvdata(pdev);
+   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
 
-   pm_runtime_disable(>dev);
+   __exynos_dsi_remove(dsi);
 
component_del(>dev, _dsi_component_ops);
 
-- 
2.20.1

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


[PATCH 11/16] drm/exynos: shift register values to fields on write

2020-09-03 Thread Michael Tretter
The phy timings are already shifted to the field position. If the driver
is reused on multiple platforms, this exposes the field positions to the
platform code.

Store only the timing values in the platform data and shift the value to
the field when writing the fields to the registers.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 88 +
 1 file changed, 46 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 3bf4ae0fe6cc..21db18ae0772 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -397,54 +397,54 @@ static const unsigned int reg_values[] = {
[RESET_TYPE] = DSIM_SWRST,
[PLL_TIMER] = 500,
[STOP_STATE_CNT] = 0xf,
-   [PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x0af),
+   [PHYCTRL_ULPS_EXIT] = 0x0af,
[PHYCTRL_VREG_LP] = 0,
[PHYCTRL_SLEW_UP] = 0,
-   [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
-   [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
-   [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
-   [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x27),
-   [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
-   [PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
-   [PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x09),
-   [PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
-   [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+   [PHYTIMING_LPX] = 0x06,
+   [PHYTIMING_HS_EXIT] = 0x0b,
+   [PHYTIMING_CLK_PREPARE] = 0x07,
+   [PHYTIMING_CLK_ZERO] = 0x27,
+   [PHYTIMING_CLK_POST] = 0x0d,
+   [PHYTIMING_CLK_TRAIL] = 0x08,
+   [PHYTIMING_HS_PREPARE] = 0x09,
+   [PHYTIMING_HS_ZERO] = 0x0d,
+   [PHYTIMING_HS_TRAIL] = 0x0b,
 };
 
 static const unsigned int exynos5422_reg_values[] = {
[RESET_TYPE] = DSIM_SWRST,
[PLL_TIMER] = 500,
[STOP_STATE_CNT] = 0xf,
-   [PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0xaf),
+   [PHYCTRL_ULPS_EXIT] = 0xaf,
[PHYCTRL_VREG_LP] = 0,
[PHYCTRL_SLEW_UP] = 0,
-   [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x08),
-   [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0d),
-   [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
-   [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x30),
-   [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
-   [PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x0a),
-   [PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0c),
-   [PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x11),
-   [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0d),
+   [PHYTIMING_LPX] = 0x08,
+   [PHYTIMING_HS_EXIT] = 0x0d,
+   [PHYTIMING_CLK_PREPARE] = 0x09,
+   [PHYTIMING_CLK_ZERO] = 0x30,
+   [PHYTIMING_CLK_POST] = 0x0e,
+   [PHYTIMING_CLK_TRAIL] = 0x0a,
+   [PHYTIMING_HS_PREPARE] = 0x0c,
+   [PHYTIMING_HS_ZERO] = 0x11,
+   [PHYTIMING_HS_TRAIL] = 0x0d,
 };
 
 static const unsigned int exynos5433_reg_values[] = {
[RESET_TYPE] = DSIM_FUNCRST,
[PLL_TIMER] = 22200,
[STOP_STATE_CNT] = 0xa,
-   [PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x190),
-   [PHYCTRL_VREG_LP] = DSIM_PHYCTRL_B_DPHYCTL_VREG_LP,
-   [PHYCTRL_SLEW_UP] = DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP,
-   [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x07),
-   [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0c),
-   [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
-   [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x2d),
-   [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
-   [PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x09),
-   [PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0b),
-   [PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x10),
-   [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
+   [PHYCTRL_ULPS_EXIT] = 0x190,
+   [PHYCTRL_VREG_LP] = 1,
+   [PHYCTRL_SLEW_UP] = 1,
+   [PHYTIMING_LPX] = 0x07,
+   [PHYTIMING_HS_EXIT] = 0x0c,
+   [PHYTIMING_CLK_PREPARE] = 0x09,
+   [PHYTIMING_CLK_ZERO] = 0x2d,
+   [PHYTIMING_CLK_POST] = 0x0e,
+   [PHYTIMING_CLK_TRAIL] = 0x09,
+   [PHYTIMING_HS_PREPARE] = 0x0b,
+   [PHYTIMING_HS_ZERO] = 0x10,
+   [PHYTIMING_HS_TRAIL] = 0x0c,
 };
 
 static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
@@ -696,8 +696,11 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
return;
 
/* B D-PHY: D-PHY Master & Slave Analog Block control */
-   reg = reg_values[PHYCTRL_ULPS_EXIT] | reg_values[PHYCTRL_VREG_LP] |
-   reg_values[PHYCTRL_SLEW_UP];
+   reg = DSIM_PHYCTRL_ULPS_EXIT(reg_values[PHYCTRL_ULPS_EXIT]);
+   if (reg_values[PHYCTRL_VREG_LP])
+   reg |= DSIM_PHYCTRL_B_DPHYCTL_VREG_LP;
+   if 

[PATCH 05/16] drm/exynos: convert encoder functions to bridge function

2020-09-03 Thread Michael Tretter
If other drivers use the exynos_dsi driver as a bridge, they might bring
their own encoder. Enable and disable the MIPI-DSI bridge using the
bridge functions instead of the encoder functions.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 33 +++--
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 4d19630f33e7..31d62c10614a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1376,9 +1376,8 @@ static void exynos_dsi_unregister_te_irq(struct 
exynos_dsi *dsi)
}
 }
 
-static void exynos_dsi_enable(struct drm_encoder *encoder)
+static void exynos_dsi_enable(struct exynos_dsi *dsi)
 {
-   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_bridge *iter;
int ret;
 
@@ -1426,9 +1425,8 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
pm_runtime_put(dsi->dev);
 }
 
-static void exynos_dsi_disable(struct drm_encoder *encoder)
+static void exynos_dsi_disable(struct exynos_dsi *dsi)
 {
-   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_bridge *iter;
 
if (!(dsi->state & DSIM_STATE_ENABLED))
@@ -1519,11 +1517,6 @@ static int exynos_dsi_create_connector(struct 
drm_encoder *encoder)
return 0;
 }
 
-static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = 
{
-   .enable = exynos_dsi_enable,
-   .disable = exynos_dsi_disable,
-};
-
 static int exynos_dsi_bridge_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
 {
@@ -1537,8 +1530,24 @@ static int exynos_dsi_bridge_attach(struct drm_bridge 
*bridge,
return 0;
 }
 
+static void exynos_dsi_bridge_enable(struct drm_bridge *bridge)
+{
+   struct exynos_dsi *dsi = bridge->driver_private;
+
+   exynos_dsi_enable(dsi);
+}
+
+static void exynos_dsi_bridge_disable(struct drm_bridge *bridge)
+{
+   struct exynos_dsi *dsi = bridge->driver_private;
+
+   exynos_dsi_disable(dsi);
+}
+
 static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
.attach = exynos_dsi_bridge_attach,
+   .enable = exynos_dsi_bridge_enable,
+   .disable = exynos_dsi_bridge_disable,
 };
 
 MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
@@ -1619,7 +1628,7 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host 
*host,
 
if (dsi->panel) {
mutex_lock(>mode_config.mutex);
-   exynos_dsi_disable(>encoder);
+   exynos_dsi_disable(dsi);
drm_panel_detach(dsi->panel);
dsi->panel = NULL;
dsi->connector.status = connector_status_disconnected;
@@ -1726,8 +1735,6 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
 
drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
 
-   drm_encoder_helper_add(encoder, _dsi_encoder_helper_funcs);
-
ret = exynos_drm_set_possible_crtcs(encoder, EXYNOS_DISPLAY_TYPE_LCD);
if (ret < 0)
return ret;
@@ -1753,7 +1760,7 @@ static void exynos_dsi_unbind(struct device *dev, struct 
device *master,
struct drm_encoder *encoder = dev_get_drvdata(dev);
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
 
-   exynos_dsi_disable(encoder);
+   exynos_dsi_disable(dsi);
 
mipi_dsi_host_unregister(>dsi_host);
 }
-- 
2.20.1

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


[PATCH 16/16] drm/exynos: move bridge driver to bridges

2020-09-03 Thread Michael Tretter
As the driver is not platform dependent anymore, move it to the drm
bridge driver directory.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/bridge/Kconfig|7 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/samsung-dsim.c | 1797 
 drivers/gpu/drm/exynos/Makefile   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 1888 ++---
 drivers/gpu/drm/exynos/exynos_drm_dsi_pltfm.c |  307 ---
 .../drm/bridge/samsung-dsim.h |   24 +-
 7 files changed, 2017 insertions(+), 2009 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi_pltfm.c
 rename drivers/gpu/drm/exynos/exynos_drm_dsi.h => 
include/drm/bridge/samsung-dsim.h (65%)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..be3ac0eb6b54 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -112,6 +112,13 @@ config DRM_PARADE_PS8640
  The PS8640 is a high-performance and low-power
  MIPI DSI to eDP converter
 
+config DRM_SAMSUNG_DSIM
+   tristate "Samsung MIPI DSI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Samsung MIPI DSI bridge driver.
+
 config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..6c785149d6fd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
+obj-$(CONFIG_DRM_SAMSUNG_DSIM) += samsung-dsim.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
new file mode 100644
index ..4da7990328ef
--- /dev/null
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -0,0 +1,1797 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Samsung SoC MIPI DSI Master driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Contacts: Tomasz Figa 
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* returns true iff both arguments logically differs */
+#define NEQV(a, b) (!(a) ^ !(b))
+
+/* DSIM_STATUS */
+#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
+#define DSIM_STOP_STATE_CLK(1 << 8)
+#define DSIM_TX_READY_HS_CLK   (1 << 10)
+#define DSIM_PLL_STABLE(1 << 31)
+
+/* DSIM_TIMEOUT */
+#define DSIM_LPDR_TIMEOUT(x)   ((x) << 0)
+#define DSIM_BTA_TIMEOUT(x)((x) << 16)
+
+/* DSIM_CLKCTRL */
+#define DSIM_ESC_PRESCALER(x)  (((x) & 0x) << 0)
+#define DSIM_ESC_PRESCALER_MASK(0x << 0)
+#define DSIM_LANE_ESC_CLK_EN_CLK   (1 << 19)
+#define DSIM_LANE_ESC_CLK_EN_DATA(x)   (((x) & 0xf) << 20)
+#define DSIM_LANE_ESC_CLK_EN_DATA_MASK (0xf << 20)
+#define DSIM_BYTE_CLKEN(1 << 24)
+#define DSIM_BYTE_CLK_SRC(x)   (((x) & 0x3) << 25)
+#define DSIM_BYTE_CLK_SRC_MASK (0x3 << 25)
+#define DSIM_PLL_BYPASS(1 << 27)
+#define DSIM_ESC_CLKEN (1 << 28)
+#define DSIM_TX_REQUEST_HSCLK  (1 << 31)
+
+/* DSIM_CONFIG */
+#define DSIM_LANE_EN_CLK   (1 << 0)
+#define DSIM_LANE_EN(x)(((x) & 0xf) << 1)
+#define DSIM_NUM_OF_DATA_LANE(x)   (((x) & 0x3) << 5)
+#define DSIM_SUB_PIX_FORMAT(x) (((x) & 0x7) << 8)
+#define DSIM_MAIN_PIX_FORMAT_MASK  (0x7 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB888(0x7 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB666(0x6 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB666_P  (0x5 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB565(0x4 << 12)
+#define DSIM_SUB_VC(((x) & 0x3) << 16)
+#define DSIM_MAIN_VC   (((x) & 0x3) << 18)
+#define DSIM_HSA_MODE  (1 << 20)
+#define DSIM_HBP_MODE  (1 << 21)
+#define DSIM_HFP_MODE  (1 << 22)
+#define DSIM_HSE_MODE  (1 << 23)
+#define DSIM_AUTO_MODE (1 << 24)
+#define DSIM_VIDEO_MODE(1 << 25)
+#define DSIM_BURST_MODE(1 << 26)
+#define DSIM_SYNC_INFORM   (1 << 27)
+#define DSIM_EOT_DISABLE   (1 << 28)
+#define DSIM_MFLUSH_VS (1 << 29)
+/* This flag is valid only for 

[PATCH 07/16] drm/exynos: get encoder from bridge whenever possible

2020-09-03 Thread Michael Tretter
The bridge will not necessarily use the encoder of struct exynos_dsi,
but might use another encoder from another drm driver. Therefore, the
driver has to use the encoder from the bridge instead of the one from
exynos_dsi.

Signed-off-by: Michael Tretter 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 657de5407190..51ec37304a69 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1289,7 +1289,7 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
 static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 {
struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
-   struct drm_encoder *encoder = >encoder;
+   struct drm_encoder *encoder = dsi->bridge.encoder;
 
if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
exynos_drm_crtc_te_handler(encoder->crtc);
@@ -1491,11 +1491,10 @@ static const struct drm_connector_helper_funcs 
exynos_dsi_connector_helper_funcs
.get_modes = exynos_dsi_get_modes,
 };
 
-static int exynos_dsi_create_connector(struct drm_encoder *encoder)
+static int exynos_dsi_create_connector(struct exynos_dsi *dsi)
 {
-   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_connector *connector = >connector;
-   struct drm_device *drm = encoder->dev;
+   struct drm_device *drm = dsi->bridge.dev;
int ret;
 
connector->polled = DRM_CONNECTOR_POLL_HPD;
@@ -1510,7 +1509,7 @@ static int exynos_dsi_create_connector(struct drm_encoder 
*encoder)
 
connector->status = connector_status_disconnected;
drm_connector_helper_add(connector, _dsi_connector_helper_funcs);
-   drm_connector_attach_encoder(connector, encoder);
+   drm_connector_attach_encoder(connector, dsi->bridge.encoder);
if (!drm->registered)
return 0;
 
@@ -1586,7 +1585,7 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host 
*host,
dsi->out_bridge = out_bridge;
list_splice_init(>bridge_chain, >bridge_chain);
} else {
-   int ret = exynos_dsi_create_connector(encoder);
+   int ret = exynos_dsi_create_connector(dsi);
 
if (ret) {
DRM_DEV_ERROR(dsi->dev,
@@ -1637,7 +1636,7 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host 
*host,
  struct mipi_dsi_device *device)
 {
struct exynos_dsi *dsi = host_to_dsi(host);
-   struct drm_device *drm = dsi->encoder.dev;
+   struct drm_device *drm = dsi->bridge.encoder->dev;
 
if (dsi->panel) {
mutex_lock(>mode_config.mutex);
-- 
2.20.1

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


Re: [PATCH] dt-bindings: gpu: samsung-rotator: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sun, Aug 30, 2020 at 01:30:02PM +0200, Krzysztof Kozlowski wrote:
> Additional properties or nodes actually might appear (e.g. power
> domains) so use unevaluatedProperties to fix dtbs_check warnings like:
> 
>   arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281:
> 'iommus', 'power-domains' do not match any of the regexes: 
> 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Tue, Sep 01, 2020 at 03:50:00PM +0100, Mark Brown wrote:
> On Sat, 29 Aug 2020 16:24:52 +0200, Krzysztof Kozlowski wrote:
> > Additional properties actually might appear (e.g. assigned-clocks) so
> > use unevaluatedProperties to fix dtbs_check warnings like:
> > 
> >   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: 
> > system-controller@105c:
> > 'assigned-clock-parents', 'assigned-clocks' do not match any of the 
> > regexes: 'pinctrl-[0-9]+'
> 
> Applied to
> 
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
> 
> Thanks!
> 
> [1/1] ASoC: samsung-i2s: Use unevaluatedProperties
>   commit: 8187d8300251a99e40e288be80bef6a15b7b22e4

Please revert or drop. All these 'unevaluatedProperties' changes are 
wrong.

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


Re: [PATCH 06/10] dt-bindings: sound: samsung-i2s: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sat, Aug 29, 2020 at 04:24:57PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. power-domains) so use
> unevaluatedProperties to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2s@1144:
> Additional properties are not allowed ('power-domains', '#address-cells', 
> 'interrupts', '#size-cells' were unexpected)
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/sound/samsung-i2s.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 02/10] dt-bindings: gpu: arm,mali-midgard: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sat, Aug 29, 2020 at 04:24:53PM +0200, Krzysztof Kozlowski wrote:
> Additional properties or nodes actually might appear (e.g. operating
> points table) so use unevaluatedProperties to fix dtbs_check warnings
> like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac:
> 'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 03/10] dt-bindings: timer: exynos4210-mct: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sat, Aug 29, 2020 at 04:24:54PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. clocks) so use
> unevaluatedProperties to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: timer@101c:
> 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../devicetree/bindings/timer/samsung,exynos4210-mct.yaml   | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sat, Aug 29, 2020 at 04:24:52PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. assigned-clocks) so
> use unevaluatedProperties to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: 
> system-controller@105c:
> 'assigned-clock-parents', 'assigned-clocks' do not match any of the 
> regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND] Requests For Proposals for hosting XDC2021 are now open

2020-09-03 Thread Lyude Paul
(Including a bunch more emails in the To: that got missed the first time)

Hello everyone!

The X.org board is soliciting proposals to host XDC in 2021. Since
XDC2020 is being held virtually this year, we've decided to host in
either North America or Europe. However, the board is open to other
locations, especially if there's an interesting co-location with another
conference.

Of course though, due to the ongoing COVID-19 pandemic it's not yet
clear whether or not it will be possible to host XDC2021 in person.
Because of this, we would like to make it clear that sponsors should
prepare for both the possibility of an in person conference, and the
possibility of a virtual conference. We will work with organizers on
coming up with a deadline for deciding whether or not we'll be going
virtual, likely sometime around July.

If you're considering hosting XDC, we've assembled a wiki page with
what's generally expected and needed:

https://www.x.org/wiki/Events/RFP/

When submitting your proposal, please make sure to include at least the
key information about the potential location in question, possible dates
along with estimated costs. Proposals can be submitted to board at
foundation.x.org until the deadline of November 1st. Additionally, an
quirk early heads-up to the board if you're considering hosting would be
appreciated, in case we need to adjust the schedule a bit. Also, earlier
is better since there generally will be a bit of Q with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

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


Re: [PATCH v5 3/3] xen: add helpers to allocate unpopulated memory

2020-09-03 Thread Jürgen Groß

On 01.09.20 10:33, Roger Pau Monne wrote:

To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallback to use ballooned pages in order to
create foreign mappings.

The newly added helpers use the same parameters as the existing
{alloc/free}_xenballooned_pages functions, which allows for in-place
replacement of the callers. Once a memory region has been added to be
used as scratch mapping space it will no longer be released, and pages
returned are kept in a linked list. This allows to have a buffer of
pages and prevents resorting to frequent additions and removals of
regions.

If enabled (because ZONE_DEVICE is supported) the usage of the new
functionality untangles Xen balloon and RAM hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.

Note the driver is currently not enabled on Arm platforms because it
would interfere with the identity mapping required on some platforms.

Signed-off-by: Roger Pau Monné 


Sorry, I just got a build error for x86 32-bit build:

WARNING: unmet direct dependencies detected for ZONE_DEVICE
  Depends on [n]: MEMORY_HOTPLUG [=n] && MEMORY_HOTREMOVE [=n] && 
SPARSEMEM_VMEMMAP [=n] && ARCH_HAS_PTE_DEVMAP [=n]

  Selected by [y]:
  - XEN_UNPOPULATED_ALLOC [=y] && XEN [=y] && X86 [=y]
  GEN Makefile
  CC  kernel/bounds.s
  CALL/home/gross/korg/src/scripts/atomic/check-atomics.sh
  UPD include/generated/bounds.h
  CC  arch/x86/kernel/asm-offsets.s
In file included from /home/gross/korg/src/include/linux/mmzone.h:19:0,
 from /home/gross/korg/src/include/linux/gfp.h:6,
 from /home/gross/korg/src/include/linux/slab.h:15,
 from /home/gross/korg/src/include/linux/crypto.h:19,
 from /home/gross/korg/src/arch/x86/kernel/asm-offsets.c:9:
/home/gross/korg/src/include/linux/page-flags-layout.h:95:2: error: 
#error "Not enough bits in page flags"

 #error "Not enough bits in page flags"
  ^
make[2]: *** [/home/gross/korg/src/scripts/Makefile.build:114: 
arch/x86/kernel/asm-offsets.s] Error 1

make[1]: *** [/home/gross/korg/src/Makefile:1175: prepare0] Error 2
make[1]: Leaving directory '/home/gross/korg/x8632'
make: *** [Makefile:185: __sub-make] Error 2


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


Re: [PATCH] dt-bindings: gpu: arm, mali-utgard: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sun, Aug 30, 2020 at 2:40 AM Krzysztof Kozlowski  wrote:
>
> Additional properties or nodes actually might appear (e.g. operating
> points table) so use unevaluatedProperties to fix dtbs_check warnings
> like:
>
>   arch/arm/boot/dts/exynos4210-i9100.dt.yaml: gpu@1300:
> 'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+'

When unevaluatedProperties support is actually implemented (there's a
prototype), this will still be a warning. You need to document any
additional properties/nodes.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 04/15] drm/bridge: tc358764: add drm_panel_bridge support

2020-09-03 Thread Andrzej Hajda
Hi Laurent,

On 03.09.2020 11:59, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Thu, Sep 03, 2020 at 11:40:58AM +0200, Andrzej Hajda wrote:
>> On 26.07.2020 22:33, Sam Ravnborg wrote:
>>> Prepare the tc358764 bridge driver for use in a chained setup by
>>> replacing direct use of drm_panel with drm_panel_bridge support.
>>>
>>> The bridge panel will use the connector type reported by the panel,
>>> where the connector for this driver hardcodes DRM_MODE_CONNECTOR_LVDS.
>>>
>>> The tc358764 did not any additional info the the connector so the
>>> connector creation is passed to the bridge panel driver.
>>>
>>> v3:
>>> - Merge with patch to make connector creation optional to avoid
>>>   creating two connectors (Laurent)
>>> - Pass connector creation to bridge panel, as this bridge driver
>>>   did not add any extra info to the connector.
>>> - Set bridge.type to DRM_MODE_CONNECTOR_LVDS.
>>>
>>> v2:
>>> - Use PTR_ERR_OR_ZERO() (kbuild test robot)
>>>
>>> Signed-off-by: Sam Ravnborg 
>>> Cc: Laurent Pinchart 
>>> Cc: kbuild test robot 
>>> Cc: Andrzej Hajda 
>>> Cc: Neil Armstrong 
>>> Cc: Jonas Karlman 
>>> Cc: Jernej Skrabec 
>>> ---
>>>drivers/gpu/drm/bridge/tc358764.c | 107 +-
>>>1 file changed, 16 insertions(+), 91 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/tc358764.c 
>>> b/drivers/gpu/drm/bridge/tc358764.c
>>> index a277739fab58..fdde4cfdc724 100644
>>> --- a/drivers/gpu/drm/bridge/tc358764.c
>>> +++ b/drivers/gpu/drm/bridge/tc358764.c
>>> @@ -153,10 +153,9 @@ static const char * const tc358764_supplies[] = {
>>>struct tc358764 {
>>> struct device *dev;
>>> struct drm_bridge bridge;
>>> -   struct drm_connector connector;
>>> struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
>>> struct gpio_desc *gpio_reset;
>>> -   struct drm_panel *panel;
>>> +   struct drm_bridge *panel_bridge;
>>> int error;
>>>};
>>>
>>> @@ -210,12 +209,6 @@ static inline struct tc358764 
>>> *bridge_to_tc358764(struct drm_bridge *bridge)
>>> return container_of(bridge, struct tc358764, bridge);
>>>}
>>>
>>> -static inline
>>> -struct tc358764 *connector_to_tc358764(struct drm_connector *connector)
>>> -{
>>> -   return container_of(connector, struct tc358764, connector);
>>> -}
>>> -
>>>static int tc358764_init(struct tc358764 *ctx)
>>>{
>>> u32 v = 0;
>>> @@ -278,43 +271,11 @@ static void tc358764_reset(struct tc358764 *ctx)
>>> usleep_range(1000, 2000);
>>>}
>>>
>>> -static int tc358764_get_modes(struct drm_connector *connector)
>>> -{
>>> -   struct tc358764 *ctx = connector_to_tc358764(connector);
>>> -
>>> -   return drm_panel_get_modes(ctx->panel, connector);
>>> -}
>>> -
>>> -static const
>>> -struct drm_connector_helper_funcs tc358764_connector_helper_funcs = {
>>> -   .get_modes = tc358764_get_modes,
>>> -};
>>> -
>>> -static const struct drm_connector_funcs tc358764_connector_funcs = {
>>> -   .fill_modes = drm_helper_probe_single_connector_modes,
>>> -   .destroy = drm_connector_cleanup,
>>> -   .reset = drm_atomic_helper_connector_reset,
>>> -   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>>> -   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>> -};
>>> -
>>> -static void tc358764_disable(struct drm_bridge *bridge)
>>> -{
>>> -   struct tc358764 *ctx = bridge_to_tc358764(bridge);
>>> -   int ret = drm_panel_disable(bridge_to_tc358764(bridge)->panel);
>>> -
>>> -   if (ret < 0)
>>> -   dev_err(ctx->dev, "error disabling panel (%d)\n", ret);
>>> -}
>>> -
>>>static void tc358764_post_disable(struct drm_bridge *bridge)
>>>{
>>> struct tc358764 *ctx = bridge_to_tc358764(bridge);
>>> int ret;
>>>
>>> -   ret = drm_panel_unprepare(ctx->panel);
>>> -   if (ret < 0)
>>> -   dev_err(ctx->dev, "error unpreparing panel (%d)\n", ret);
>>
>> Using this bridge_panel thing you reverse order of hw
>> initialization/de-initialization, this is incorrect.
>>
>> For example:
>>
>> - panel_unprepare should be called before tc35* turn off,
>>
>> - panel_prepare should be called after tc35* on.
>>
>> This is why I avoid the whole "bridge chaining" - it enforces ridiculous
>> order of initialization.
>>
>>
>>> tc358764_reset(ctx);
>>> usleep_range(1, 15000);
>>> ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
>>> @@ -335,70 +296,28 @@ static void tc358764_pre_enable(struct drm_bridge 
>>> *bridge)
>>> ret = tc358764_init(ctx);
>>> if (ret < 0)
>>> dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
>>> -   ret = drm_panel_prepare(ctx->panel);
>>> -   if (ret < 0)
>>> -   dev_err(ctx->dev, "error preparing panel (%d)\n", ret);
>>> -}
>>> -
>>> -static void tc358764_enable(struct drm_bridge *bridge)
>>> -{
>>> -   struct tc358764 *ctx = bridge_to_tc358764(bridge);
>>> -   int ret = drm_panel_enable(ctx->panel);
>>> -
>>> -   if 

Re: [PATCH] drm/managed: Cleanup of unused functions and polishing docs

2020-09-03 Thread Daniel Vetter
On Wed, Sep 02, 2020 at 09:26:27AM +0200, Daniel Vetter wrote:
> Following functions are only used internally, not by drivers:
> - devm_drm_dev_init
> 
> Also, now that we have a very slick and polished way to allocate a
> drm_device with devm_drm_dev_alloc, update all the docs to reflect the
> new reality. Mostly this consists of deleting old and misleading
> hints. Two main ones:
> 
> - it is no longer required that the drm_device base class is first in
>   the structure. devm_drm_dev_alloc can cope with it being anywhere
> 
> - obviously embedded now strongly recommends using devm_drm_dev_alloc
> 
> v2: Fix typos (Noralf)
> 
> v3: Split out the removal of drm_dev_init, that's blocked on some
> discussions on how to convert vgem/vkms/i915-selftests. Adjust commit
> message to reflect that.
> 
> Cc: Noralf Trønnes 
> Acked-by: Noralf Trønnes  (v2)
> Acked-by: Sam Ravnborg 
> Cc: Luben Tuikov 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 

Ok pushed that now to drm-misc-next. I'm also working on getting the
remaining bits of the basic drm managed conversion resubmitted. That was
unfortunately massively sidelined for the dma-fence discussions.

Quick heads-up:
drmm_add_final_kfree and drm_dev_init will both disappear, please use
devm_drm_dev_alloc.

Cheers, Daniel

> ---
>  .../driver-api/driver-model/devres.rst|  2 +-
>  drivers/gpu/drm/drm_drv.c | 78 +--
>  drivers/gpu/drm/drm_managed.c |  2 +-
>  include/drm/drm_device.h  |  2 +-
>  include/drm/drm_drv.h | 16 ++--
>  5 files changed, 30 insertions(+), 70 deletions(-)
> 
> diff --git a/Documentation/driver-api/driver-model/devres.rst 
> b/Documentation/driver-api/driver-model/devres.rst
> index efc21134..aa4d2420f79e 100644
> --- a/Documentation/driver-api/driver-model/devres.rst
> +++ b/Documentation/driver-api/driver-model/devres.rst
> @@ -263,7 +263,7 @@ DMA
>dmam_pool_destroy()
>  
>  DRM
> -  devm_drm_dev_init()
> +  devm_drm_dev_alloc()
>  
>  GPIO
>devm_gpiod_get()
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index d4506f7a234e..7c1689842ec0 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -240,13 +240,13 @@ void drm_minor_release(struct drm_minor *minor)
>   * DOC: driver instance overview
>   *
>   * A device instance for a drm driver is represented by  drm_device. 
> This
> - * is initialized with drm_dev_init(), usually from bus-specific ->probe()
> - * callbacks implemented by the driver. The driver then needs to initialize 
> all
> - * the various subsystems for the drm device like memory management, vblank
> - * handling, modesetting support and intial output configuration plus 
> obviously
> - * initialize all the corresponding hardware bits. Finally when everything 
> is up
> - * and running and ready for userspace the device instance can be published
> - * using drm_dev_register().
> + * is allocated and initialized with devm_drm_dev_alloc(), usually from
> + * bus-specific ->probe() callbacks implemented by the driver. The driver 
> then
> + * needs to initialize all the various subsystems for the drm device like 
> memory
> + * management, vblank handling, modesetting support and initial output
> + * configuration plus obviously initialize all the corresponding hardware 
> bits.
> + * Finally when everything is up and running and ready for userspace the 
> device
> + * instance can be published using drm_dev_register().
>   *
>   * There is also deprecated support for initalizing device instances using
>   * bus-specific helpers and the _driver.load callback. But due to
> @@ -274,7 +274,7 @@ void drm_minor_release(struct drm_minor *minor)
>   *
>   * The following example shows a typical structure of a DRM display driver.
>   * The example focus on the probe() function and the other functions that is
> - * almost always present and serves as a demonstration of 
> devm_drm_dev_init().
> + * almost always present and serves as a demonstration of 
> devm_drm_dev_alloc().
>   *
>   * .. code-block:: c
>   *
> @@ -294,22 +294,12 @@ void drm_minor_release(struct drm_minor *minor)
>   *   struct drm_device *drm;
>   *   int ret;
>   *
> - *   // devm_kzalloc() can't be used here because the drm_device '
> - *   // lifetime can exceed the device lifetime if driver unbind
> - *   // happens when userspace still has open file descriptors.
> - *   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> - *   if (!priv)
> - *   return -ENOMEM;
> - *
> + *   priv = devm_drm_dev_alloc(>dev, _drm_driver,
> + * struct driver_device, drm);
> + *   if (IS_ERR(priv))
> + *   return PTR_ERR(priv);
>   *   drm = >drm;
>   *
> - *   ret = devm_drm_dev_init(>dev, drm, _drm_driver);
> - *   if (ret) {
> - *

Re: [PATCH] drm/panfrost: Set DMA max segment size

2020-09-03 Thread Steven Price

On 03/09/2020 14:59, Robin Murphy wrote:

Since all we do with scatterlists is map them in the MMU, we don't have
any hardware constraints on how they're laid out. Let the DMA layer know
so it won't warn when DMA API debugging is enabled.

Signed-off-by: Robin Murphy 


Reviewed-by: Steven Price 


---
  drivers/gpu/drm/panfrost/panfrost_gpu.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c 
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index f2c1ddc41a9b..9a5c85a7d341 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -343,6 +343,7 @@ int panfrost_gpu_init(struct panfrost_device *pfdev)
  
  	dma_set_mask_and_coherent(pfdev->dev,

DMA_BIT_MASK(FIELD_GET(0xff00, pfdev->features.mmu_features)));
+   dma_set_max_seg_size(pfdev->dev, UINT_MAX);
  
  	irq = platform_get_irq_byname(to_platform_device(pfdev->dev), "gpu");

if (irq <= 0)



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


[PATCH] drm/panfrost: Set DMA max segment size

2020-09-03 Thread Robin Murphy
Since all we do with scatterlists is map them in the MMU, we don't have
any hardware constraints on how they're laid out. Let the DMA layer know
so it won't warn when DMA API debugging is enabled.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/panfrost/panfrost_gpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c 
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index f2c1ddc41a9b..9a5c85a7d341 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -343,6 +343,7 @@ int panfrost_gpu_init(struct panfrost_device *pfdev)
 
dma_set_mask_and_coherent(pfdev->dev,
DMA_BIT_MASK(FIELD_GET(0xff00, pfdev->features.mmu_features)));
+   dma_set_max_seg_size(pfdev->dev, UINT_MAX);
 
irq = platform_get_irq_byname(to_platform_device(pfdev->dev), "gpu");
if (irq <= 0)
-- 
2.28.0.dirty

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


Re: [PATCH v10 07/17] pwm: lpss: Remove suspend/resume handlers

2020-09-03 Thread Hans de Goede

Hi,

On 9/3/20 2:56 PM, Andy Shevchenko wrote:

On Thu, Sep 03, 2020 at 03:48:16PM +0300, Andy Shevchenko wrote:

On Thu, Sep 03, 2020 at 01:23:27PM +0200, Hans de Goede wrote:



the question is do we need to have similar in acpi_lpss.c?
For example,
static const struct lpss_device_desc byt_pwm_dev_desc = {
.flags = LPSS_SAVE_CTX,
^^
.prv_offset = 0x800,
.setup = byt_pwm_setup,
};

static const struct lpss_device_desc bsw_pwm_dev_desc = {
.flags = LPSS_SAVE_CTX | LPSS_NO_D3_DELAY,
^^
.prv_offset = 0x800,
.setup = bsw_pwm_setup,
};


Okay, it's a private space which has clock and reset gating, so means we still
need to handle it.


Right I was about to say the same.

As always, thank you for your reviews.

Regards,

Hans

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


Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

2020-09-03 Thread Jim Quinlan
On Tue, Sep 1, 2020 at 4:24 AM Christoph Hellwig  wrote:
>
> I've applied this to the dma-mapping tree.
>
> I had to resolve a conflict in drivers/of/address.c with a recent
> mainline commit.  I also applied the minor tweaks Andy pointed out
> plus a few more style changes.  A real change is that I changed the
> prototype for dma_copy_dma_range_map to require less boilerplate code.
>
> The result is here:
>
> 
> http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/eef520b232c60e74eb8b33a5a7863ad8f2b4a5c7
>
> please double check that everyting works as expected.
Tested-by: Jim Quinlan 

Thanks Christoph
Jim
>
> I can cut a stable branch with this if you need it for other trees, but
> I'd like to wait a few days to see if there is any fallout first.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

2020-09-03 Thread Jim Quinlan
On Wed, Sep 2, 2020 at 5:53 PM Nathan Chancellor
 wrote:
>
> On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
> > capable of holding a single uniform offset and had no region bounds
> > checking.
> >
> > The function of_dma_get_range() has been modified so that it takes a single
> > argument -- the device node -- and returns a map, NULL, or an error code.
> > The map is an array that holds the information regarding the DMA regions.
> > Each range entry contains the address offset, the cpu_start address, the
> > dma_start address, and the size of the region.
> >
> > of_dma_configure() is the typical manner to set range offsets but there are
> > a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> > driver code.  These cases now invoke the function
> > dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
> >
> > Signed-off-by: Jim Quinlan 
> > ---
> >  arch/arm/include/asm/dma-mapping.h| 10 +--
> >  arch/arm/mach-keystone/keystone.c | 17 +++--
> >  arch/sh/drivers/pci/pcie-sh7786.c |  9 +--
> >  arch/x86/pci/sta2x11-fixup.c  |  7 +-
> >  drivers/acpi/arm64/iort.c |  5 +-
> >  drivers/base/core.c   |  2 +
> >  drivers/gpu/drm/sun4i/sun4i_backend.c |  5 +-
> >  drivers/iommu/io-pgtable-arm.c|  2 +-
> >  .../platform/sunxi/sun4i-csi/sun4i_csi.c  |  5 +-
> >  .../platform/sunxi/sun6i-csi/sun6i_csi.c  |  4 +-
> >  drivers/of/address.c  | 72 +--
> >  drivers/of/device.c   | 43 ++-
> >  drivers/of/of_private.h   | 10 +--
> >  drivers/of/unittest.c | 34 ++---
> >  drivers/remoteproc/remoteproc_core.c  |  8 ++-
> >  .../staging/media/sunxi/cedrus/cedrus_hw.c|  7 +-
> >  drivers/usb/core/message.c|  9 ++-
> >  drivers/usb/core/usb.c|  7 +-
> >  include/linux/device.h|  4 +-
> >  include/linux/dma-direct.h|  8 +--
> >  include/linux/dma-mapping.h   | 36 ++
> >  kernel/dma/coherent.c | 10 +--
> >  kernel/dma/mapping.c  | 66 +
> >  23 files changed, 265 insertions(+), 115 deletions(-)
>
> Apologies if this has already been reported or is known but this commit
> is now in next-20200902 and it causes my Raspberry Pi 4 to no longer
> make it to userspace, instead spewing mmc errors:
>
> That commit causes my Raspberry Pi 4 to no longer make it to userspace,
> instead spewing mmc errors:
>
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
> [0.00] Linux version 5.9.0-rc3-4-geef520b232c6-dirty 
> (nathan@ubuntu-n2-xlarge-x86) (ClangBuiltLinux clang version 12.0.0 
> (https://github.com/llvm/llvm-project.git 
> b21ddded8f04fee925bbf9e6458347104b5b99eb), LLD 12.0.0 
> (https://github.com/llvm/llvm-project.git 
> b21ddded8f04fee925bbf9e6458347104b5b99eb)) #1 SMP PREEMPT Wed Sep 2 13:48:49 
> MST 2020
> [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.2
> ...
> [1.459752] raspberrypi-firmware soc:firmware: Attached to firmware from 
> 2020-08-24T18:50:56
> [1.57] dwc2 fe98.usb: supply vusb_d not found, using dummy 
> regulator
> [1.507454] dwc2 fe98.usb: supply vusb_a not found, using dummy 
> regulator
> [1.615547] dwc2 fe98.usb: EPs: 8, dedicated fifos, 4080 entries in 
> SPRAM
> [1.627537] sdhci-iproc fe30.sdhci: allocated mmc-pwrseq
> [1.665497] mmc0: SDHCI controller on fe30.sdhci [fe30.sdhci] 
> using PIO
> [1.690601] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
> [1.697892] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [1.705173] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [1.713788] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [1.721228] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [1.732062] mmc1: SDHCI controller on fe34.emmc2 [fe34.emmc2] 
> using ADMA
> [1.741828] ALSA device list:
> [1.744885]   No soundcards found.
> [1.748540] Waiting for root device PARTUUID=45a8dd8a-02...
> [1.788865] random: fast init done
> [1.793489] mmc1: unrecognised SCR structure version 4
> [1.798814] mmc1: error -22 whilst initialising SD card
> [1.813969] mmc0: new high speed SDIO card at address 0001
> [1.883178] mmc1: unrecognised SCR structure version 2
> [1.888423] mmc1: error -22 whilst initialising SD card
> [1.964069] mmc1: unrecognised SCR structure version 4
> [1.969314] mmc1: error -22 whilst initialising SD card
> [2.061225] mmc1: unrecognised 

Re: [PATCH 08/29] dma-buf: Avoid comma separated statements

2020-09-03 Thread Sumit Semwal
Hello Joe,

On Wed, 26 Aug 2020 at 20:38, Christian König  wrote:
>
> Am 25.08.20 um 06:56 schrieb Joe Perches:
> > Use semicolons and braces.
> >
> > Signed-off-by: Joe Perches 
>
> Acked-by: Christian König 
FWIW,
Acked-by: Sumit Semwal 

>
> > ---
> >   drivers/dma-buf/st-dma-fence.c | 7 +--
> >   1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
> > index e593064341c8..c8a12d7ad71a 100644
> > --- a/drivers/dma-buf/st-dma-fence.c
> > +++ b/drivers/dma-buf/st-dma-fence.c
> > @@ -471,8 +471,11 @@ static int thread_signal_callback(void *arg)
> >   dma_fence_signal(f1);
> >
> >   smp_store_mb(cb.seen, false);
> > - if (!f2 || dma_fence_add_callback(f2, , 
> > simple_callback))
> > - miss++, cb.seen = true;
> > + if (!f2 ||
> > + dma_fence_add_callback(f2, , simple_callback)) {
> > + miss++;
> > + cb.seen = true;
> > + }
> >
> >   if (!t->before)
> >   dma_fence_signal(f1);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 209129] HW related error message under Gnome important tab

2020-09-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209129

--- Comment #14 from Laszlo (laszlo.a.t...@googlemail.com) ---
Then please assign a person at the mentioned new thread who can examine the
reason of this bug, verify the root cause, assess whether they have fixed it or
not.

Then he can suggest the appropriate kernel and probably driver . . .

I am user who needs some support during the correcting procedure . . . .

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge

2020-09-03 Thread Tomi Valkeinen
Hi Milind,

On 03/09/2020 09:22, Milind Parab wrote:

> Also, note that CDNS MHDP implements DP_FRAMER_TU_p where bits 5:0 is 
> tu_valid_symbols. So max programmable value is 63.
> Register document gives following explanation 
> "Number of valid symbols per Transfer Unit (TU). Rounded down to lower 
> integer value (Allowed values are 1 to (TU_size-1)"
> 
> So, it says in case vs calculates to 64 (where Avail BW and Req BW are same) 
> we program tu_valid_symbols = 63

Hmm, so "Rounded down to lower integer value" means

floor(x) - 1 ?

If that's the case, we need to subtract 1 in all cases, not only when req bw == 
avail bw.

> Third, is about the line_threshold calculation
> Unlike TU_SIZE and Valid_Symbols, line_threshold is implementation dependent
> 
> CDNS MHDP register specs gives the definition as " Video FIFO latency 
> threshold" 
> Bits 5:0, Name "cfg_active_line_tresh", Description "Video Fifo Latency 
> threshold. Defines the number of FIFO rows before reading starts. This 
> setting depends on the transmitted video format and link rate."
> 
> This parameter is the Threshold of the FIFO. For optimal performance 
> (considering equal write and read clock) we normally put the threshold in the 
> mid of the FIFO.
> Hence the reset value is fixed as 32.
> Since symbol FIFO is accessed by Pxl clock and Symbol Link Clock the 
> Threshold is set to a value which is dependent on the ratio of these clocks
> 
> line_threshold = full_fifo - fifo_ratio_due_to_clock_diff + 2
> where,
> full_fifo = (vs+1) * (8/bpp)
> fifo_ratio_due_to_clock_diff = ((vs+1) * pxlclock/mhdp->link.rate - 1) / 
> mhdp->link.num_lanes 
> 
> Note that line_threshold can take a max value of 63

That doesn't result in anything sensible. 8/bpp is always 0.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v10 13/17] pwm: crc: Implement get_state() method

2020-09-03 Thread Hans de Goede
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.

Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v6:
- Rebase on 5.9-rc1
- Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64

Changes in v5:
- Fix an indentation issue

Changes in v4:
- Use DIV_ROUND_UP when calculating the period and duty_cycle from the
  controller's register values

Changes in v3:
- Add Andy's Reviewed-by tag
- Remove extra whitespace to align some code after assignments (requested by
  Uwe Kleine-König)
---
 drivers/pwm/pwm-crc.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 27dc30882424..ecfdfac0c2d9 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -121,8 +121,39 @@ static int crc_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
return 0;
 }
 
+static void crc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(chip);
+   struct device *dev = crc_pwm->chip.dev;
+   unsigned int clk_div, clk_div_reg, duty_cycle_reg;
+   int error;
+
+   error = regmap_read(crc_pwm->regmap, PWM0_CLK_DIV, _div_reg);
+   if (error) {
+   dev_err(dev, "Error reading PWM0_CLK_DIV %d\n", error);
+   return;
+   }
+
+   error = regmap_read(crc_pwm->regmap, PWM0_DUTY_CYCLE, _cycle_reg);
+   if (error) {
+   dev_err(dev, "Error reading PWM0_DUTY_CYCLE %d\n", error);
+   return;
+   }
+
+   clk_div = (clk_div_reg & ~PWM_OUTPUT_ENABLE) + 1;
+
+   state->period =
+   DIV_ROUND_UP(clk_div * NSEC_PER_USEC * 256, PWM_BASE_CLK_MHZ);
+   state->duty_cycle =
+   DIV_ROUND_UP_ULL(duty_cycle_reg * state->period, PWM_MAX_LEVEL);
+   state->polarity = PWM_POLARITY_NORMAL;
+   state->enabled = !!(clk_div_reg & PWM_OUTPUT_ENABLE);
+}
+
 static const struct pwm_ops crc_pwm_ops = {
.apply = crc_pwm_apply,
+   .get_state = crc_pwm_get_state,
 };
 
 static int crystalcove_pwm_probe(struct platform_device *pdev)
-- 
2.28.0

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


[PATCH v10 14/17] drm/i915: panel: Add get_vbt_pwm_freq() helper

2020-09-03 Thread Hans de Goede
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().

This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).

Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 27 ++
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 4072d7062efd..df7472a3b9f8 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1543,18 +1543,9 @@ static u32 vlv_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
return DIV_ROUND_CLOSEST(clock, pwm_freq_hz * mul);
 }
 
-static u32 get_backlight_max_vbt(struct intel_connector *connector)
+static u16 get_vbt_pwm_freq(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_panel *panel = >panel;
u16 pwm_freq_hz = dev_priv->vbt.backlight.pwm_freq_hz;
-   u32 pwm;
-
-   if (!panel->backlight.hz_to_pwm) {
-   drm_dbg_kms(_priv->drm,
-   "backlight frequency conversion not supported\n");
-   return 0;
-   }
 
if (pwm_freq_hz) {
drm_dbg_kms(_priv->drm,
@@ -1567,6 +1558,22 @@ static u32 get_backlight_max_vbt(struct intel_connector 
*connector)
pwm_freq_hz);
}
 
+   return pwm_freq_hz;
+}
+
+static u32 get_backlight_max_vbt(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u16 pwm_freq_hz = get_vbt_pwm_freq(dev_priv);
+   u32 pwm;
+
+   if (!panel->backlight.hz_to_pwm) {
+   drm_dbg_kms(_priv->drm,
+   "backlight frequency conversion not supported\n");
+   return 0;
+   }
+
pwm = panel->backlight.hz_to_pwm(connector, pwm_freq_hz);
if (!pwm) {
drm_dbg_kms(_priv->drm,
-- 
2.28.0

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


[PATCH v10 12/17] pwm: crc: Implement apply() method to support the new atomic PWM API

2020-09-03 Thread Hans de Goede
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.

Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v6:
- Rebase on 5.9-rc1
- Use do_div when calculating level because pwm_state.period and .duty_cycle 
are now u64

Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
 drivers/pwm/pwm-crc.c | 89 ++-
 1 file changed, 54 insertions(+), 35 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index b72008c9b072..27dc30882424 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -51,59 +51,78 @@ static int crc_pwm_calc_clk_div(int period_ns)
return clk_div;
 }
 
-static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
+static int crc_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+const struct pwm_state *state)
 {
-   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
-   int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(chip);
+   struct device *dev = crc_pwm->chip.dev;
+   int err;
 
-   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div | PWM_OUTPUT_ENABLE);
-   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
+   if (state->period > PWM_MAX_PERIOD_NS) {
+   dev_err(dev, "un-supported period_ns\n");
+   return -EINVAL;
+   }
 
-   return 0;
-}
+   if (state->polarity != PWM_POLARITY_NORMAL)
+   return -EOPNOTSUPP;
 
-static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
-{
-   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
-   int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
+   if (pwm_is_enabled(pwm) && !state->enabled) {
+   err = regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+   if (err) {
+   dev_err(dev, "Error writing BACKLIGHT_EN %d\n", err);
+   return err;
+   }
+   }
 
-   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
-   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div);
-}
+   if (pwm_get_duty_cycle(pwm) != state->duty_cycle ||
+   pwm_get_period(pwm) != state->period) {
+   u64 level = state->duty_cycle * PWM_MAX_LEVEL;
 
-static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
- int duty_ns, int period_ns)
-{
-   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
-   struct device *dev = crc_pwm->chip.dev;
-   int level;
+   do_div(level, state->period);
 
-   if (period_ns > PWM_MAX_PERIOD_NS) {
-   dev_err(dev, "un-supported period_ns\n");
-   return -EINVAL;
+   err = regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
+   if (err) {
+   dev_err(dev, "Error writing PWM0_DUTY_CYCLE %d\n", err);
+   return err;
+   }
}
 
-   if (pwm_get_period(pwm) != period_ns) {
-   int clk_div = crc_pwm_calc_clk_div(period_ns);
-
+   if (pwm_is_enabled(pwm) && state->enabled &&
+   pwm_get_period(pwm) != state->period) {
/* changing the clk divisor, clear PWM_OUTPUT_ENABLE first */
-   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
+   err = regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
+   if (err) {
+   dev_err(dev, "Error writing PWM0_CLK_DIV %d\n", err);
+   return err;
+   }
+   }
 
-   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
-   clk_div | PWM_OUTPUT_ENABLE);
+   if (pwm_get_period(pwm) != state->period ||
+   pwm_is_enabled(pwm) != state->enabled) {
+   int clk_div = crc_pwm_calc_clk_div(state->period);
+   int pwm_output_enable = state->enabled ? PWM_OUTPUT_ENABLE : 0;
+
+   err = regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
+  clk_div | pwm_output_enable);
+   if (err) {
+   dev_err(dev, "Error writing PWM0_CLK_DIV %d\n", err);
+   return err;
+   }
}
 
-   /* change the pwm duty cycle */
-   level = duty_ns * PWM_MAX_LEVEL / period_ns;
-   regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
+   if (!pwm_is_enabled(pwm) && state->enabled) {
+   err = regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
+   if (err) {
+   dev_err(dev, "Error writing BACKLIGHT_EN %d\n", err);
+   return err;
+   }
+   }
 
return 0;
 }
 
 static const struct pwm_ops crc_pwm_ops = {
-   .config = crc_pwm_config,
-   .enable = crc_pwm_enable,
-   .disable = crc_pwm_disable,
+   

[PATCH v10 16/17] drm/i915: panel: Honor the VBT PWM min setting for devs with an external PWM controller

2020-09-03 Thread Hans de Goede
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.

Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the minimum level.

Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 5a13089d2fc0..2b27f9b07403 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1925,8 +1925,8 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
 */
pwm_apply_args(panel->backlight.pwm);
 
-   panel->backlight.min = 0; /* 0% */
panel->backlight.max = 100; /* 100% */
+   panel->backlight.min = get_backlight_min_vbt(connector);
level = intel_panel_compute_brightness(connector, 100);
ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
@@ -1941,8 +1941,9 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
 
level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
 panel->backlight.pwm_period_ns);
-   panel->backlight.level =
-   intel_panel_compute_brightness(connector, level);
+   level = intel_panel_compute_brightness(connector, level);
+   panel->backlight.level = clamp(level, panel->backlight.min,
+  panel->backlight.max);
panel->backlight.enabled = panel->backlight.level != 0;
 
drm_info(_priv->drm, "Using %s PWM for LCD backlight control\n",
-- 
2.28.0

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


[PATCH v10 10/17] pwm: crc: Fix period changes not having any effect

2020-09-03 Thread Hans de Goede
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register

The BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable pin for LCD panels, this GPO is part of the PMIC's
"Display Panel Control Block." . This pin should probably be moved over
to a GPIO provider driver (and consumers modified accordingly), but that
is something for an(other) patch.

Enabling / disabling the actual PWM output is controlled by the
PWM_OUTPUT_ENABLE bit of the PWM0_CLK_DIV register.

As the comment in the old code already indicates we must disable the PWM
before we can change the clock divider. But the crc_pwm_disable() and
crc_pwm_enable() calls the old code make for this only change the
BACKLIGHT_EN register; and the value of that register does not matter for
changing the period / the divider. What does matter is that the
PWM_OUTPUT_ENABLE bit must be cleared before a new value can be written.

This commit modifies crc_pwm_config() to clear PWM_OUTPUT_ENABLE instead
when changing the period, so that period changes actually work.

Note this fix will cause a significant behavior change on some devices
using the CRC PWM output to drive their backlight. Before the PWM would
always run with the output frequency configured by the BIOS at boot, now
the period time specified by the i915 driver will actually be honored.

Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
 drivers/pwm/pwm-crc.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 44ec7d5b63e1..81232da0c767 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -82,14 +82,11 @@ static int crc_pwm_config(struct pwm_chip *c, struct 
pwm_device *pwm,
if (pwm_get_period(pwm) != period_ns) {
int clk_div = crc_pwm_calc_clk_div(period_ns);
 
-   /* changing the clk divisor, need to disable fisrt */
-   crc_pwm_disable(c, pwm);
+   /* changing the clk divisor, clear PWM_OUTPUT_ENABLE first */
+   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, 0);
 
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
-
-   /* enable back */
-   crc_pwm_enable(c, pwm);
}
 
/* change the pwm duty cycle */
-- 
2.28.0

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


[PATCH v10 17/17] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller

2020-09-03 Thread Hans de Goede
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.

The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastset path.

Note that this commit also simplifies pwm_disable_backlight(), by dropping
the intel_panel_actually_set_backlight(..., 0) call. This call sets the
PWM to 0% duty-cycle. I believe that this call was only present as a
workaround for a bug in the pwm-crc.c driver where it failed to clear the
PWM_OUTPUT_ENABLE bit. This is fixed by an earlier patch in this series.

After the dropping of this workaround, the usleep call, which seems
unnecessary to begin with, has no useful effect anymore, so drop that too.

Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
Changes in v7:
- Fix a u64 divide leading to undefined reference to `__udivdi3' errors on 32 
bit
  platforms by casting the divisor to an unsigned long

Changes in v6:
- Drop the pwm_get_period() check in pwm_setup(), it is now longer needed
  now that we use pwm_get_relative_duty_cycle()

Changes in v4:
- Add a note to the commit message about the dropping of the
  intel_panel_actually_set_backlight() and usleep() calls from
  pwm_disable_backlight()
- Use the pwm_set/get_relative_duty_cycle() helpers instead of using DIY code
  for this
---
 .../drm/i915/display/intel_display_types.h|  3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 70 ---
 2 files changed, 33 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 7171e7c8d928..e3ebe7c313ba 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -223,7 +224,7 @@ struct intel_panel {
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
-   int pwm_period_ns;
+   struct pwm_state pwm_state;
 
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 2b27f9b07403..2eb1a3a93df1 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -592,10 +592,10 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 static u32 pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
-   int duty_ns;
+   struct pwm_state state;
 
-   duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
-   return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
+   pwm_get_state(panel->backlight.pwm, );
+   return pwm_get_relative_duty_cycle(, 100);
 }
 
 static void lpt_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
@@ -669,10 +669,9 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
 static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
-   int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
-   pwm_config(panel->backlight.pwm, duty_ns,
-  panel->backlight.pwm_period_ns);
+   pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
+   pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
 }
 
 static void
@@ -841,10 +840,8 @@ static void pwm_disable_backlight(const struct 
drm_connector_state *old_conn_sta
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
 
-   /* Disable the backlight */
-   intel_panel_actually_set_backlight(old_conn_state, 0);
-   usleep_range(2000, 3000);
-   pwm_disable(panel->backlight.pwm);
+   panel->backlight.pwm_state.enabled = false;
+   pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
 }
 
 void intel_panel_disable_backlight(const struct drm_connector_state 
*old_conn_state)
@@ -1176,9 +1173,12 @@ static void pwm_enable_backlight(const struct 
intel_crtc_state *crtc_state,
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
+   int level = panel->backlight.level;
 
-   pwm_enable(panel->backlight.pwm);
-   intel_panel_actually_set_backlight(conn_state, panel->backlight.level);
+   level = intel_panel_compute_brightness(connector, level);
+   pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
+   panel->backlight.pwm_state.enabled = true;
+   

[PATCH v10 02/17] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)

2020-09-03 Thread Hans de Goede
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:

Method (_PS3, 0, Serialized)  // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
...
}

Where PSAT is the power-status register of the PWM controller.

Since the i915 driver will do a pwm_get on the pwm device as it uses it to
control the LCD panel backlight, there is a device-link marking the i915
device as a consumer of the pwm device. So that the PWM controller will
always be suspended after the i915 driver suspends (which is the right
thing to do). This causes the above GFX0 PS3 AML code to run before
acpi_lpss.c calls acpi_lpss_save_ctx().

So on these devices the PWM controller will already be off when
acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0x)
as ctx register values.

When these bogus values get restored on resume the PWM controller actually
keeps working, since most bits are reserved, but this does set bit 3 of
the LPSS General purpose register, which for the PWM controller has the
following function: "This bit is re-used to support 32kHz slow mode.
Default is 19.2MHz as PWM source clock".

This causes the clock of the PWM controller to switch from 19.2MHz to
32KHz, which is a slow-down of a factor 600. Surprisingly enough so far
there have been few bug reports about this. This is likely because the
i915 driver was hardcoding the PWM frequency to 46 KHz, which divided
by 600 would result in a PWM frequency of approx. 78 Hz, which mostly
still works fine. There are some bug reports about the LCD backlight
flickering after suspend/resume which are likely caused by this issue.

But with the upcoming patch-series to finally switch the i915 drivers
code for external PWM controllers to use the atomic API and to honor
the PWM frequency specified in the video BIOS (VBT), this becomes a much
bigger problem. On most cases the VBT specifies either 200 Hz or 20
KHz as PWM frequency, which with the mentioned issue ends up being either
1/3 Hz, where the backlight actually visible blinks on and off every 3s,
or in 33 Hz and horrible flickering of the backlight.

There are a number of possible solutions to this problem:

1. Make acpi_lpss_save_ctx() run before GFX0._PS3
 Pro: Clean solution from pov of not medling with save/restore ctx code
 Con: As mentioned the current ordering is the right thing to do
 Con: Requires assymmetry in at what suspend/resume phase we do the save vs
  restore, requiring more suspend/resume ordering hacks in already
  convoluted acpi_lpss.c suspend/resume code.
2. Do some sort of save once mode for the LPSS ctx
 Pro: Reasonably clean
 Con: Needs a new LPSS flag + code changes to handle the flag
3. Detect we have failed to save the ctx registers and do not restore them
 Pro: Not PWM specific, might help with issues on other LPSS devices too
 Con: If we can get away with not restoring the ctx why bother with it at
  all?
4. Do not save the ctx for CHT PWM controllers
 Pro: Clean, as simple as dropping a flag?
 Con: Not so simple as dropping a flag, needs a new flag to ensure that
  we still do lpss_deassert_reset() on device activation.
5. Make the pwm-lpss code fixup the LPSS-context registers
 Pro: Keeps acpi_lpss.c code clean
 Con: Moves knowledge of LPSS-context into the pwm-lpss.c code

1 and 5 both do not seem to be a desirable way forward.

3 and 4 seem ok, but they both assume that restoring the LPSS-context
registers is not necessary. I have done a couple of test and those do
show that restoring the LPSS-context indeed does not seem to be necessary
on devices using s2idle suspend (and successfully reaching S0i3). But I
have no hardware to test deep / S3 suspend. So I'm not sure that not
restoring the context is safe.

That leaves solution 2, which is about as simple / clean as 3 and 4,
so this commit fixes the described problem by implementing a new
LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
Changes in v2:
- Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX
---
 drivers/acpi/acpi_lpss.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 67892fc0b822..a8d7d83ac761 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -67,7 +67,15 @@ ACPI_MODULE_NAME("acpi_lpss");
 #define LPSS_CLK_DIVIDER   BIT(2)
 #define LPSS_LTR   BIT(3)
 #define LPSS_SAVE_CTX  BIT(4)
-#define LPSS_NO_D3_DELAY   BIT(5)
+/*
+ * For some devices the DSDT AML code for another device turns off the device
+ * before our 

[PATCH v10 15/17] drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller

2020-09-03 Thread Hans de Goede
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.

I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which greatly exceeds
the PWM_MAX_PERIOD_NS define in the Crystal Cove PMIC PWM driver, which
used to be 21333.

This PWM_MAX_PERIOD_NS define was actually based on a bug in the PWM
driver where its period and duty-cycle times where off by a factor of 256.

Due to this bug the hardcoded CRC_PMIC_PWM_PERIOD_NS value of 21333 would
result in the PWM driver using its divider of 128, which would result in
a PWM output frequency of 600 Hz / 256 / 128 = 183 Hz. So actually
pretty close to the default VBT value of 200 Hz.

Now that this bug in the pwm-crc driver is fixed, we can actually use
the VBT defined frequency.

This is important because:

a) With the pwm-crc driver fixed it will now translate the hardcoded
CRC_PMIC_PWM_PERIOD_NS value of 21333 ns / 46 Khz to a PWM output
frequency of 23 KHz (the max it can do).

b) The pwm-lpss driver used on many models has always honored the
21333 ns / 46 Khz request

Some panels do not like such high output frequencies. E.g. on a Terra
Pad 1061 tablet, using the LPSS PWM controller, the backlight would go
from off to max, when changing the sysfs backlight brightness value from
90-100%, anything under aprox. 90% would turn the backlight fully off.

Honoring the VBT specified PWM frequency will also hopefully fix the
various bug reports which we have received about users perceiving the
backlight to flicker after a suspend/resume cycle.

Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_panel.c| 19 +++
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e8f809161c75..7171e7c8d928 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -223,6 +223,7 @@ struct intel_panel {
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
+   int pwm_period_ns;
 
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index df7472a3b9f8..5a13089d2fc0 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -40,8 +40,6 @@
 #include "intel_dsi_dcs_backlight.h"
 #include "intel_panel.h"
 
-#define CRC_PMIC_PWM_PERIOD_NS 21333
-
 void
 intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
   struct drm_display_mode *adjusted_mode)
@@ -597,7 +595,7 @@ static u32 pwm_get_backlight(struct intel_connector 
*connector)
int duty_ns;
 
duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
-   return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+   return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
 }
 
 static void lpt_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
@@ -671,9 +669,10 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
 static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
-   int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+   int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
-   pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+   pwm_config(panel->backlight.pwm, duty_ns,
+  panel->backlight.pwm_period_ns);
 }
 
 static void
@@ -1917,6 +1916,9 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
return -ENODEV;
}
 
+   panel->backlight.pwm_period_ns = NSEC_PER_SEC /
+get_vbt_pwm_freq(dev_priv);
+
/*
 * FIXME: pwm_apply_args() should be removed when switching to
 * the atomic PWM API.
@@ -1926,9 +1928,10 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
panel->backlight.min = 0; /* 0% */
panel->backlight.max = 100; /* 100% */
level = intel_panel_compute_brightness(connector, 100);
-   ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+   ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
 
-   retval = pwm_config(panel->backlight.pwm, ns, CRC_PMIC_PWM_PERIOD_NS);
+   retval = pwm_config(panel->backlight.pwm, ns,
+   panel->backlight.pwm_period_ns);
if 

[PATCH v10 09/17] pwm: crc: Fix off-by-one error in the clock-divider calculations

2020-09-03 Thread Hans de Goede
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.

So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested frequency was so high that the
calculation has already resulted in a (rounded) divider value of 0.

Note that before this fix, setting a period of PWM_MAX_PERIOD_NS which
corresponds to the max. divider value of 128 could have resulted in a
bug where the code would use 128 as divider-register value which would
have resulted in an actual divider value of 0 (and the enable bit being
set). A rounding error stopped this bug from actually happen. This
same rounding error means that after the subtraction of 1 it is impossible
to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow
setting a divider of 128 (register-value 127).

Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Introduce crc_pwm_calc_clk_div() here instead of later in the patch-set
  to reduce the amount of churn in the patch-set a bit
---
 drivers/pwm/pwm-crc.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index c056eb9b858c..44ec7d5b63e1 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -22,7 +22,7 @@
 #define PWM_MAX_LEVEL  0xFF
 
 #define PWM_BASE_CLK_MHZ   6   /* 6 MHz */
-#define PWM_MAX_PERIOD_NS  5461333 /* 183 Hz */
+#define PWM_MAX_PERIOD_NS  5461334 /* 183 Hz */
 
 /**
  * struct crystalcove_pwm - Crystal Cove PWM controller
@@ -39,6 +39,18 @@ static inline struct crystalcove_pwm *to_crc_pwm(struct 
pwm_chip *pc)
return container_of(pc, struct crystalcove_pwm, chip);
 }
 
+static int crc_pwm_calc_clk_div(int period_ns)
+{
+   int clk_div;
+
+   clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
+   /* clk_div 1 - 128, maps to register values 0-127 */
+   if (clk_div > 0)
+   clk_div--;
+
+   return clk_div;
+}
+
 static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
 {
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
@@ -68,11 +80,10 @@ static int crc_pwm_config(struct pwm_chip *c, struct 
pwm_device *pwm,
}
 
if (pwm_get_period(pwm) != period_ns) {
-   int clk_div;
+   int clk_div = crc_pwm_calc_clk_div(period_ns);
 
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
-   clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
 
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
-- 
2.28.0

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


[PATCH v10 11/17] pwm: crc: Enable/disable PWM output on enable/disable

2020-09-03 Thread Hans de Goede
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register

So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set it again on re-enable.

Acked-by: Uwe Kleine-König 
Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Remove paragraph about tri-stating the output from the commit message,
  we don't have a datasheet so this was just an unfounded guess
---
 drivers/pwm/pwm-crc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 81232da0c767..b72008c9b072 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -54,7 +54,9 @@ static int crc_pwm_calc_clk_div(int period_ns)
 static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
 {
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+   int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
 
+   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div | PWM_OUTPUT_ENABLE);
regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
 
return 0;
@@ -63,8 +65,10 @@ static int crc_pwm_enable(struct pwm_chip *c, struct 
pwm_device *pwm)
 static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
 {
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+   int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
 
regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div);
 }
 
 static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
-- 
2.28.0

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


[PATCH v10 04/17] pwm: lpss: Add range limit check for the base_unit register value

2020-09-03 Thread Hans de Goede
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.

But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.

When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:

base_unit &= (base_unit_range - 1);

But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.

This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).

Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v5:
- Use clamp_val(... instead of clam_t(unsigned long long, ...

Changes in v3:
- Change upper limit of clamp to (base_unit_range - 1)
- Add Fixes tag
---
 drivers/pwm/pwm-lpss.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b1fc634af1..da9bc3d10104 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -97,6 +97,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
freq *= base_unit_range;
 
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
+   /* base_unit must not be 0 and we also want to avoid overflowing it */
+   base_unit = clamp_val(base_unit, 1, base_unit_range - 1);
 
on_time_div = 255ULL * duty_ns;
do_div(on_time_div, period_ns);
@@ -105,7 +107,6 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
orig_ctrl = ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
-   base_unit &= (base_unit_range - 1);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
 
-- 
2.28.0

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


[PATCH v10 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state

2020-09-03 Thread Hans de Goede
Before this commit pwm_lpss_apply() was assuming 2 pre-conditions
were met by the existing hardware state:

1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the desired values.

2. That the controller is enabled when the cached
pwm_state.enabled says that the controller is enabled.

As the long history of fixes for subtle (often suspend/resume)
lpss-pwm issues shows, these assumptions are not necessary
always true.

1. Specifically is not true on some (*) Cherry Trail devices
with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
b. sets the base-unit to 0 and writes the update bit to apply/commit
c. restores the original ctrl value without setting the update bit,
so that the 0 base-unit value is still in use.

2. Assumption 2. currently is true, but only because of the code which
saves/restores the state on suspend/resume. By convention restoring the
PWM state should be done by the PWM consumer and the presence of this
code in the pmw-lpss driver is a bug. Therefor the save/restore code will
be dropped in the next patch in this series, after which this assumption
also is no longer true.

This commit changes the pwm_lpss_apply() to not make any assumptions about
the state the hardware is in. Instead it makes pwm_lpss_apply() always
fully program the PWM controller, making it much less fragile.

*) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
and various Medion models.

Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v10:
- Fixup some wording / mistakes in the commit message

Changes in v9:
- This is a new patch in v9 of this series
---
 drivers/pwm/pwm-lpss.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 8a136ba2a583..9c5c7217c9b6 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -85,7 +85,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
unsigned long long on_time_div;
unsigned long c = lpwm->info->clk_rate, base_unit_range;
unsigned long long base_unit, freq = NSEC_PER_SEC;
-   u32 orig_ctrl, ctrl;
+   u32 ctrl;
 
do_div(freq, period_ns);
 
@@ -104,16 +104,14 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
do_div(on_time_div, period_ns);
on_time_div = 255ULL - on_time_div;
 
-   orig_ctrl = ctrl = pwm_lpss_read(pwm);
+   ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
 
-   if (orig_ctrl != ctrl) {
-   pwm_lpss_write(pwm, ctrl);
-   pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
-   }
+   pwm_lpss_write(pwm, ctrl);
+   pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
 }
 
 static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond)
@@ -124,8 +122,7 @@ static inline void pwm_lpss_cond_enable(struct pwm_device 
*pwm, bool cond)
 
 static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
   struct pwm_device *pwm,
-  const struct pwm_state *state,
-  bool enable)
+  const struct pwm_state *state)
 {
int ret;
 
@@ -134,12 +131,12 @@ static int pwm_lpss_prepare_enable(struct pwm_lpss_chip 
*lpwm,
return ret;
 
pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
-   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
+   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
ret = pwm_lpss_wait_for_update(pwm);
if (ret)
return ret;
 
-   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);
+   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
return 0;
 }
 
@@ -152,11 +149,11 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
-   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state);
if (ret)
pm_runtime_put(chip->dev);
} else {
-   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
-- 
2.28.0

___
dri-devel mailing list

[PATCH v10 08/17] pwm: crc: Fix period / duty_cycle times being off by a factor of 256

2020-09-03 Thread Hans de Goede
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.

The pwm-crc code before this commit assumed that a clock-divider
setting of 1 means that the PWM output is running at 6 MHZ, if that
is true, where do these 256 duty-cycle steps come from?

This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that
seems unlikely for a PMIC which is using a silicon process optimized for
power-switching transistors. It is way more likely that there is an 8
bit counter for the duty cycle which acts as an extra fixed divider
wrt the PWM output frequency.

The main user of the pwm-crc driver is the i915 GPU driver which uses it
for backlight control. Lets compare the PWM register values set by the
video-BIOS (the GOP), assuming the extra fixed divider is present versus
the PWM frequency specified in the Video-BIOS-Tables:

Device: PWM Hz set by BIOS  PWM Hz specified in VBT
Asus T100TA 200 200
Asus T100HA 200 200
Lenovo Miix 2 8 23437   2
Toshiba WT8-A   23437   2

So as we can see if we assume the extra division by 256 then the register
values set by the GOP are an exact match for the VBT values, where as
otherwise the values would be of by a factor of 256.

This commit fixes the period / duty_cycle calculations to take the
extra division by 256 into account.

Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define
---
 drivers/pwm/pwm-crc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 272eeb071147..c056eb9b858c 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -21,8 +21,8 @@
 
 #define PWM_MAX_LEVEL  0xFF
 
-#define PWM_BASE_CLK   600  /* 6 MHz */
-#define PWM_MAX_PERIOD_NS  21333/* 46.875KHz */
+#define PWM_BASE_CLK_MHZ   6   /* 6 MHz */
+#define PWM_MAX_PERIOD_NS  5461333 /* 183 Hz */
 
 /**
  * struct crystalcove_pwm - Crystal Cove PWM controller
@@ -72,7 +72,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct 
pwm_device *pwm,
 
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
-   clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
+   clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
 
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
-- 
2.28.0

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


[PATCH v10 05/17] pwm: lpss: Add pwm_lpss_prepare_enable() helper

2020-09-03 Thread Hans de Goede
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.

This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enabled -> enabled transition there, so that we can error check
the entire transition in a single place and only have one pm_runtime_put()
on failure call site.

While working on this I noticed that the enabled -> enabled (update
settings) path was quite similar, so I've added an enable parameter to
the new pwm_lpss_prepare_enable() helper, which allows using it in that
path too.

Suggested-by: Andy Shevchenko 
Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
 drivers/pwm/pwm-lpss.c | 45 --
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index da9bc3d10104..8a136ba2a583 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -122,41 +122,48 @@ static inline void pwm_lpss_cond_enable(struct pwm_device 
*pwm, bool cond)
pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
 }
 
+static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
+  struct pwm_device *pwm,
+  const struct pwm_state *state,
+  bool enable)
+{
+   int ret;
+
+   ret = pwm_lpss_is_updating(pwm);
+   if (ret)
+   return ret;
+
+   pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
+   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
+   ret = pwm_lpss_wait_for_update(pwm);
+   if (ret)
+   return ret;
+
+   pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);
+   return 0;
+}
+
 static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
  const struct pwm_state *state)
 {
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
-   int ret;
+   int ret = 0;
 
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
-   ret = pwm_lpss_is_updating(pwm);
-   if (ret) {
-   pm_runtime_put(chip->dev);
-   return ret;
-   }
-   pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, 
state->period);
-   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
-   ret = pwm_lpss_wait_for_update(pwm);
-   if (ret) {
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
+   if (ret)
pm_runtime_put(chip->dev);
-   return ret;
-   }
-   pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
} else {
-   ret = pwm_lpss_is_updating(pwm);
-   if (ret)
-   return ret;
-   pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, 
state->period);
-   return pwm_lpss_wait_for_update(pwm);
+   ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
pm_runtime_put(chip->dev);
}
 
-   return 0;
+   return ret;
 }
 
 static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
-- 
2.28.0

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


[PATCH v10 03/17] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

2020-09-03 Thread Hans de Goede
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.

So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input clock-cycles the counter has been increased from 0 to
65535 and it will overflow on the next cycle, so it will overflow after
every 65536 clock cycles and thus the calculations done in
pwm_lpss_prepare() should use 65536 and not 65535.

This commit fixes this. Note this also aligns the calculations in
pwm_lpss_prepare() with those in pwm_lpss_get_state().

Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid
potential overflow of base_unit"). The next patch in this series really
fixes the potential overflow of the base_unit value.

Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko 
Acked-by: Uwe Kleine-König 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Add Fixes tag
- Add Reviewed-by: Andy Shevchenko tag
---
 drivers/pwm/pwm-lpss.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 9d965ffe66d1..43b1fc634af1 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -93,7 +93,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
 * The equation is:
 * base_unit = round(base_unit_range * freq / c)
 */
-   base_unit_range = BIT(lpwm->info->base_unit_bits) - 1;
+   base_unit_range = BIT(lpwm->info->base_unit_bits);
freq *= base_unit_range;
 
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
@@ -104,8 +104,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
 
orig_ctrl = ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
-   ctrl &= ~(base_unit_range << PWM_BASE_UNIT_SHIFT);
-   base_unit &= base_unit_range;
+   ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
+   base_unit &= (base_unit_range - 1);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
 
-- 
2.28.0

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


  1   2   >