from:"Clint Taylor"

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2

2021-12-02 Thread Clint Taylor


Reviewed-by: Clint Taylor 

-Clint

On 11/16/21 9:48 AM, Matt Roper wrote:

From: Matt Atwood 

Extend existing workaround 1409120013 to DG2.

Cc: José Roberto de Souza 
Signed-off-by: Matt Atwood 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 89dc7f69baf3..e721c421cc58 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7444,9 +7444,9 @@ static void icl_init_clock_gating(struct drm_i915_private 
*dev_priv)
  
  static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)

  {
-   /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
+   /* Wa_1409120013:tgl,rkl,adl-s,dg1,dg2 */
if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
-   IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
+   IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv) || IS_DG2(dev_priv))
intel_uncore_write(_priv->uncore, ILK_DPFC_CHICKEN,
   DPFC_CHICKEN_COMP_DUMMY_PIXEL);

Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/dg2: Add Wa_16013000631

2021-12-02 Thread Clint Taylor


Reviewed-by: Clint Taylor 

-Clint


On 11/16/21 9:48 AM, Matt Roper wrote:

From: Ramalingam C 

Invalidate IC cache through pipe control command as part of the ctx
restore flow through indirect ctx pointer.

v2:
  - Move pipe control from xcs indirect context to the rcs indirect
context.  We'll eventually need this on the CCS engines too, but
support for those hasn't landed yet.

Cc: Chris Wilson 
Signed-off-by: Ramalingam C 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 56156cf18c41..b3489599e4de 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1167,6 +1167,11 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context 
*ce, u32 *cs)
cs = gen12_emit_cmd_buf_wa(ce, cs);
cs = gen12_emit_restore_scratch(ce, cs);
  
+	/* Wa_16013000631:dg2 */

+   if (IS_DG2_GRAPHICS_STEP(ce->engine->i915, G10, STEP_B0, STEP_C0) ||
+   IS_DG2_G11(ce->engine->i915))
+   cs = gen8_emit_pipe_control(cs, 
PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE, 0);
+
return cs;
  }

Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/dg2: Add Wa_16011777198

2021-12-02 Thread Clint Taylor


Correct,

Reviewed-by: Clint Taylor 

-Clint



On 11/16/21 9:48 AM, Matt Roper wrote:

Coarse power gating for render should not be enabled on some DG2
steppings.

Bspec: 52698
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_rc6.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 43093dd2d0c9..c3155ee58689 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -117,10 +117,17 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6)
GEN6_RC_CTL_RC6_ENABLE |
GEN6_RC_CTL_EI_MODE(1);
  
-	pg_enable =

-   GEN9_RENDER_PG_ENABLE |
-   GEN9_MEDIA_PG_ENABLE |
-   GEN11_MEDIA_SAMPLER_PG_ENABLE;
+   /* Wa_16011777198 - Render powergating must remain disabled */
+   if (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) ||
+   IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0))
+   pg_enable =
+   GEN9_MEDIA_PG_ENABLE |
+   GEN11_MEDIA_SAMPLER_PG_ENABLE;
+   else
+   pg_enable =
+   GEN9_RENDER_PG_ENABLE |
+   GEN9_MEDIA_PG_ENABLE |
+   GEN11_MEDIA_SAMPLER_PG_ENABLE;
  
  	if (GRAPHICS_VER(gt->i915) >= 12) {

for (i = 0; i < I915_MAX_VCS; i++)

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/dg2: Add Wa_14010547955

2021-12-02 Thread Clint Taylor


Looks correct.

Reviewed-by: Clint Taylor 

-Clint


On 11/16/21 9:48 AM, Matt Roper wrote:

This workaround is documented a bit strangely in the bspec; it's listed
as an A0 workaround, but the description clarifies that the workaround
is implicitly handled by the hardware and what the driver really needs
to do is program a chicken bit to reenable some internal behavior.

Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/display/intel_display.c | 4 
  drivers/gpu/drm/i915/i915_reg.h  | 5 +++--
  2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0ceee8ac6671..1639bdbe2091 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -988,6 +988,10 @@ static void icl_set_pipe_chicken(const struct 
intel_crtc_state *crtc_state)
else if (DISPLAY_VER(dev_priv) >= 13)
tmp |= UNDERRUN_RECOVERY_DISABLE_ADLP;
  
+	/* Wa_14010547955:dg2 */

+   if (IS_DG2_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER))
+   tmp |= DG2_RENDER_CCSTAG_4_3_EN;
+
intel_de_write(dev_priv, PIPE_CHICKEN(pipe), tmp);
  }
  
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h

index f15ffc53e858..c187ec122fdb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8568,8 +8568,9 @@ enum {
   _PIPEB_CHICKEN)
  #define   UNDERRUN_RECOVERY_DISABLE_ADLP  REG_BIT(30)
  #define   UNDERRUN_RECOVERY_ENABLE_DG2REG_BIT(30)
-#define   PIXEL_ROUNDING_TRUNC_FB_PASSTHRU (1 << 15)
-#define   PER_PIXEL_ALPHA_BYPASS_EN(1 << 7)
+#define   PIXEL_ROUNDING_TRUNC_FB_PASSTHRU REG_BIT(15)
+#define   DG2_RENDER_CCSTAG_4_3_EN REG_BIT(12)
+#define   PER_PIXEL_ALPHA_BYPASS_ENREG_BIT(7)
  
  #define VFLSKPD_MMIO(0x62a8)

  #define   DIS_OVER_FETCH_CACHEREG_BIT(1)

Re: [PATCH 3/3] drm/i915/dg2: Program recommended HW settings

2021-11-11 Thread Clint Taylor


Reviewed-by: Clint Taylor 

-Clint


On 11/2/21 3:25 PM, Matt Roper wrote:

The bspec's performance guide suggests programming specific values into
a few registers for optimal performance.  Although these aren't
workarounds, it's easiest to handle them inside the GT workaround
functions (which will also ensure that the values set here are properly
melded with other bits in the same registers that _are_ set by
workarounds).

Bspec: 68331, 45395

Cc: Matt Atwood 
Cc: Lucas De Marchi 
Cc: Siddiqui Ayaz A 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 -
  drivers/gpu/drm/i915/i915_reg.h |  9 +++
  2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 37fd541a9719..51591119da15 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -558,6 +558,22 @@ static void icl_ctx_workarounds_init(struct 
intel_engine_cs *engine,
wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN11_DIS_PICK_2ND_EU);
  }
  
+/*

+ * These settings aren't actually workarounds, but general tuning settings that
+ * need to be programmed on dg2 platform.
+ */
+static void dg2_ctx_gt_tuning_init(struct intel_engine_cs *engine,
+  struct i915_wa_list *wal)
+{
+   wa_write_clr_set(wal, GEN11_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
+REG_FIELD_PREP(L3_PWM_TIMER_INIT_VAL_MASK, 0x7f));
+   wa_add(wal,
+  FF_MODE2,
+  FF_MODE2_TDS_TIMER_MASK,
+  FF_MODE2_TDS_TIMER_128,
+  0, false);
+}
+
  /*
   * These settings aren't actually workarounds, but general tuning settings 
that
   * need to be programmed on several platforms.
@@ -647,7 +663,7 @@ static void dg1_ctx_workarounds_init(struct intel_engine_cs 
*engine,
  static void dg2_ctx_workarounds_init(struct intel_engine_cs *engine,
 struct i915_wa_list *wal)
  {
-   gen12_ctx_gt_tuning_init(engine, wal);
+   dg2_ctx_gt_tuning_init(engine, wal);
  
  	/* Wa_16011186671:dg2_g11 */

if (IS_DG2_GRAPHICS_STEP(engine->i915, G11, STEP_A0, STEP_B0)) {
@@ -1482,6 +1498,14 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct 
i915_wa_list *wal)
  
  	/* Wa_14014830051:dg2 */

wa_write_clr(wal, SARB_CHICKEN1, COMP_CKN_IN);
+
+   /*
+* The following are not actually "workarounds" but rather
+* recommended tuning settings documented in the bspec's
+* performance guide section.
+*/
+   wa_write_or(wal, XEHP_L3SCQREG7, BLEND_FILL_CACHING_OPT_DIS);
+   wa_write_or(wal, GEN12_SQCM, EN_32B_ACCESS);
  }
  
  static void

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee39d6bd0f3c..ef3b5732faad 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -731,6 +731,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
  
  #define GEN12_OA_TLB_INV_CR _MMIO(0xceec)
  
+#define GEN12_SQCM		_MMIO(0x8724)

+#define   EN_32B_ACCESSREG_BIT(30)
+
  /* Gen12 OAR unit */
  #define GEN12_OAR_OACONTROL _MMIO(0x2960)
  #define  GEN12_OAR_OACONTROL_COUNTER_FORMAT_SHIFT 1
@@ -8506,6 +8509,12 @@ enum {
  #define  GEN8_LQSC_FLUSH_COHERENT_LINES   (1 << 21)
  #define  GEN8_LQSQ_NONIA_COHERENT_ATOMICS_ENABLE REG_BIT(22)
  
+#define GEN11_L3SQCREG5_MMIO(0xb158)

+#define   L3_PWM_TIMER_INIT_VAL_MASK   REG_GENMASK(9, 0)
+
+#define XEHP_L3SCQREG7 _MMIO(0xb188)
+#define   BLEND_FILL_CACHING_OPT_DIS   REG_BIT(3)
+
  /* GEN8 chicken */
  #define HDC_CHICKEN0  _MMIO(0x7300)
  #define ICL_HDC_MODE  _MMIO(0xE5F4)

Re: [PATCH 1/2] drm/i915/xehpsdv: Define MOCS table for XeHP SDV

2021-09-14 Thread Clint Taylor


Appears to match latest BSPEC

Reviewed-by: Clint Taylor 

-Clint


On 9/3/21 5:35 PM, Matt Roper wrote:

From: Lucas De Marchi 

Like DG1, XeHP SDV doesn't have LLC/eDRAM control values due to being a
dgfx card. XeHP SDV adds 2 more bits: L3_GLBGO to "push the Go point to
memory for L3 destined transaction" and L3_LKP to "enable Lookup for
uncacheable accesses".

Bspec: 45101
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Lucas De Marchi 
Signed-off-by: Stuart Summers 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_mocs.c | 35 +++-
  1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index e96afd7beb49..133cfe07cb9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -42,6 +42,8 @@ struct drm_i915_mocs_table {
  #define L3_ESC(value) ((value) << 0)
  #define L3_SCC(value) ((value) << 1)
  #define _L3_CACHEABILITY(value)   ((value) << 4)
+#define L3_GLBGO(value)((value) << 6)
+#define L3_LKUP(value) ((value) << 7)
  
  /* Helper defines */

  #define GEN9_NUM_MOCS_ENTRIES 64  /* 63-64 are reserved, but configured. */
@@ -315,6 +317,31 @@ static const struct drm_i915_mocs_entry dg1_mocs_table[] = 
{
MOCS_ENTRY(63, 0, L3_1_UC),
  };
  
+static const struct drm_i915_mocs_entry xehpsdv_mocs_table[] = {

+   /* wa_1608975824 */
+   MOCS_ENTRY(0, 0, L3_3_WB | L3_LKUP(1)),
+
+   /* UC - Coherent; GO:L3 */
+   MOCS_ENTRY(1, 0, L3_1_UC | L3_LKUP(1)),
+   /* UC - Coherent; GO:Memory */
+   MOCS_ENTRY(2, 0, L3_1_UC | L3_GLBGO(1) | L3_LKUP(1)),
+   /* UC - Non-Coherent; GO:Memory */
+   MOCS_ENTRY(3, 0, L3_1_UC | L3_GLBGO(1)),
+   /* UC - Non-Coherent; GO:L3 */
+   MOCS_ENTRY(4, 0, L3_1_UC),
+
+   /* WB */
+   MOCS_ENTRY(5, 0, L3_3_WB | L3_LKUP(1)),
+
+   /* HW Reserved - SW program but never use. */
+   MOCS_ENTRY(48, 0, L3_3_WB | L3_LKUP(1)),
+   MOCS_ENTRY(49, 0, L3_1_UC | L3_LKUP(1)),
+   MOCS_ENTRY(60, 0, L3_1_UC),
+   MOCS_ENTRY(61, 0, L3_1_UC),
+   MOCS_ENTRY(62, 0, L3_1_UC),
+   MOCS_ENTRY(63, 0, L3_1_UC),
+};
+
  enum {
HAS_GLOBAL_MOCS = BIT(0),
HAS_ENGINE_MOCS = BIT(1),
@@ -344,7 +371,13 @@ static unsigned int get_mocs_settings(const struct 
drm_i915_private *i915,
memset(table, 0, sizeof(struct drm_i915_mocs_table));
  
  	table->unused_entries_index = I915_MOCS_PTE;

-   if (IS_DG1(i915)) {
+   if (IS_XEHPSDV(i915)) {
+   table->size = ARRAY_SIZE(xehpsdv_mocs_table);
+   table->table = xehpsdv_mocs_table;
+   table->uc_index = 2;
+   table->n_entries = GEN9_NUM_MOCS_ENTRIES;
+   table->unused_entries_index = 5;
+   } else if (IS_DG1(i915)) {
table->size = ARRAY_SIZE(dg1_mocs_table);
table->table = dg1_mocs_table;
table->uc_index = 1;

Re: [PATCH v3 0/3] add LG panel to dpcd quirk database

2018-09-11 Thread Clint Taylor




On 09/11/2018 01:56 AM, Lee, Shawn C wrote:

Only specific N value (0x8000) would be acceptable for LG
LP140WF6-SPM1 eDP panel which is running at asynchronous
clock mode. With the other N value, it will enter BITS mode
and display black screen. This patch series set constant N
value for specific sink/branch device that would cover
similar issue.

Cc: Jani Nikula 
Cc: Cooper Chiou 
Cc: Matt Atwood 
Cc: Maarten Lankhorst 
Cc: Dhinakaran Pandiyan 
Cc: Clint Taylor 

Lee, Shawn C (3):
   drm: Add support for device_id based detection.
   drm: Change limited M/N quirk to constant N quirk.
   drm: add LG eDP panel to quirk database

  drivers/gpu/drm/drm_dp_helper.c  | 17 -
  drivers/gpu/drm/i915/intel_display.c | 28 +---
  drivers/gpu/drm/i915/intel_display.h |  2 +-
  drivers/gpu/drm/i915/intel_dp.c  |  8 
  drivers/gpu/drm/i915/intel_dp_mst.c  |  6 +++---
  include/drm/drm_dp_helper.h  |  6 +++---
  6 files changed, 40 insertions(+), 27 deletions(-)



Tested quirk on Analogix 7737 based USB_C->HDMI dongle that the original 
Limited M/N quirk was designed around. New quirk appears to work correctly.


-Clint

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

Re: [PATCH] drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state

2018-04-16 Thread Clint Taylor




On 04/16/2018 08:53 AM, Imre Deak wrote:

LSPCON adapters in low-power state may ignore the first I2C write during
TMDS output buffer enabling, resulting in a blank screen even with an
otherwise enabled pipe. Fix this by reading back and validating the
written value a few times.

The problem was noticed on GLK machines with an onboard LSPCON adapter
after entering/exiting DC5 power state. Doing an I2C read of the adapter
ID as the first transaction - instead of the I2C write to enable the
TMDS buffers - returns the correct value. Based on this we assume that
the transaction itself is sent properly, it's only the adapter that is
not ready for some reason to accept this first write after waking from
low-power state. In my case the second I2C write attempt always
succeeded.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105854
Cc: Clinton Taylor <clinton.a.tay...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Imre Deak <imre.d...@intel.com>
---
  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 39 +--
  1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 02a50929af67..e7f4fe2848a5 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -350,19 +350,44 @@ int drm_dp_dual_mode_set_tmds_output(enum 
drm_dp_dual_mode_type type,
  {
uint8_t tmds_oen = enable ? 0 : DP_DUAL_MODE_TMDS_DISABLE;
ssize_t ret;
+   int retry;
  
  	if (type < DRM_DP_DUAL_MODE_TYPE2_DVI)

return 0;
  
-	ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,

-_oen, sizeof(tmds_oen));
-   if (ret) {
-   DRM_DEBUG_KMS("Failed to %s TMDS output buffers\n",
- enable ? "enable" : "disable");
-   return ret;
+   /*
+* LSPCON adapters in low-power state may ignore the first write, so
+* read back and verify the written value a few times.
+*/
+   for (retry = 0; retry < 3; retry++) {
+   uint8_t tmp;
+
+   ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
+_oen, sizeof(tmds_oen));
+   if (ret) {
+   DRM_DEBUG_KMS("Failed to %s TMDS output buffers (%d 
attempts)\n",
+ enable ? "enable" : "disable",
+ retry + 1);
+   return ret;
+   }
+
+   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
+   , sizeof(tmp));
+   if (ret) {
+   DRM_DEBUG_KMS("I2C read failed during TMDS output buffer %s 
(%d attempts)\n",
+ enable ? "enabling" : "disabling",
+ retry + 1);
+   return ret;
+   }
+
+   if (tmp == tmds_oen)
+   return 0;
}
  
-	return 0;

+   DRM_DEBUG_KMS("I2C write value mismatch during TMDS output buffer %s\n",
+ enable ? "enabling" : "disabling");
+
+   return -EIO;
  }
  EXPORT_SYMBOL(drm_dp_dual_mode_set_tmds_output);
  


Appears to fix the issue seen on GLK with LSPCON and DMC firmware 
loaded. Customer was concerned about the fix being in DRM instead of 
i915. However, there are no other SOCs that use this DRM function.


Reviewed-by: Clint Taylor <clinton.a.tay...@intel.com>
Tested-by: Clint Taylor <clinton.a.tay...@intel.com>

-Clint


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

Re: [PATCH 2/4] intel: Add Cannonlake PCI IDs for Y-skus.

2017-06-29 Thread Clint Taylor


Reviewed-by: Clinton Taylor 

-Clint



On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:

By the Spec all CNL Y skus are 2+2, i.e. GT2.

This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")

v2: Add kernel commit id for reference.

Cc: Anusha Srivatsa 
Cc: Clinton Taylor 
Signed-off-by: Rodrigo Vivi 
---
  intel/intel_chipset.h | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index e6b49d7..37579c6 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -237,6 +237,12 @@
  #define PCI_CHIP_CANNONLAKE_U_GT2_1   0x5A5A
  #define PCI_CHIP_CANNONLAKE_U_GT2_2   0x5A42
  #define PCI_CHIP_CANNONLAKE_U_GT2_3   0x5A4A
+#define PCI_CHIP_CANNONLAKE_Y_GT2_00x5A51
+#define PCI_CHIP_CANNONLAKE_Y_GT2_10x5A59
+#define PCI_CHIP_CANNONLAKE_Y_GT2_20x5A41
+#define PCI_CHIP_CANNONLAKE_Y_GT2_30x5A49
+#define PCI_CHIP_CANNONLAKE_Y_GT2_40x5A71
+#define PCI_CHIP_CANNONLAKE_Y_GT2_50x5A79
  
  #define IS_MOBILE(devid)	((devid) == PCI_CHIP_I855_GM || \

 (devid) == PCI_CHIP_I915_GM || \
@@ -501,12 +507,20 @@
 IS_GEN8(dev) || \
 IS_GEN9(dev))
  
+#define IS_CNL_Y(devid)		((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 || \

+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
+
  #define IS_CNL_U(devid)   ((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 
|| \
 (devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
 (devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
 (devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
  
-#define IS_CANNONLAKE(devid)	(IS_CNL_U(devid))

+#define IS_CANNONLAKE(devid)   (IS_CNL_U(devid) || \
+IS_CNL_Y(devid))
  
  #define IS_GEN10(devid)		(IS_CANNONLAKE(devid))
  


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

Re: [PATCH 1/4] intel: Add Cannonlake PCI IDs for U-skus.

2017-06-29 Thread Clint Taylor


Reviewed-by: Clinton Taylor 

-Clint



On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:

Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.

This is a copy of merged i915's
commit e918d79a5d0a ("drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.")

v2: Remove PCI IDs for SKU not mentioned in spec.
v3: Add kernel commit id for reference.

Cc: Anusha Srivatsa 
Cc: Clinton Taylor 
Signed-off-by: Rodrigo Vivi 
---
  intel/intel_chipset.h | 13 +
  1 file changed, 13 insertions(+)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 891b50f..e6b49d7 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -233,6 +233,11 @@
  #define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
  #define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
  
+#define PCI_CHIP_CANNONLAKE_U_GT2_0	0x5A52

+#define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A
+#define PCI_CHIP_CANNONLAKE_U_GT2_20x5A42
+#define PCI_CHIP_CANNONLAKE_U_GT2_30x5A4A
+
  #define IS_MOBILE(devid)  ((devid) == PCI_CHIP_I855_GM || \
 (devid) == PCI_CHIP_I915_GM || \
 (devid) == PCI_CHIP_I945_GM || \
@@ -496,5 +501,13 @@
 IS_GEN8(dev) || \
 IS_GEN9(dev))
  
+#define IS_CNL_U(devid)		((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 || \

+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
+
+#define IS_CANNONLAKE(devid)   (IS_CNL_U(devid))
+
+#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
  
  #endif /* _INTEL_CHIPSET_H */


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

Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX

2017-05-30 Thread Clint Taylor




On 05/26/2017 12:18 AM, Daniel Vetter wrote:

On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:

From: Hans Verkuil 

This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.

Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.

Signed-off-by: Hans Verkuil 
---
  drivers/gpu/drm/Kconfig  |   3 +
  drivers/gpu/drm/Makefile |   1 +
  drivers/gpu/drm/drm_dp_cec.c | 196 +++
  include/drm/drm_dp_helper.h  |  24 ++
  4 files changed, 224 insertions(+)
  create mode 100644 drivers/gpu/drm/drm_dp_cec.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 78d7fc0ebb57..dd771ce8a3d0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE
  default case is N. Details and instructions how to build your own
  EDID data are given in Documentation/EDID/HOWTO.txt.
  
+config DRM_DP_CEC

+   bool

We generally don't bother with a Kconfig for every little bit in drm, not
worth the trouble (yes I know there's some exceptions, but somehow they're
all from soc people). Just smash this into the KMS_HELPER one and live is
much easier for drivers. Also allows you to drop the dummy inline
functions.
All of the functions like cec_register_adapter() require 
CONFIG_MEDIA_CEC_SUPPORT.
This will add a new dependency to the DRM drivers. All instances of 
CONFIG_DRM_DP_CEC should be changed to CONFIG_MEDIA_CEC_SUPPORT so drm 
can still be used without the media CEC drivers.


-Clint



The other nitpick: Pls kernel-doc the functions exported to drivers, and
then pull them into Documentation/gpu/drm-kms-helpers.rst, next to the
existing DP helper section.

Thanks, Daniel


+
  config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 59f0f9b696eb..22f1a17dfc8a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -34,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
drm_scdc_helper.o
  
+drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o

  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
new file mode 100644
index ..44c544ba53cb
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,196 @@
+/*
+ * DisplayPort CEC-Tunneling-over-AUX support
+ *
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   ssize_t err = 0;
+
+   if (enable)
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL,
+DP_CEC_TUNNELING_ENABLE);
+   else
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, 0);
+   return (enable && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   u8 mask[2] = { 0x00, 0x80 };
+   ssize_t err;
+
+   if (addr != CEC_LOG_ADDR_INVALID) {
+   u16 la_mask = adap->log_addrs.log_addr_mask;
+
+   la_mask |= 0x8000 | (1 << addr);
+   mask[0] = la_mask & 0xff;
+   mask[1] = la_mask >> 8;
+   }
+   err = drm_dp_dpcd_write(aux, DP_CEC_LOGICAL_ADDRESS_MASK, mask, 2);
+   return (addr != CEC_LOG_ADDR_INVALID && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
+   u32 signal_free_time, struct cec_msg *msg)
+{
+   struct drm_dp_aux

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-05-30 Thread Clint Taylor

On 05/30/2017 02:29 PM, Hans Verkuil wrote:

On 05/30/2017 10:32 PM, Clint Taylor wrote:

On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:

On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil <hverk...@xs4all.nl> wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete
newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst
thing (a
simple dp port multiplexer is what I use for testing here, then
plug in a
converter dongle or cable into that) then probably better to not
wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on
buying a
dp multiplexer to make sure there is nothing special I need to do
for mst.

The CEC Tunneling is all in the branch device, so if I understand
things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output
they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to
their

datasheet is supposed to implement CEC Tunneling, but if they do
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware
issue
or something else. The BIOS is able to do some CEC, but whether
they hook
into the MegaChip or have the CEC pin connected to a GPIO or
something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would
be very
helpful.
It's called LSPCON, see i915/intel_lspcon.c, basically to support
HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for
us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't
support

that in i915.

I don't know about the CEC on that.

My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over
Aux.
The release notes for the NUC state that there is a BIOS
configuration
option for enabling support. My doesn't have the option but the
LSPCON

fully supports CEC.

What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your
NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have
actually
tested it somehow? The only working solution I have seen mentioned
for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC
pin to

some microcontroller.

The only working chipset I have seen is the Parade PS176.

If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?

[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info

Connector info
--
connector 48: type DP-1, status: connected
name:
physical dimensions: 700x400mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: 175IB0
HW: 1.0
SW: 7.32
Max TMDS clock: 60 kHz
Max bpc: 12

Huh. Based on this document:

https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf

this is the internal DP-to-HDMI adapter and it has the PS175. So it is a
Parade chipset, and I have seen that work before (at least the PS176).

This is the PS175 LSPCON on the NUC6.

connector 55: type DP-2, status: connected
name:
physical dimensions: 620x340mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: BCTRC0
HW: 2.0
SW: 0.26

And is this from a USB-C to HDMI adapter? Which one? I don't recognize
the ID.

This is a LSPCON inside the Google USB-C->HDMI dongle. This is actually
a MC2850 with what appears to be a custom ID. Datasheet claims CEC over
Aux and the pin is wired, but FW has it currently disabled.

-Clint

For the record, this is the internal HDMI output of my NUC7i5BNK:

connector 48: type DP-1, status: connected
name:
physical dimensions: 1050x590mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: MC2800
HW: 2.2
SW: 1.66
Max TMDS clock: 60 kHz
Max bpc: 16

Clearly a Megachip.

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-05-30 Thread Clint Taylor




On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil <hverk...@xs4all.nl> wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete 
newbie when it

comes to mst.
I don't really have more clue, but yeah if you don't have an mst 
thing (a
simple dp port multiplexer is what I use for testing here, then 
plug in a
converter dongle or cable into that) then probably better to not 
wire up

the code for it.
I think my NUC already uses mst internally. But I was planning on 
buying a
dp multiplexer to make sure there is nothing special I need to do 
for mst.


The CEC Tunneling is all in the branch device, so if I understand 
things

correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output 
they

use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do 
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware 
issue
or something else. The BIOS is able to do some CEC, but whether 
they hook
into the MegaChip or have the CEC pin connected to a GPIO or 
something and

have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would 
be very

helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have 
actually
tested it somehow? The only working solution I have seen mentioned 
for the

NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.


If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?


[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info
CRTC info
-
CRTC 32: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24
fb: 115, pos: 0x0, size: 3840x2160
encoder 47: type: DDI B, connectors:
connector 48: type: DP-1, status: connected, mode:
id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

cursor visible? no, position (0, 0), size 0x0, addr 0x
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, 
mode=0, scalers[1]: use=no, mode=0
--Plane id 26: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, 
src_pos=0.x0., src_size=1920.x1080., format=XR24 
little-endian (0x34325258), rotation=0 (0x0001)
--Plane id 28: type=OVL, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 
(0x0001)
--Plane id 30: type=CUR, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 
(0x0001)

underrun reporting: cpu=yes pch=yes
CRTC 39: pipe: B, active=yes, (size=3840x2160), dither=no, bpp=36
fb: 115, pos: 0x0, size: 3840x2160
encoder 54: type: DDI C, connectors:
connector 55: type: DP-2, status: connected, mode:
id 0:"3840x2160" freq 30 clock 296703 hdisp 3840 hss 4016 hse 
4104 htot 4400 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x48 flags 0x5

cursor visible? no, position (0, 0), size 0x0, addr 0x
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, 
mode=0, scalers[1]: use=no, mode=0
--Plane id 33: type=PRI, crtc_pos=   0x   0, crtc_size=3840x2160, 
src_pos=0.x0., src_size=3840.x2160., format=XR24 
little-endian (0x34325258), rotation=0 (0x0001)
--Plane id 35: type=OVL, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-05-30 Thread Clint Taylor




On 05/30/2017 09:49 AM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil <hverk...@xs4all.nl> wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete 
newbie when it

comes to mst.
I don't really have more clue, but yeah if you don't have an mst 
thing (a
simple dp port multiplexer is what I use for testing here, then 
plug in a
converter dongle or cable into that) then probably better to not 
wire up

the code for it.
I think my NUC already uses mst internally. But I was planning on 
buying a
dp multiplexer to make sure there is nothing special I need to do 
for mst.


The CEC Tunneling is all in the branch device, so if I understand 
things

correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output 
they

use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it 
is not
exposed as a capability. I'm not sure if it is a MegaChip firmware 
issue
or something else. The BIOS is able to do some CEC, but whether 
they hook
into the MegaChip or have the CEC pin connected to a GPIO or 
something and

have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be 
very

helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

slightly different command, but it still dumps DPCD 0x3000 for 48 bytes.

sudo dd if=/dev/drm_dp_aux0 bs=1 skip=12288 count=48 | hexdump -C
  07 00 00 00 00 00 00 00  00 00 00 00 00 00 00 80 
||
0010  f8 23 c4 8f 06 d8 59 7b  37 bb 1e 14 9c cb cd 88 
|.#Y{7...|
0020  4e 84 10 00 04 00 f7 f5  e2 fa a3 30 ad 42 ed 19 
|N..0.B..|





When you say "it does support CEC over Aux", does that mean you have 
actually
tested it somehow? The only working solution I have seen mentioned for 
the

NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.
I have a couple PS176 based devices that I purchased from Amazon that do 
not work even though they advertise support at DPCD 0x3000.


Club 3D USB-C->HDMI 2.0 UHD
UptabUSB-C->HDMI 2.0

-Clint




Regards,

Hans



-Clint




BR,
Jani.

It would be so nice to get MegaChip CEC Tunneling working on the 
NUC, because
then you have native CEC support without requiring any Pulse Eight 
adapter.


And add a CEC-capable USB-C to HDMI adapter and you have it on the 
USB-C

output as well.

Regards,

Hans






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

Re: [ANN] HDMI CEC Status Update

2017-05-30 Thread Clint Taylor




On 05/29/2017 11:53 PM, Hans Verkuil wrote:

For those who are interested in HDMI CEC support I made a little status
document that I intend to keep up to date:

https://hverkuil.home.xs4all.nl/cec-status.txt

My goal is to get CEC supported for any mainlined HDMI driver where 
the hardware

supports CEC.

If anyone is working on a CEC driver that I don't know already about, 
just drop

me an email so I can update the status.

I also started maintaining a list of DisplayPort to HDMI adapters that 
support
CEC. If you have one that works and is not on the list, then please 
let me know.
Seeing /dev/cecX is not enough, some adapters do not connect the CEC 
pin, so they
won't be able to detect any other CEC devices. See the test 
instructions in the
cec-status.txt file on how to make sure the adapter has a working CEC 
pin. I
plan to do some more testing this week, so hopefully the list will 
expand.


Would you also like a list of known USB-C->HDMI adapters that do not 
work? I have a couple that advertise support at DPCD 0x3000 but are not 
wired correctly.


-Clint




Thanks!

Hans
___
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 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

2017-05-30 Thread Clint Taylor




On 05/29/2017 04:06 AM, Jani Nikula wrote:

On Thu, 18 May 2017, Clint Taylor <clinton.a.tay...@intel.com> wrote:

On 05/18/2017 04:10 AM, Jani Nikula wrote:

Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just otherwise require special treatment. Start a common
quirk database the drivers can query based on the DP device
identification. At least for now, we leave the workarounds for the
drivers to implement as they see fit.

For starters, add a branch device that can't handle full 24-bit main
link Mdiv and Ndiv main link attributes properly. Naturally, the
workaround of reducing main link attributes for all devices ended up in
regressions for other devices. So here we are.

v2: Rebase on DRM DP desc read helpers

v3: Fix the OUI memcmp blunder (Clint)

Tested-by: Clinton Taylor <clinton.a.tay...@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.tay...@intel.com>

I pushed the series to drm-intel topic/dp-quirks branch based on
v4.12-rc3, with the goal of merging this to v4.12. Thanks for the review
and testing so far; would you mind giving that branch a go too, to
ensure I didn't screw anything up while applying?
Topic branch appears to work as expected. Quirk is applied only to OUI 
0x0022B9 and the n and m values are reduced.


Topic branch is:
Tested-by: Clinton Taylor <clinton.a.tay...@intel.com>

-Clint



BR,
Jani.



Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
Cc: Clint Taylor <clinton.a.tay...@intel.com>
Cc: Adam Jackson <a...@redhat.com>
Cc: Harry Wentland <harry.wentl...@amd.com>
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
   drivers/gpu/drm/drm_dp_helper.c | 52 
+++--
   include/drm/drm_dp_helper.h | 32 +
   2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 52e0ca9a5bb1..213fb837e1c4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1209,6 +1209,51 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
   }
   EXPORT_SYMBOL(drm_dp_stop_crc);
   
+struct dpcd_quirk {

+   u8 oui[3];
+   bool is_branch;
+   u32 quirks;
+};
+
+#define OUI(first, second, third) { (first), (second), (third) }
+
+static const struct dpcd_quirk dpcd_quirk_list[] = {
+   /* Analogix 7737 needs reduced M and N at HBR2 link rates */
+   { OUI(0x00, 0x22, 0xb9), true, BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
+};
+
+#undef OUI
+
+/*
+ * Get a bit mask of DPCD quirks for the sink/branch device identified by
+ * ident. The quirk data is shared but it's up to the drivers to act on the
+ * data.
+ *
+ * For now, only the OUI (first three bytes) is used, but this may be extended
+ * to device identification string and hardware/firmware revisions later.
+ */
+static u32
+drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, bool is_branch)
+{
+   const struct dpcd_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
+   quirk = _quirk_list[i];
+
+   if (quirk->is_branch != is_branch)
+   continue;
+
+   if (memcmp(quirk->oui, ident->oui, sizeof(ident->oui)) != 0)
+   continue;
+
+   quirks |= quirk->quirks;
+   }
+
+   return quirks;
+}
+
   /**
* drm_dp_read_desc - read sink/branch descriptor from DPCD
* @aux: DisplayPort AUX channel
@@ -1231,14 +1276,17 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct 
drm_dp_desc *desc,
if (ret < 0)
return ret;
   
+	desc->quirks = drm_dp_get_quirks(ident, is_branch);

+
dev_id_len = strnlen(ident->device_id, sizeof(ident->device_id));
   
-	DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d\n",

+   DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d quirks 
0x%04x\n",
  is_branch ? "branch" : "sink",
  (int)sizeof(ident->oui), ident->oui,
  dev_id_len, ident->device_id,
  ident->hw_rev >> 4, ident->hw_rev & 0xf,
- ident->sw_major_rev, ident->sw_minor_rev);
+ ident->sw_major_rev, ident->sw_minor_rev,
+ desc->quirks);
   
   	return 0;

   }
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index aee5b96b51d7..717cb8496725 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1090,12 +1090,44 @@ struct drm_dp_dpcd_ident {
   /**
* struct drm_dp_desc - DP branch/sink device descriptor
* @ident: DP device i

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-05-30 Thread Clint Taylor




On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst thing (a
simple dp port multiplexer is what I use for testing here, then plug in a
converter dongle or cable into that) then probably better to not wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on buying a
dp multiplexer to make sure there is nothing special I need to do for mst.

The CEC Tunneling is all in the branch device, so if I understand things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware issue
or something else. The BIOS is able to do some CEC, but whether they hook
into the MegaChip or have the CEC pin connected to a GPIO or something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. 
The release notes for the NUC state that there is a BIOS configuration 
option for enabling support. My doesn't have the option but the LSPCON 
fully supports CEC.


-Clint




BR,
Jani.


It would be so nice to get MegaChip CEC Tunneling working on the NUC, because
then you have native CEC support without requiring any Pulse Eight adapter.

And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
output as well.

Regards,

Hans


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

Re: [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

2017-05-18 Thread Clint Taylor




On 05/18/2017 04:10 AM, Jani Nikula wrote:

Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just otherwise require special treatment. Start a common
quirk database the drivers can query based on the DP device
identification. At least for now, we leave the workarounds for the
drivers to implement as they see fit.

For starters, add a branch device that can't handle full 24-bit main
link Mdiv and Ndiv main link attributes properly. Naturally, the
workaround of reducing main link attributes for all devices ended up in
regressions for other devices. So here we are.

v2: Rebase on DRM DP desc read helpers

v3: Fix the OUI memcmp blunder (Clint)


Tested-by: Clinton Taylor <clinton.a.tay...@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.tay...@intel.com>



Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
Cc: Clint Taylor <clinton.a.tay...@intel.com>
Cc: Adam Jackson <a...@redhat.com>
Cc: Harry Wentland <harry.wentl...@amd.com>
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
  drivers/gpu/drm/drm_dp_helper.c | 52 +++--
  include/drm/drm_dp_helper.h | 32 +
  2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 52e0ca9a5bb1..213fb837e1c4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1209,6 +1209,51 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
  }
  EXPORT_SYMBOL(drm_dp_stop_crc);
  
+struct dpcd_quirk {

+   u8 oui[3];
+   bool is_branch;
+   u32 quirks;
+};
+
+#define OUI(first, second, third) { (first), (second), (third) }
+
+static const struct dpcd_quirk dpcd_quirk_list[] = {
+   /* Analogix 7737 needs reduced M and N at HBR2 link rates */
+   { OUI(0x00, 0x22, 0xb9), true, BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
+};
+
+#undef OUI
+
+/*
+ * Get a bit mask of DPCD quirks for the sink/branch device identified by
+ * ident. The quirk data is shared but it's up to the drivers to act on the
+ * data.
+ *
+ * For now, only the OUI (first three bytes) is used, but this may be extended
+ * to device identification string and hardware/firmware revisions later.
+ */
+static u32
+drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, bool is_branch)
+{
+   const struct dpcd_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
+   quirk = _quirk_list[i];
+
+   if (quirk->is_branch != is_branch)
+   continue;
+
+   if (memcmp(quirk->oui, ident->oui, sizeof(ident->oui)) != 0)
+   continue;
+
+   quirks |= quirk->quirks;
+   }
+
+   return quirks;
+}
+
  /**
   * drm_dp_read_desc - read sink/branch descriptor from DPCD
   * @aux: DisplayPort AUX channel
@@ -1231,14 +1276,17 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct 
drm_dp_desc *desc,
if (ret < 0)
return ret;
  
+	desc->quirks = drm_dp_get_quirks(ident, is_branch);

+
dev_id_len = strnlen(ident->device_id, sizeof(ident->device_id));
  
-	DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d\n",

+   DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d quirks 
0x%04x\n",
  is_branch ? "branch" : "sink",
  (int)sizeof(ident->oui), ident->oui,
  dev_id_len, ident->device_id,
  ident->hw_rev >> 4, ident->hw_rev & 0xf,
- ident->sw_major_rev, ident->sw_minor_rev);
+ ident->sw_major_rev, ident->sw_minor_rev,
+ desc->quirks);
  
  	return 0;

  }
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index aee5b96b51d7..717cb8496725 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1090,12 +1090,44 @@ struct drm_dp_dpcd_ident {
  /**
   * struct drm_dp_desc - DP branch/sink device descriptor
   * @ident: DP device identification from DPCD 0x400 (sink) or 0x500 (branch).
+ * @quirks: Quirks; use drm_dp_has_quirk() to query for the quirks.
   */
  struct drm_dp_desc {
struct drm_dp_dpcd_ident ident;
+   u32 quirks;
  };
  
  int drm_dp_read_desc(struct drm_dp_aux *aux, struct drm_dp_desc *desc,

 bool is_branch);
  
+/**

+ * enum drm_dp_quirk - Display Port sink/branch device specific quirks
+ *
+ * Display Port sink and branch devices in the wild have a variety of bugs, try
+ * to collect them here. The quirks are shared, but it's up to the drivers to
+ * implement workarounds for them.
+ */
+enu

Re: [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

2017-05-17 Thread Clint Taylor




On 05/17/2017 07:25 AM, Jani Nikula wrote:

Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just otherwise require special treatment. Start a common
quirk database the drivers can query based on the DP device
identification. At least for now, we leave the workarounds for the
drivers to implement as they see fit.

For starters, add a branch device that can't handle full 24-bit main
link M and N attributes properly. Naturally, the workaround of reducing
main link attributes for all devices ended up in regressions for other
devices. So here we are.

v2: Rebase on DRM DP desc read helpers

Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
Cc: Clint Taylor <clinton.a.tay...@intel.com>
Cc: Adam Jackson <a...@redhat.com>
Cc: Harry Wentland <harry.wentl...@amd.com>
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
  drivers/gpu/drm/drm_dp_helper.c | 52 +++--
  include/drm/drm_dp_helper.h | 32 +
  2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 52e0ca9a5bb1..8c3797283c3b 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1209,6 +1209,51 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
  }
  EXPORT_SYMBOL(drm_dp_stop_crc);
  
+struct dpcd_quirk {

+   u8 oui[3];
+   bool is_branch;
+   u32 quirks;
+};
+
+#define OUI(first, second, third) { (first), (second), (third) }
+
+static const struct dpcd_quirk dpcd_quirk_list[] = {
+   /* Analogix 7737 needs reduced M and N at HBR2 link rates */
+   { OUI(0x00, 0x22, 0xb9), true, BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
+};
+
+#undef OUI
+
+/*
+ * Get a bit mask of DPCD quirks for the sink/branch device identified by
+ * ident. The quirk data is shared but it's up to the drivers to act on the
+ * data.
+ *
+ * For now, only the OUI (first three bytes) is used, but this may be extended
+ * to device identification string and hardware/firmware revisions later.
+ */
+static u32
+drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, bool is_branch)
+{
+   const struct dpcd_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
+   quirk = _quirk_list[i];
+
+   if (quirk->is_branch != is_branch)
+   continue;
+
+   if (memcmp(quirk->oui, ident->oui, sizeof(ident->oui) != 0))
+   continue;


Oops, All branch devices appear to have the quirk applied. The memcmp 
should be closed before the !=0


if (memcmp(quirk->oui, ident->oui, sizeof(ident->oui)) != 0)


[  659.496861] [drm:drm_dp_read_desc] DP branch: OUI 00-1c-f8 dev-ID 
175IB0 HW-rev 1.0 SW-rev 7.32 quirks 0x0001
[  659.549017] [drm:drm_dp_read_desc] DP branch: OUI 00-22-b9 dev-ID 
7737 HW-rev 10.12 SW-rev 6.4 quirks 0x0001
[  659.630449] [drm:drm_dp_read_desc] DP sink: OUI ee-ff-c0 dev-ID \001 
HW-rev 0.0 SW-rev 0.0 quirks 0x


This was actually good to find out that LSPCON didn't like the reduced M 
and N from the quirk at HBR2.


-Clint


+
+   quirks |= quirk->quirks;
+   }
+
+   return quirks;
+}
+
  /**
   * drm_dp_read_desc - read sink/branch descriptor from DPCD
   * @aux: DisplayPort AUX channel
@@ -1231,14 +1276,17 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct 
drm_dp_desc *desc,
if (ret < 0)
return ret;
  
+	desc->quirks = drm_dp_get_quirks(ident, is_branch);

+
dev_id_len = strnlen(ident->device_id, sizeof(ident->device_id));
  
-	DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d\n",

+   DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d quirks 
0x%04x\n",
  is_branch ? "branch" : "sink",
  (int)sizeof(ident->oui), ident->oui,
  dev_id_len, ident->device_id,
  ident->hw_rev >> 4, ident->hw_rev & 0xf,
- ident->sw_major_rev, ident->sw_minor_rev);
+ ident->sw_major_rev, ident->sw_minor_rev,
+ desc->quirks);
  
  	return 0;

  }
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index aee5b96b51d7..717cb8496725 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1090,12 +1090,44 @@ struct drm_dp_dpcd_ident {
  /**
   * struct drm_dp_desc - DP branch/sink device descriptor
   * @ident: DP device identification from DPCD 0x400 (sink) or 0x500 (branch).
+ * @quirks: Quirks; use drm_dp_has_quirk() to query for the quirks.
   */
  struct drm_dp_desc {
struct drm_dp_

Re: [PATCH 2/2] drm/i915: Detect USB-C specific dongles before reducing M and N

2017-05-11 Thread Clint Taylor




On 05/11/2017 02:57 AM, Jani Nikula wrote:

From: Clint Taylor <clinton.a.tay...@intel.com>

The Analogix 7737 DP to HDMI converter requires reduced M and N values
when to operate correctly at HBR2. Detect this IC by its OUI value of
0x0022B9 via the DPCD quirk list.

v2 by Jani: Rebased on the DP quirk database

Fixes: 9a86cda07af2 ("drm/i915/dp: reduce link M/N parameters")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100755
Cc: Jani Nikula <jani.nik...@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>


Tested-by: Clinton Taylor <clinton.a.tay...@intel.com>


Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com>
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
  drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
  drivers/gpu/drm/i915/intel_display.c | 22 ++
  drivers/gpu/drm/i915/intel_dp.c  | 15 +++
  drivers/gpu/drm/i915/intel_dp_mst.c  |  4 +++-
  drivers/gpu/drm/i915/intel_drv.h |  2 ++
  5 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff3574a56812..d34412673d61 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -563,7 +563,8 @@ struct intel_link_m_n {
  
  void intel_link_compute_m_n(int bpp, int nlanes,

int pixel_clock, int link_clock,
-   struct intel_link_m_n *m_n);
+   struct intel_link_m_n *m_n,
+   bool reduce_m_n);
  
  /* Interface history:

   *
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bf9020da8b80..46ac46ca976c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6116,7 +6116,7 @@ static int ironlake_fdi_compute_config(struct intel_crtc 
*intel_crtc,
pipe_config->fdi_lanes = lane;
  
  	intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,

-  link_bw, _config->fdi_m_n);
+  link_bw, _config->fdi_m_n, false);
  
  	ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);

if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
@@ -6292,7 +6292,8 @@ intel_reduce_m_n_ratio(uint32_t *num, uint32_t *den)
  }
  
  static void compute_m_n(unsigned int m, unsigned int n,

-   uint32_t *ret_m, uint32_t *ret_n)
+   uint32_t *ret_m, uint32_t *ret_n,
+   bool reduce_m_n)
  {
/*
 * Reduce M/N as much as possible without loss in precision. Several DP
@@ -6300,9 +6301,11 @@ static void compute_m_n(unsigned int m, unsigned int n,
 * values. The passed in values are more likely to have the least
 * significant bits zero than M after rounding below, so do this first.
 */
-   while ((m & 1) == 0 && (n & 1) == 0) {
-   m >>= 1;
-   n >>= 1;
+   if (reduce_m_n) {
+   while ((m & 1) == 0 && (n & 1) == 0) {
+   m >>= 1;
+   n >>= 1;
+   }
}
  
  	*ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);

@@ -6313,16 +6316,19 @@ static void compute_m_n(unsigned int m, unsigned int n,
  void
  intel_link_compute_m_n(int bits_per_pixel, int nlanes,
   int pixel_clock, int link_clock,
-  struct intel_link_m_n *m_n)
+  struct intel_link_m_n *m_n,
+  bool reduce_m_n)
  {
m_n->tu = 64;
  
  	compute_m_n(bits_per_pixel * pixel_clock,

link_clock * nlanes * 8,
-   _n->gmch_m, _n->gmch_n);
+   _n->gmch_m, _n->gmch_n,
+   reduce_m_n);
  
  	compute_m_n(pixel_clock, link_clock,

-   _n->link_m, _n->link_n);
+   _n->link_m, _n->link_n,
+   reduce_m_n);
  }
  
  static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4a6feb6a69bd..59f3dbb242a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1568,13 +1568,17 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp)
if (!__intel_dp_read_desc(intel_dp, desc))
return false;
  
+	intel_dp->quirks = drm_dp_get_quirks(desc->oui, sizeof(desc->oui),

+drm_dp_is_branch(intel_dp->dpcd));
+
dev_id_len = strnlen(desc->device_id, sizeof(desc->device_id));
-   DRM_DEBUG_KMS("DP %s: OUI %

Re: [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

2017-05-11 Thread Clint Taylor




On 05/11/2017 02:57 AM, Jani Nikula wrote:

Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just otherwise require special treatment. Start a common
quirk database the drivers can query based on OUI (with the option of
expanding to device identification string and hardware/firmware
revisions later). At least for now, we leave the workarounds for the
drivers to implement as they see fit.

For starters, add a branch device that can't handle full 24-bit main
link M and N attributes properly. Naturally, the workaround of reducing
main link attributes for all devices ended up in regressions for other
devices. So here we are.

Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
Cc: Clint Taylor <clinton.a.tay...@intel.com>
Cc: Adam Jackson <a...@redhat.com>
Cc: Harry Wentland <harry.wentl...@amd.com>


Tested-by: Clinton Taylor <clinton.a.tay...@intel.com>

Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
  drivers/gpu/drm/drm_dp_helper.c | 61 +
  include/drm/drm_dp_helper.h |  7 +
  2 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e5f52110ea1..58b2ced33151 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1208,3 +1208,64 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
return 0;
  }
  EXPORT_SYMBOL(drm_dp_stop_crc);
+
+/*
+ * Display Port sink and branch devices in the wild have a variety of bugs, try
+ * to collect them here. The quirks are shared, but it's up to the drivers to
+ * implement workarounds for them.
+ */
+
+/*
+ * FIXME: Add support for device identification and hardware/firmware revision.
+ */
+struct dpcd_quirk {
+   u8 oui[3];
+   bool is_branch;
+   u32 quirks;
+};
+
+#define OUI(first, second, third) { (first), (second), (third) }
+
+static const struct dpcd_quirk dpcd_quirk_list[] = {
+   /* Analogix 7737 needs reduced M and N at HBR2 link rates */
+   { OUI(0x00, 0x22, 0xb9), true, DP_DPCD_QUIRK_LIMITED_M_N },
+};
+
+#undef OUI
+
+/**
+ * drm_dp_get_quirks() - get quirks for the sink/branch device
+ * @oui: pointer to len bytes of DPCD at 0x400 (sink) or 0x500 (branch)
+ * @len: 3-12 bytes of DPCD data
+ * @is_branch: true for branch devices, false for sink devices
+ *
+ * Get a bit mask of DPCD quirks for the sink/branch device. The quirk data is
+ * shared but it's up to the drivers to act on the data.
+ *
+ * For now, only the OUI (first three bytes) is used, but this may be extended
+ * to device identification string and hardware/firmware revisions later.
+ */
+u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch)
+{
+   const struct dpcd_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   if (WARN_ON_ONCE(len < 3))
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
+   quirk = _quirk_list[i];
+
+   if (quirk->is_branch != is_branch)
+   continue;
+
+   if (memcmp(quirk->oui, oui, 3) != 0)
+   continue;
+
+   quirks |= quirk->quirks;
+   }
+
+   return quirks;
+}
+EXPORT_SYMBOL(drm_dp_get_quirks);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f7007e544f29..8abe9897fe59 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1079,4 +1079,11 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
  int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
  int drm_dp_stop_crc(struct drm_dp_aux *aux);
  
+/* Display Port sink and branch device quirks. */

+
+/* The sink is limited to small link M and N values. */
+#define DP_DPCD_QUIRK_LIMITED_M_N  BIT(0)
+
+u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch);
+
  #endif /* _DRM_DP_HELPER_H_ */


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

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

2017-03-27 Thread Clint Taylor


On 03/26/2017 09:05 PM, Ayaka wrote:



從我的 iPad 傳送


Ander Conselvan De Oliveira <conselv...@gmail.com> 於 2017年3月14日 下午9:53 寫道：


On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:

從我的 iPad 傳送


Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月7日 上午2:34 寫道：

On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:


從我的 iPad 傳送


Ville Syrjälä <ville.syrj...@linux.intel.com> 於 2017年3月6日 下午9:06 寫道：

On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format.

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.


What? Why? You just undid what Clint did in v6.


He missed a file also keeping the wrong description of rockchip.


I don't follow. Who missed what exactly?


What he sent is v5, I increase the order number twice in the message, it 
confuse me as well.
I think Clint forgot the include/uapi/drm/drm_fourcc.h .


Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":

https://patchwork.freedesktop.org/patch/141342/

Oh, yes but he still used Cr:Cb, but I think it should be Cb:Cr
since I think the V is after the U.


From the MSDN fourcc website:
"If the combined U-V array is addressed as an array of DWORDs, the least 
significant word (LSW) contains the U value and the most significant 
word (MSW) contains the V value. The stride of the combined U-V plane is 
equal to the stride of the Y plane. The U-V plane has half as many lines 
as the Y plane."


The LSW contains U and the MSW contains V, hence the Cr:Cb in the 
comments of the V6 patch.


-Clint




Ander








Cc: Daniel Stone <dan...@fooishbar.org>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>

Signed-off-by: Randy Li <ay...@soulik.info>
Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com>
---
drivers/gpu/drm/drm_fourcc.c  |  3 +++
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
 { .format = DRM_FORMAT_UYVY,.depth = 0,  .num_planes = 1, .cpp = { 
2, 0, 0 }, .hsub = 2, .vsub = 1 },
 { .format = DRM_FORMAT_VYUY,.depth = 0,  .num_planes = 1, .cpp = { 
2, 0, 0 }, .hsub = 2, .vsub = 1 },
 { .format = DRM_FORMAT_AYUV,.depth = 0,  .num_planes = 1, .cpp = { 
4, 0, 0 }, .hsub = 1, .vsub = 1 },
+{ .format = DRM_FORMAT_P010,.depth = 0,  .num_planes = 2, .cpp 
= { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+{ .format = DRM_FORMAT_P012,.depth = 0,  .num_planes = 2, .cpp 
= { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+{ .format = DRM_FORMAT_P016,.depth = 0,  .num_planes = 2, .cpp 
= { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
 };

 unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@ extern "C" {
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */

/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4


--
Ville Syrjälä
Intel OTC


--
Ville Syrjälä
Intel OTC


___
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 v5 1/2] drm_fourcc: Add new P010, P016 video format

2017-02-28 Thread Clint Taylor


On 02/28/2017 02:58 AM, ayaka wrote:



On 02/28/2017 06:57 AM, clinton.a.tay...@intel.com wrote:

From: Clint Taylor <clinton.a.tay...@intel.com>

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.

P016 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format

Cc: Daniel Stone <dan...@fooishbar.org>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>

Signed-off-by: Randy Li <ay...@soulik.info>
Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com>
---
  drivers/gpu/drm/drm_fourcc.c  |4 
  include/uapi/drm/drm_fourcc.h |   21 +
  2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..5494764 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,10 @@ const struct drm_format_info
*__drm_format_info(u32 format)
  { .format = DRM_FORMAT_UYVY,.depth = 0,  .num_planes
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
  { .format = DRM_FORMAT_VYUY,.depth = 0,  .num_planes
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
  { .format = DRM_FORMAT_AYUV,.depth = 0,  .num_planes
= 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+/* FIXME a pixel in Y for P010 is 10 bits */

  You may remove this line, I misunderstand the P010 that time.


That will look better. Thanks.


What I want is adding a new pixel format never be defined before, may it
should be called P010_PACK


We could probably add the PACK variants as DRM_FORMAT_P010V


or something else.

+{ .format = DRM_FORMAT_P010,.depth = 0,  .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+{ .format = DRM_FORMAT_P012,.depth = 0,  .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+{ .format = DRM_FORMAT_P016,.depth = 0,  .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
  };
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h
b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@
  #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
   * 3 plane YCbCr
   * index 0: Y plane, [7:0] Y
   * index 1: Cb plane, [7:0] Cb




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

Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format

2017-02-28 Thread Clint Taylor


On 02/28/2017 03:56 AM, Ville Syrjälä wrote:

On Mon, Feb 27, 2017 at 02:57:58PM -0800, clinton.a.tay...@intel.com wrote:

From: Clint Taylor <clinton.a.tay...@intel.com>

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.

P016 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format

Cc: Daniel Stone <dan...@fooishbar.org>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>

Signed-off-by: Randy Li <ay...@soulik.info>
Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com>
---
 drivers/gpu/drm/drm_fourcc.c  |4 
 include/uapi/drm/drm_fourcc.h |   21 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..5494764 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   /* FIXME a pixel in Y for P010 is 10 bits */
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P012,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};

unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */

 /*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */


Your Cb and Cr look swapped (unless my memory is playing tricks on me).


This is the information I have:
 Y UV
YUV 4:2:0  8 bpc - NV12  7:0  15:8  7:0
YUV 4:2:0 10 bpc - P010 15:6  31:22 15:6
YUV 4:2:0 12 bpc - P012 15:4  31:20 15:4
YUV 4:2:0 16 bpc - P016 15:0  31:16 15:0

-clint




+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
  * index 1: Cb plane, [7:0] Cb
--
1.7.9.5




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

Re: [PATCH v4 1/2] drm_fourcc: Add new P010, P016 video format

2017-02-27 Thread Clint Taylor


On 02/27/2017 09:41 AM, Ville Syrjälä wrote:

On Mon, Feb 27, 2017 at 09:21:09AM -0800, clinton.a.tay...@intel.com wrote:

From: Clint Taylor <clinton.a.tay...@intel.com>

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.

P016 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review

Cc: Daniel Stone <dan...@fooishbar.org>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>

Signed-off-by: Randy Li <ay...@soulik.info>
Signed-off-by: Clint Taylor <clinton.a.tay...@intel.com>
---
 drivers/gpu/drm/drm_fourcc.c  |4 
 include/uapi/drm/drm_fourcc.h |   18 ++
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..5494764 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   /* FIXME a pixel in Y for P010 is 10 bits */
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P012,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};


What's this hunk doing here?


This hunk defines the memory layout definition to DRM, so framebuffers 
can be checked to make sure they are large enough for the format. Can 
you describe your concern here?






unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..ad94464 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,24 @@
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */

 /*
+ * 2 plane YCbCr MSB aligned P0?? formats
+ * index 0 = Y plane, word array [15:6] P010
+ * or
+ * index 0 = Y plane, word array [15:4] P012
+ * or
+ * index 0 = Y plane, word array [15:0] P016
+ *
+ * index 1 = Cb:Cr plane, [31:22] Cb [15:6] Cr little endian P010
+ * or
+ * index 1 = Cb:Cr plane, [31:20] Cb [15:4] Cr little endian P012
+ * or
+ * index 1 = Cb:Cr plane, [31:16] Cb [15:0] Cr little endian P016
+ */


Still looks somewhat out of place when compared with the rest of the file.


The other YUV entries in the file all have 8 bit definitions and are 
easily grouped together. The P0?? formats change their number of bits. 
The only way I see is to make the comments look like the other YUV 
formats is to make each format have its own comment block describing the 
layout. I feel it's better to group them together since the difference 
between them (bpc) is minor.


perhaps moving the bit definitions to the defines, but then again it 
won't look like the other YUV format. It will look more like the RGB 
defines.


-Clint




+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cb:Cr plane 10 bits per channel */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cb:Cr plane 12 bits per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
  * index 1: Cb plane, [7:0] Cb
--
1.7.9.5




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

Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

2017-01-23 Thread Clint Taylor


On 01/04/2017 06:00 PM, Ayaka wrote:



從我的 iPad 傳送


Daniel Stone  於 2017年1月5日 上午1:02 寫道：

Hi Randy,


On 4 January 2017 at 16:29, Randy Li  wrote:
index 90d2cc8..23c8e99 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
   { .format = DRM_FORMAT_UYVY,.depth = 0,  .num_planes 
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
   { .format = DRM_FORMAT_VYUY,.depth = 0,  .num_planes 
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
   { .format = DRM_FORMAT_AYUV,.depth = 0,  .num_planes 
= 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   /* FIXME a pixel in Y for P010 is 10 bits */
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },


It seems like P010 stores each Y component in a 16-bit value, with the
bottom 6 bits ignored. So I think cpp here should be 2.

No, the rest bits are used to store the next pixel. The P010 is just a 10 bits 
color depth pixel format.


The reviewer is correct. In P010 and P016 the memory layout is identical 
as the luma and each Chroma channel are stored as words. .cpp = { 2, 4, 
0 } for both P010 and P016.


-Clint



Cheers,
Daniel


___
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

[PATCH] drm/edid: Reduce horizontal timings for pixel replicated modes

2014-08-25 Thread Clint Taylor

On 08/25/2014 06:02 AM, Daniel Vetter wrote:
> On Mon, Aug 18, 2014 at 02:02:14PM -0700, clinton.a.taylor at intel.com wrote:
>> From: Clint Taylor 
>>
>> Pixel replicated modes should be 720 horizontal pixel and pixel
>> replicated by the HW across the HDMI cable at 2X pixel clock. Current
>> horizontal resolution of 1440 does not allow pixel duplication to
>> occur and scaling artifacts occur on the TV. HDMI certification
>> 7-26 currently fails for all pixel replicated modes. This change fizes
>> the HDMI certification issues with 480i/576i.
>>
>> V2: Removed interlace flag from VICs 44 and 45. Will be submitted in
>> another patch. Various other formatting fixes.
>>
>> Signed-off-by: Clint Taylor 
>> ---
>>   drivers/gpu/drm/drm_edid.c|   96 
>> ++---
>>   drivers/gpu/drm/i915/intel_hdmi.c |   10 +++-
>
> I think the i915 side of this double-clock support should be split out
> into a separate patch. Makes it easier for people to spot that there's
> some driver work to enable this properly.
> -Daniel
>

Two patches will work. The HDMI driver will just reject the SD 
interlaced modes without the i915 changes.

Clint

[Intel-gfx] [PATCH] drm: HDMI pixel replication modes now hactive of 720 for pixel replication

2014-08-18 Thread Clint Taylor

On 08/12/2014 04:07 AM, Ville Syrj?l? wrote:
> On Tue, Jul 29, 2014 at 02:58:23PM -0700, clinton.a.taylor at intel.com wrote:
>> From: Clint Taylor 
>>
>> CEA SD interlaced modes use a horizontal 720 pixels that are pixel 
>> replicated to 1440. The current driver reports 1440 pixel to the OS and does 
>> not set pixel replicated modes.
>>
>> Signed-off-by: Clint Taylor 
>> ---
>>   drivers/gpu/drm/drm_edid.c|   68 
>> ++---
>>   drivers/gpu/drm/i915/intel_hdmi.c |   13 +++
>>   2 files changed, 47 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index dfa9769..5233f4c 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -632,26 +632,26 @@ static const struct drm_display_mode edid_cea_modes[] 
>> = {
>> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>  DRM_MODE_FLAG_INTERLACE),
>>.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
>> -/* 6 - 1440x480i at 60Hz */
>> -{ DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
>> +/* 6 - 720(1440)x480i at 60Hz */
>> +{ DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
>
> I think the best thing here might be to halve all the horizontal
> timings (and the clock), and maybe do it with an explicit /2 to
> remind people that this is a bit special, and also the spec lists
> the doubled timings, so it's maybe a bit easier to compare with the
> spec that way.
>
> So perhaps something like this:
> DRM_MODE(..., 27000/2, 1440/2, 1478/2, ...
>
> 
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 2422413..f8cdf7f 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -918,6 +918,19 @@ bool intel_hdmi_compute_config(struct intel_encoder 
>> *encoder,
>>  intel_hdmi->color_range = 0;
>>  }
>>
>> +/* Adjust pipe timings for pixel doubled modes */
>> +if ((adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)) {
>> +adjusted_mode->hsync_start /= 2;
>> +adjusted_mode->hsync_end /= 2;
>> +adjusted_mode->htotal /= 2;
>> +
>> +drm_mode_set_crtcinfo(adjusted_mode, 0);
>> +
>> +/* Set 2x pixel double on pipe */
>> +pipe_config->pixel_multiplier = 2;
>> +pipe_config->port_clock = adjusted_mode->crtc_clock;
>> +}
>
> If you halve the timings already in drm_edid.c all of this would be
> reduced to just:
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
>   pipe_config->pixel_multiplier = 2;
>
>
>> +
>>  if (intel_hdmi->color_range)
>>  pipe_config->limited_color_range = true;
>>
>> --
>> 1.7.9.5
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

Sorry, I missed this comment completely before I submitted the second 
patch to dri-devel. I will be making changes to the second patch only 
based on the feedback so far.

Thanks,
Clint

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2

Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/dg2: Add Wa_16013000631

Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/dg2: Add Wa_16011777198

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/dg2: Add Wa_14010547955

Re: [PATCH 3/3] drm/i915/dg2: Program recommended HW settings

Re: [PATCH 1/2] drm/i915/xehpsdv: Define MOCS table for XeHP SDV

Re: [PATCH v3 0/3] add LG panel to dpcd quirk database

Re: [PATCH] drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state

Re: [PATCH 2/4] intel: Add Cannonlake PCI IDs for Y-skus.

Re: [PATCH 1/4] intel: Add Cannonlake PCI IDs for U-skus.

Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

Re: [ANN] HDMI CEC Status Update

Re: [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

Re: [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

Re: [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

Re: [PATCH 2/2] drm/i915: Detect USB-C specific dongles before reducing M and N

Re: [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format

Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format

Re: [PATCH v4 1/2] drm_fourcc: Add new P010, P016 video format

Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

[PATCH] drm/edid: Reduce horizontal timings for pixel replicated modes

[Intel-gfx] [PATCH] drm: HDMI pixel replication modes now hactive of 720 for pixel replication

28 matches

Site Navigation

Mail list logo

Footer information