from:"Jindal, Sonika"

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid

2016-08-02 Thread Jindal, Sonika

Yes we had the issue of incorrect edid read.
But as of now you can go ahead with the revert.
I have moved to a different group, so I am not working on this anymore.

Regards,
Sonika

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Tuesday, August 2, 2016 8:02 PM
To: Daniel Vetter <dan...@ffwll.ch>; Jindal, Sonika <sonika.jin...@intel.com>; 
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading 
edid

On Tue, Jul 12, 2016 at 02:39:47PM +0300, David Weinehall wrote:
> I'm feeling sorely tempted to treat this as a proper regression, and 
> simply submit a revert patch, seeing as it slows down resume by 
> something like 200ms, but seeing as there was mention of a case where 
> incorrect EDID-information might end up being read after resume on 
> some Chromebooks, I'll just try to open a discussion instead.

Wrt https://bugs.freedesktop.org/show_bug.cgi?id=97139 this is a regression and 
I'll ack the revert. Yes, we need to resolve exactly how we get a stall between 
intel_hdmi_detect() and pageflip/cursor, but the onus is on the submitter of 
the patch to fix existing issues first to prevent such regressions (if 
possible, or else mitigate them).
-Chris

--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915/psr: Try to program link training times correctly

2016-05-19 Thread Jindal, Sonika




On 5/18/2016 10:17 PM, Daniel Vetter wrote:

Oops. Hw default for programming these fields to 0 is "skip link
training". Display won't take that too well usually.
But we were defaulting it to value 0, which means 500us for both TP1 and 
TP2 or TP3 time.
I dont think it means skip link training. This is just to set the time 
for the patterns.

Skip aux handshake can happen if bit 12 of SRD_CTL is set.

Does this solution help in fixing the bug mentioned here?



v2: Unbotch the math a bit.

v3: Drop debug hunk.

Tested-by: Lyude 
Cc: Lyude 
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176
Cc: Rodrigo Vivi 
Cc: Sonika Jindal 
Cc: Durgadoss R 
Cc: "Pandiyan, Dhinakaran" 
Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/i915/intel_psr.c | 55 ++--
  1 file changed, 47 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3abae4bc596..a788d1e9589b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -280,7 +280,10 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
 * with the 5 or 6 idle patterns.
 */
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
-   uint32_t val = 0x0;
+   uint32_t val = EDP_PSR_ENABLE;
+
+   val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
+   val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
  
  	if (IS_HASWELL(dev))

val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
@@ -288,14 +291,50 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
if (dev_priv->psr.link_standby)
val |= EDP_PSR_LINK_STANDBY;
  
-	I915_WRITE(EDP_PSR_CTL, val |

-  max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT |
-  idle_frames << EDP_PSR_IDLE_FRAME_SHIFT |
-  EDP_PSR_ENABLE);
+   if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
+   val |= EDP_PSR_TP1_TIME_2500us;
+   else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
+   val |= EDP_PSR_TP1_TIME_500us;
+   else if (dev_priv->vbt.psr.tp1_wakeup_time > 0)
+   val |= EDP_PSR_TP1_TIME_100us;
+   else
+   val |= EDP_PSR_TP1_TIME_0us;
+
+   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
+   val |= EDP_PSR_TP2_TP3_TIME_2500us;
+   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
+   val |= EDP_PSR_TP2_TP3_TIME_500us;
+   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 0)
+   val |= EDP_PSR_TP2_TP3_TIME_100us;
+   else
+   val |= EDP_PSR_TP2_TP3_TIME_0us;
+
+   if (intel_dp_source_supports_hbr2(intel_dp) &&
+   drm_dp_tps3_supported(intel_dp->dpcd))
+   val |= EDP_PSR_TP1_TP3_SEL;
+   else
+   val |= EDP_PSR_TP1_TP2_SEL;
+
+   I915_WRITE(EDP_PSR_CTL, val);
+
+   if (!dev_priv->psr.psr2_support)
+   return;
+
+   /* FIXME: selective update is probably totally broken because it doesn't
+* mesh at all with our frontbuffer tracking. And the hw alone isn't
+* good enough. */
+   val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+
+   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
+   val |= EDP_PSR2_TP2_TIME_2500;
+   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
+   val |= EDP_PSR2_TP2_TIME_500;
+   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 0)
+   val |= EDP_PSR2_TP2_TIME_100;
+   else
+   val |= EDP_PSR2_TP2_TIME_50;
  
-	if (dev_priv->psr.psr2_support)

-   I915_WRITE(EDP_PSR2_CTL, EDP_PSR2_ENABLE |
-   EDP_SU_TRACK_ENABLE | EDP_PSR2_TP2_TIME_100);
+   I915_WRITE(EDP_PSR2_CTL, val);
  }
  
  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Enable edp psr error interrupts on hsw

2016-05-19 Thread Jindal, Sonika




On 5/18/2016 11:56 PM, Ville Syrjälä wrote:

On Wed, May 18, 2016 at 06:47:10PM +0200, Daniel Vetter wrote:

The definitions for the error register should be valid on bdw/skl too,
but there we haven't even enabled DE_MISC handling yet.

Somewhat confusing the the moved register offset on bdw is only for
the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
on bdw.

v2: Fixes from Ville.

v3: Drop the REG_WRITE masking since edp interrupt still work and we
still enter PSR.

Cc: "Runyan, Arthur J" 
Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Cc: Sonika Jindal 
Cc: Durgadoss R 
Cc: "Pandiyan, Dhinakaran" 
Signed-off-by: Daniel Vetter 

I guess we might enable the error interrupt unconditionally, but the
entry/exit interrupts are going to cause constant dmesg spam, so those I
don't think we want enabled normally. Might be interesting to have some
kind of debug knob for those though.

Hmm. Actually is the PSR error interrupt tied to the "error interrupt"
bit in the PSR AUX register? We don't enable that bit, so maybe we can't
actually get the error interrupt?
Only bit 2 (SRD Aux Error) must be tied to the error interrupt bit of 
SRD_AUX register.

The entry and exit interrupts should be independent as per my understanding.
I agree the entry/exit messages will be too much in dmesg.

---
  drivers/gpu/drm/i915/i915_irq.c | 35 +++
  drivers/gpu/drm/i915/i915_reg.h | 10 ++
  2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f0d941455bed..579f582ef987 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2185,6 +2185,26 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
ironlake_rps_change_irq_handler(dev_priv);
  }
  
+static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)

+{
+   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
+
+   if (edp_psr_iir & EDP_PSR_ERROR)
+   DRM_DEBUG_KMS("PSR error\n");
+
+   if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
+   DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
+   I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
+   }
+
+   if (edp_psr_iir & EDP_PSR_POST_EXIT) {
+   DRM_DEBUG_KMS("PSR exit completed\n");
+   I915_WRITE(EDP_PSR_IMR, 0);
+   }
+
+   I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
+}
+
  static void ivb_display_irq_handler(struct drm_i915_private *dev_priv,
u32 de_iir)
  {
@@ -2197,6 +2217,9 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
if (de_iir & DE_ERR_INT_IVB)
ivb_err_int_handler(dev_priv);
  
+	if (de_iir & DE_EDP_PSR_INT_HSW)

+   hsw_edp_psr_irq_handler(dev_priv);
+
if (de_iir & DE_AUX_CHANNEL_A_IVB)
dp_aux_irq_handler(dev_priv);
  
@@ -3381,6 +3404,11 @@ static void ironlake_irq_reset(struct drm_device *dev)

if (IS_GEN7(dev))
I915_WRITE(GEN7_ERR_INT, 0x);
  
+	if (IS_HASWELL(dev)) {

+   I915_WRITE(EDP_PSR_IMR, 0x);
+   I915_WRITE(EDP_PSR_IIR, 0x);
+   }
+
gen5_gt_irq_reset(dev);
  
  	ibx_irq_reset(dev);

@@ -3676,6 +3704,7 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
DE_PCH_EVENT_IVB | DE_PLANEC_FLIP_DONE_IVB |
DE_PLANEB_FLIP_DONE_IVB |
DE_PLANEA_FLIP_DONE_IVB | DE_AUX_CHANNEL_A_IVB);
+

extra line.

extra_mask = (DE_PIPEC_VBLANK_IVB | DE_PIPEB_VBLANK_IVB |
  DE_PIPEA_VBLANK_IVB | DE_ERR_INT_IVB |
  DE_DP_A_HOTPLUG_IVB);
@@ -3690,6 +3719,12 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
  DE_DP_A_HOTPLUG);
}
  
+	if (IS_HASWELL(dev)) {

+   gen5_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
+   I915_WRITE(EDP_PSR_IMR, 0);
+   display_mask |= DE_EDP_PSR_INT_HSW;
+   }
+
dev_priv->irq_mask = ~display_mask;
  
  	I915_WRITE(HWSTAM, 0xeffe);

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 86fbf723eca7..0f99e67f2114 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3225,6 +3225,13 @@ enum skl_disp_power_wells {
  #define   EDP_PSR_TP1_TIME_0us(3<<4)
  #define   EDP_PSR_IDLE_FRAME_SHIFT0
  
+/* Bspec claims those aren't shifted but stay at 0x64800 */

+#define EDP_PSR_IMR_MMIO(0x64834)
+#define EDP_PSR_IIR_MMIO(0x64838)
+#define   EDP_PSR_ERROR

Re: [Intel-gfx] [PATCH] drm/i915/psr: Implement PSR2 w/a for gen9

2016-05-19 Thread Jindal, Sonika


Looks good to me.

Reviewed-by: Sonika Jindal



On 5/19/2016 12:44 PM, Daniel Vetter wrote:

Found this while browsing Bspec. Looks like it applies to both skl and
kbl.

v2: Also for bxt (Art).

Cc: Rodrigo Vivi 
Cc: Sonika Jindal 
Cc: Durgadoss R 
Cc: "Pandiyan, Dhinakaran" 
Cc: "Runyan, Arthur J" 
Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/i915/i915_reg.h |  1 +
  drivers/gpu/drm/i915/intel_pm.c | 17 +++--
  2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0f99e67f2114..c51368744e9e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6043,6 +6043,7 @@ enum skl_disp_power_wells {
  #define CHICKEN_PAR1_1_MMIO(0x42080)
  #define  DPA_MASK_VBLANK_SRD  (1 << 15)
  #define  FORCE_ARB_IDLE_PLANES(1 << 14)
+#define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
  
  #define _CHICKEN_PIPESL_1_A	0x420b0

  #define _CHICKEN_PIPESL_1_B   0x420b4
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e0d5405a8b15..8d42261daf1f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -58,6 +58,10 @@ static void bxt_init_clock_gating(struct drm_device *dev)
  {
struct drm_i915_private *dev_priv = dev->dev_private;
  
+	/* See Bspec note for PSR2_CTL bit 31, Wa#828:bxt */

+   I915_WRITE(CHICKEN_PAR1_1,
+  I915_READ(CHICKEN_PAR1_1) | SKL_EDP_PSR_FIX_RDWRAP);
+
/* WaDisableSDEUnitClockGating:bxt */
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
   GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
@@ -6845,6 +6849,15 @@ static void gen8_set_l3sqc_credits(struct 
drm_i915_private *dev_priv,
I915_WRITE(GEN7_MISCCPCTL, misccpctl);
  }
  
+static void skylake_init_clock_gating(struct drm_device *dev)

+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,kbl */
+   I915_WRITE(CHICKEN_PAR1_1,
+  I915_READ(CHICKEN_PAR1_1) | SKL_EDP_PSR_FIX_RDWRAP);
+}
+
  static void broadwell_init_clock_gating(struct drm_device *dev)
  {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -7307,9 +7320,9 @@ static void nop_init_clock_gating(struct drm_device *dev)
  void intel_init_clock_gating_hooks(struct drm_i915_private *dev_priv)
  {
if (IS_SKYLAKE(dev_priv))
-   dev_priv->display.init_clock_gating = nop_init_clock_gating;
+   dev_priv->display.init_clock_gating = skylake_init_clock_gating;
else if (IS_KABYLAKE(dev_priv))
-   dev_priv->display.init_clock_gating = nop_init_clock_gating;
+   dev_priv->display.init_clock_gating = skylake_init_clock_gating;
else if (IS_BROXTON(dev_priv))
dev_priv->display.init_clock_gating = bxt_init_clock_gating;
else if (IS_BROADWELL(dev_priv))


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check live status before reading edid

2016-03-08 Thread Jindal, Sonika

+Shashank

Shashank was planning to give a patch to bypass live status checks for older 
platforms.

Regards,
Sonika

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Wednesday, March 9, 2016 2:34 AM
To: Jindal, Sonika <sonika.jin...@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Check live status before reading edid

On Tue, Sep 15, 2015 at 09:44:20AM +0530, Sonika Jindal wrote:
> The Bspec is very clear that Live status must be checked about before 
> trying to read EDID over DDC channel. This patch makes sure that HDMI 
> EDID is read only when live status is up.
> 
> The live status doesn't seem to perform very consistent across various 
> platforms when tested with different monitors. The reason behind that 
> is some monitors are late to provide right voltage to set live_status up.
> So, after getting the interrupt, for a small duration, live status reg 
> fluctuates, and then settles down showing the correct staus.
> 
> This is explained here in, in a rough way:
> HPD line  
>|\ T1 = Monitor Hotplug causing IRQ
>| \__
>| |
>  | |
>| |   T2 = Live status is stable
>| |  _
>| | /|
> Live status _|_|/ |
>| |  |
>| |  |
>| |  |
>   T0 T1  T2
> 
> (Between T1 and T2 Live status fluctuates or can be even low, 
> depending on  the monitor)
> 
> After several experiments, we have concluded that a max delay of 30ms 
> is enough to allow the live status to settle down with most of the 
> monitors. This total delay of 30ms has been split into a resolution of 
> 3 retries of 10ms each, for the better cases.
> 
> This delay is kept at 30ms, keeping in consideration that, HDCP 
> compliance expect the HPD handler to respond a plug out in 100ms, by 
> disabling port.

This is a regression-fest. Revert with stable@?
-Chris

--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid

2016-02-25 Thread Jindal, Sonika




On 2/26/2016 12:11 AM, Joseph Salisbury wrote:

On 02/24/2016 10:53 PM, Jindal, Sonika wrote:

Hi Joe,

Yes, first thing to try is to increase the tries.

We testing with 300 retries, but the second monitor still did not show
up.  However, it did show up in lspci.



Can you please point me to the bug and provide more details like platform, 
monitor, cable.

The bug is at: http://pad.lv/1543683 .  All the hardware details should
be in the bug report.  The cable is a single link dvi-d cable.
Unfortunately the bug reporter does not have a dual link cable to test.
If you need any additional info, we can ask the bug reporter.

If this is with single link cable, the issue could be the same.
As Ville suggested for the other issue to use video=HDMI-A-1:e as 
command line argument, can you please give it a try?
The logs shared in the bug doesn't have drm logs enabled, so couldnt get 
much out of it.

Which platform is this?

Alternatively you can add something like following in intel_hdmi_detect 
to make it ignore the live status checks.


@@ -1419,7 +1419,7 @@ intel_hdmi_detect(struct drm_connector *connector, 
bool force)


intel_hdmi_unset_edid(connector);
-
+   live_status = live_status | force;
if (intel_hdmi_set_edid(connector, live_status)) {
struct intel_hdmi *intel_hdmi = 
intel_attached_hdmi(connector);



Regards,
Sonika

Are you referring to the same issue as Oleksandr reported where a single link 
dvi/hdmi cable didn’t work and dual link worked?

I'm not sure if this is the exact issue or not.  I'll review the other
thread and compare.


Regards,
Sonika

-Original Message-
From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com]
Sent: Thursday, February 25, 2016 3:09 AM
To: Jindal, Sonika <sonika.jin...@intel.com>
Cc: Sharma, Shashank <shashank.sha...@intel.com>; Vivi, Rodrigo <rodrigo.v...@intel.com>; Daniel Vetter 
<daniel.vet...@ffwll.ch>; Jani Nikula <jani.nik...@linux.intel.com>; David Airlie <airl...@linux.ie>; 
intel-gfx <intel-gfx@lists.freedesktop.org>; dri-devel <dri-de...@lists.freedesktop.org>; LKML 
<linux-ker...@vger.kernel.org>
Subject: [4.4-rc1][Regression] drm/i915: Check live status before reading edid

Hi Sonika,

A kernel bug report was opened against Ubuntu [0].  After a kernel bisect, it 
was found that reverting the following commit resolved this bug:

commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal <sonika.jin...@intel.com>
Date:   Tue Sep 15 09:44:20 2015 +0530

 drm/i915: Check live status before reading edid



The regression was introduced as of v4.4-rc1.

I was hoping to get your feedback, since you are the patch author.  Do think 
increasing the number of tries in intel_hdmi_detect() is worth trying?  Do you 
think gathering any additional data will help diagnose this issue, or would it 
be best to submit a revert request?
 


Thanks,
 
Joe


[0] http://pad.lv/lp1543683





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid

2016-02-24 Thread Jindal, Sonika

Hi Joe,

Yes, first thing to try is to increase the tries.
Can you please point me to the bug and provide more details like platform, 
monitor, cable.
Are you referring to the same issue as Oleksandr reported where a single link 
dvi/hdmi cable didn’t work and dual link worked?

Regards,
Sonika

-Original Message-
From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] 
Sent: Thursday, February 25, 2016 3:09 AM
To: Jindal, Sonika <sonika.jin...@intel.com>
Cc: Sharma, Shashank <shashank.sha...@intel.com>; Vivi, Rodrigo 
<rodrigo.v...@intel.com>; Daniel Vetter <daniel.vet...@ffwll.ch>; Jani Nikula 
<jani.nik...@linux.intel.com>; David Airlie <airl...@linux.ie>; intel-gfx 
<intel-gfx@lists.freedesktop.org>; dri-devel <dri-de...@lists.freedesktop.org>; 
LKML <linux-ker...@vger.kernel.org>
Subject: [4.4-rc1][Regression] drm/i915: Check live status before reading edid

Hi Sonika,

A kernel bug report was opened against Ubuntu [0].  After a kernel bisect, it 
was found that reverting the following commit resolved this bug:

commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal <sonika.jin...@intel.com>
Date:   Tue Sep 15 09:44:20 2015 +0530

drm/i915: Check live status before reading edid



The regression was introduced as of v4.4-rc1.

I was hoping to get your feedback, since you are the patch author.  Do think 
increasing the number of tries in intel_hdmi_detect() is worth trying?  Do you 
think gathering any additional data will help diagnose this issue, or would it 
be best to submit a revert request?


Thanks,

Joe

[0] http://pad.lv/lp1543683

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

2016-02-23 Thread Jindal, Sonika




On 2/23/2016 8:38 PM, Ville Syrjälä wrote:

On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:

Ville, Daniel,

any additional info I could provide? I have to return dual-link DVI
cable back, so let me know if I could reveal more details if necessary.

Unfortunately I'm out of ideas for now. Daniel is on vacation.
Anyone else? VPG folks should take the ball here since they broke it.

In the meantime I think as a workaround I think you could use
something like video=HDMI-A-1:e on the kernel command line (not sure
I got the connector name right for your system). I think that should
result in the live status check to be skipped, at least when
populating the mode list.

Might be a good idea to collect all the information here and put in a
bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that
all the logs and such would be in one place.


Regards,
Oleksandr

16.02.2016 14:54, Daniel Vetter написав:

On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:

Ville, Daniel,

I've just got another monitor and another DVI-HDMI cable, and here
what I've
got.

===Single Link DVI-D cable with 3 different monitors===

Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
===
not working

I presume the above LG screen is what you've called previously "old
monitor"?


Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P
===
not working
Do you have logs for the failure with the single link hdmi cable and the 
register dump which you have given for the working case?

If not, can you please capture the logs and register dump.
Also which platform is this?
If it is live status related issue, we need to see how long it is taking 
to set the live status, or is it not setting it at all with the 
single-link cable?




Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P
===
works!

===Dual Link DVI-D cable with monitor that doesn't work with Single
Link
cable===

Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
===
works!

Funky. Can you pls grab the debug logs (with the special patches from
Ville) for this case? I wonder why suddenly different cable and it
works.

Also: Is this one of these older-ish screens where you must have a
dual-link cable to drive it at full resolution rate?
-Daniel



===Laptop with HDMI output===

Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!

I'd say that single link DVI cables are broken with new kernel, but
one of
monitors could work with such a cable. So I have no idea :(.

Regards,
   Oleksandr.

15.02.2016 17:42, Daniel Vetter wrote:

The other downside is that it'll make us non-compliant, which was the
point of this entire ordeal: HDMI spec forbids us from starting any i2c
transactions when the hpd isn't signalling a present screen.

So maybe we need to buy one of these broken screens.

Oleksandr, what exact model are you using? And any chance that you could
test this on some other machine with intel gfx and latest kernel, just to
make sure this really is some issue with the sink and not with the machine
itself? And I guess you've tested with some other hdmi sink, and that
works?


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Call encoder hotplug for init and resume cases

2015-12-16 Thread Jindal, Sonika




On 12/16/2015 7:16 PM, Daniel Vetter wrote:

On Wed, Dec 16, 2015 at 04:18:05PM +0530, Sonika Jindal wrote:

Call the encoders, call the hot_plug if it is registered.
This is required for connected boot and resume cases to generate
fake hpd resulting in reading of edid.
Removing the initial sdvo hot_plug call too so that it will be called
just once from this loop.

v2: Schedule a work function to call hot_plug. On CHT, it runs into a
deadlock if we call ->hot_plug inside hpd_init. This is because, hot_plug
calls set_edid which tries to acquire the power domain and if power
well is disabled, we enable power well and call hpd_init again.
So, schedule a work function from here to call hot_plug and run a
detect cycle.

Cc: Shashank Sharma 
Signed-off-by: Sonika Jindal 
---

  drivers/gpu/drm/i915/i915_drv.h  |  1 +
  drivers/gpu/drm/i915/intel_hotplug.c | 26 ++
  drivers/gpu/drm/i915/intel_sdvo.c|  1 -
  3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bc865e23..4f037b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -228,6 +228,7 @@ enum hpd_pin {
  
  struct i915_hotplug {

struct work_struct hotplug_work;
+   struct work_struct edid_work;
  
  	struct {

unsigned long last_jiffies;
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index b177857..72d8fe8 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -442,6 +442,24 @@ void intel_hpd_irq_handler(struct drm_device *dev,
schedule_work(_priv->hotplug.hotplug_work);
  }
  
+static void i915_edid_work_func(struct work_struct *work)

+{
+   struct drm_i915_private *dev_priv =
+   container_of(work, struct drm_i915_private, hotplug.edid_work);
+   struct drm_device *dev = dev_priv->dev;
+   struct drm_mode_config *mode_config = >mode_config;
+   struct intel_encoder *encoder;
+
+   mutex_lock(_config->mutex);
+   list_for_each_entry(encoder, _config->encoder_list,
+   base.head) {
+   if (encoder->hot_plug)
+   encoder->hot_plug(encoder);
+   }
+   mutex_unlock(_config->mutex);
+   drm_helper_hpd_irq_event(dev);
+}

Why do we need a completely new hand-rolled work? My idea was to reuse the
existing hpd irq handler, but instead of just scheduling that (which won't
do anything) fake-inject a full set of hpd interrupts into it. Well, we
need to inject short-pulse ones to avoid upsetting dp mst.
-Daniel
Hmm, this suggestion came from Siva as well to just set the event_bits. 
Let me try that.


Thanks,
Sonika

+
  /**
   * intel_hpd_init - initializes and enables hpd support
   * @dev_priv: i915 device instance
@@ -482,12 +500,19 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
if (dev_priv->display.hpd_irq_setup)
dev_priv->display.hpd_irq_setup(dev);
spin_unlock_irq(_priv->irq_lock);
+
+   /*
+* Connected boot / resume scenarios can't generate new hot plug.
+* So, probe it manually.
+*/
+   schedule_work(_priv->hotplug.edid_work);
  }
  
  void intel_hpd_init_work(struct drm_i915_private *dev_priv)

  {
INIT_WORK(_priv->hotplug.hotplug_work, i915_hotplug_work_func);
INIT_WORK(_priv->hotplug.dig_port_work, i915_digport_work_func);
+   INIT_WORK(_priv->hotplug.edid_work, i915_edid_work_func);
INIT_DELAYED_WORK(_priv->hotplug.reenable_work,
  intel_hpd_irq_storm_reenable_work);
  }
@@ -504,5 +529,6 @@ void intel_hpd_cancel_work(struct drm_i915_private 
*dev_priv)
  
  	cancel_work_sync(_priv->hotplug.dig_port_work);

cancel_work_sync(_priv->hotplug.hotplug_work);
+   cancel_work_sync(_priv->hotplug.edid_work);
cancel_delayed_work_sync(_priv->hotplug.reenable_work);
  }
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 06679f1..4238a02 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2466,7 +2466,6 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, int 
device)
 * Ensure that they get re-enabled when an interrupt happens.
 */
intel_encoder->hot_plug = intel_sdvo_enable_hotplug;
-   intel_sdvo_enable_hotplug(intel_encoder);
} else {
intel_connector->polled = DRM_CONNECTOR_POLL_CONNECT | 
DRM_CONNECTOR_POLL_DISCONNECT;
}
--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/i915: mdelay(10) considered harmful

2015-12-14 Thread Jindal, Sonika


%s/cpy/cpu

Reviewed-by: Sonika Jindal 

On 12/12/2015 12:14 AM, Daniel Vetter wrote:

I missed this myself when reviewing

commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal 
Date:   Tue Sep 15 09:44:20 2015 +0530

 drm/i915: Check live status before reading edid

Long sleeps like this really shouldn't waste cpy cycles spinning.

Cc: Sonika Jindal 
Cc: "Wang, Gary C" 
Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index c3978bad5ca0..b0a5a883227c 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1397,7 +1397,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
while (!live_status && --retry) {
live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
-   mdelay(10);
+   msleep(10);
}
  
  	if (!live_status)


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add hot_plug hook for hdmi encoder

2015-12-10 Thread Jindal, Sonika

Sure, I will start a new thread for this.

Regarding the regression, since it is a sandybridge system, I am not sure if I 
can debug it anyhow because of the unavailability of the system.
For the live status check, we earlier suggested to use platforms gen8 and above.
But for wider testing, we removed the check.
If required we can add a check there.

Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Thursday, December 10, 2015 2:00 PM
To: Jindal, Sonika <sonika.jin...@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Add hot_plug hook for hdmi encoder

On Thu, Dec 10, 2015 at 10:15:41AM +0530, Sonika Jindal wrote:
> From: Shashank Sharma <shashank.sha...@intel.com>
> 
> This patch adds a separate probe function for HDMI EDID read over DDC 
> channel. This function has been registered as a .hot_plug handler for 
> HDMI encoder.
> 
> The current implementation of hdmi_detect() function re-sets the 
> cached HDMI edid (in connector->detect_edid) in every detect call.This 
> function gets called many times, sometimes directly from userspace 
> probes, forcing drivers to read EDID every detect function call.This 
> causes several problems like:
> 
> 1. Race conditions in multiple hot_plug / unplug cases, between
>interrupts bottom halves and userspace detections.
> 2. Many Un-necessary EDID reads for single hotplug/unplug 3. HDMI 
> complaince failures which expects only one EDID read per hotplug
> 
> This function will be serving the purpose of really reading the EDID 
> by really probing the DDC channel, and updating the cached EDID.
> 
> The plan is to:
> 1. i915 IRQ handler bottom half function already calls
>intel_encoder->hotplug() function. Adding This probe function which
>will read the EDID only in case of a hotplug / unplug.
> 2. During init_connector this probe will be called to read the edid 3. 
> Reuse the cached EDID in hdmi_detect() function.
> 
> The "< gen7" check is there because this was tested only for >=gen7 
> platforms. For older platforms the hotplug/reading edid path remains same.
> 
> v2: Calling set_edid instead of hdmi_probe during init.
> Also, for platforms having DDI, intel_encoder for DP and HDMI is same 
> (taken from intel_dig_port), so for DP also, hot_plug function gets 
> called which is not intended here. So, check for HDMI in 
> intel_hdmi_probe Rely on HPD for updating edid only for platforms gen > 8 and 
> also for VLV.
> 
> v3: Dropping the gen < 8 || !VLV  check. Now all platforms should rely 
> on hotplug or init for updating the edid.(Daniel) Also, calling 
> hdmi_probe in init instead of set_edid
> 
> v4: Renaming intel_hdmi_probe to intel_hdmi_hot_plug.
> Also calling this hotplug handler from intel_hpd_init to take care of 
> init resume scenarios.
> 
> v5: Moved the call to encoder hotplug during init to separate 
> patch(Daniel)
> v6: Rebased and maintaining authorship.
> 
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>

Iirc we had to revert an earlier version of this. Commit message should cite 
that revert and explain why this version is better.

Also after a few days please start a new thread when resubmitting a patch 
series. The idea behind in-reply-to is to keep the discussion together while 
it's still ongoing. That's not the case when the discussion has died down since 
weeks.

Also, your patch to take hpd sense into account for hdmi detection has causes a 
regression. Your on the cc. Handling that regression needs to be absolute top 
priority (otherwise I need to revert that patch too).

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 58 
> ++-
>  1 file changed, 45 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index bdd462e..16dd2a7 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1381,18 +1381,16 @@ intel_hdmi_set_edid(struct drm_connector *connector, 
> bool force)
>   return connected;
>  }
>  
> -static enum drm_connector_status
> -intel_hdmi_detect(struct drm_connector *connector, bool force)
> +void intel_hdmi_hot_plug(struct intel_encoder *intel_encoder)
>  {
> - enum drm_connector_status status;
> - struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> - struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi =
> + enc_to_intel_hdmi(_encoder->base);
> + struct intel_c

Re: [Intel-gfx] [PATCH] drm/i915: Add hot_plug hook for hdmi encoder

2015-12-10 Thread Jindal, Sonika

By "we" I meant me :)
Also, since it isn't possible to check all the platforms for live status, it is 
safer to put a gen check to platforms which we are sure.
Anyways, lets see if increasing the delay helps there, then you can take a call.

Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Thursday, December 10, 2015 2:24 PM
To: Jindal, Sonika <sonika.jin...@intel.com>
Cc: Daniel Vetter <dan...@ffwll.ch>; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Add hot_plug hook for hdmi encoder

On Thu, Dec 10, 2015 at 08:35:30AM +, Jindal, Sonika wrote:
> Sure, I will start a new thread for this.
> 
> Regarding the regression, since it is a sandybridge system, I am not 
> sure if I can debug it anyhow because of the unavailability of the 
> system.  For the live status check, we earlier suggested to use 
> platforms gen8 and above.
> But for wider testing, we removed the check.
> If required we can add a check there.

It's your patch, you need to own this. And until we've confirmed that it's a 
source issue I won't add a genAnything check but instead just revert the patch.

I hope expectations from my side here are clear.

Thanks, Daniel

> 
> Regards,
> Sonika
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
> Daniel Vetter
> Sent: Thursday, December 10, 2015 2:00 PM
> To: Jindal, Sonika <sonika.jin...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Add hot_plug hook for hdmi 
> encoder
> 
> On Thu, Dec 10, 2015 at 10:15:41AM +0530, Sonika Jindal wrote:
> > From: Shashank Sharma <shashank.sha...@intel.com>
> > 
> > This patch adds a separate probe function for HDMI EDID read over 
> > DDC channel. This function has been registered as a .hot_plug 
> > handler for HDMI encoder.
> > 
> > The current implementation of hdmi_detect() function re-sets the 
> > cached HDMI edid (in connector->detect_edid) in every detect 
> > call.This function gets called many times, sometimes directly from 
> > userspace probes, forcing drivers to read EDID every detect function 
> > call.This causes several problems like:
> > 
> > 1. Race conditions in multiple hot_plug / unplug cases, between
> >interrupts bottom halves and userspace detections.
> > 2. Many Un-necessary EDID reads for single hotplug/unplug 3. HDMI 
> > complaince failures which expects only one EDID read per hotplug
> > 
> > This function will be serving the purpose of really reading the EDID 
> > by really probing the DDC channel, and updating the cached EDID.
> > 
> > The plan is to:
> > 1. i915 IRQ handler bottom half function already calls
> >intel_encoder->hotplug() function. Adding This probe function which
> >will read the EDID only in case of a hotplug / unplug.
> > 2. During init_connector this probe will be called to read the edid 3. 
> > Reuse the cached EDID in hdmi_detect() function.
> > 
> > The "< gen7" check is there because this was tested only for >=gen7 
> > platforms. For older platforms the hotplug/reading edid path remains same.
> > 
> > v2: Calling set_edid instead of hdmi_probe during init.
> > Also, for platforms having DDI, intel_encoder for DP and HDMI is 
> > same (taken from intel_dig_port), so for DP also, hot_plug function 
> > gets called which is not intended here. So, check for HDMI in 
> > intel_hdmi_probe Rely on HPD for updating edid only for platforms gen > 8 
> > and also for VLV.
> > 
> > v3: Dropping the gen < 8 || !VLV  check. Now all platforms should 
> > rely on hotplug or init for updating the edid.(Daniel) Also, calling 
> > hdmi_probe in init instead of set_edid
> > 
> > v4: Renaming intel_hdmi_probe to intel_hdmi_hot_plug.
> > Also calling this hotplug handler from intel_hpd_init to take care 
> > of init resume scenarios.
> > 
> > v5: Moved the call to encoder hotplug during init to separate
> > patch(Daniel)
> > v6: Rebased and maintaining authorship.
> > 
> > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> > Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
> 
> Iirc we had to revert an earlier version of this. Commit message should cite 
> that revert and explain why this version is better.
> 
> Also after a few days please start a new thread when resubmitting a patch 
> series. The idea behind in-reply-to is to keep the discussion together while 
> it's still ongoing. That's not the case when the discussion ha

Re: [Intel-gfx] [PATCH] drm/i915: Correct max delay for HDMI hotplug live status checking

2015-12-10 Thread Jindal, Sonika

How about following instead of two levels of check in the while loop:

unsigned int retry = 3;

do {
live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
if (live_status)
break;
mdelay(10);
} while (--retry);

Regards,
Sonika

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Wang, Gary C
Sent: Friday, December 11, 2015 7:39 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: Correct max delay for HDMI hotplug live 
status checking

The total delay of HDMI hotplug detecting with 30ms should have been split into 
a resolution of 3 retries of 10ms each, for the worst cases. But it still 
suffered from only waiting 10ms at most in intel_hdmi_detect(). This patch 
corrects it by reading hotplug status with 4 times at most for 30ms delay.

Reviewed-by: Cooper Chiou 
Cc: Gavin Hindman 
Signed-off-by: Gary Wang 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)  mode change 100644 => 100755 
drivers/gpu/drm/i915/intel_hdmi.c

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
old mode 100644
new mode 100755
index be7fab9..888401b
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1387,16 +1387,19 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
bool live_status = false;
-   unsigned int retry = 3;
+   // read hotplug status 4 times at most for 30ms delay (3 retries of 
10ms each)
+   unsigned int retry = 4;
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
 
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
 
-   while (!live_status && --retry) {
+   while (!live_status && retry--) {
live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+   if (live_status || !retry)
+   break;
mdelay(10);
}
 
--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Correct max delay for HDMI hotplug live status checking

2015-12-10 Thread Jindal, Sonika

Sure.
Can you please also post your findings about different panels taking different 
time to settle the live status so that we know that this increase in retrials 
is helping you with multiple monitors?

Regards,
Sonika


-Original Message-
From: Wang, Gary C 
Sent: Friday, December 11, 2015 11:34 AM
To: Jindal, Sonika <sonika.jin...@intel.com>; intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH] drm/i915: Correct max delay for HDMI hotplug 
live status checking

Hi Sonika,

Thanks for your comment, and it's more readability on code.

But it only delay 2 integration of each 10ms among checking hot-plug with 3 
times. Could I change it to following snippet code to read hotplug_status 4 
times at most for 3 integration 10ms delay?

unsigned int retry = 3; 

do {
live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
if (live_status || !retry)
break;
mdelay(10);
} while (retry--);

Thanks!

Gary

-Original Message-
From: Jindal, Sonika 
Sent: Friday, December 11, 2015 1:05 PM
To: Wang, Gary C <gary.c.w...@intel.com>; intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH] drm/i915: Correct max delay for HDMI hotplug 
live status checking

How about following instead of two levels of check in the while loop:

unsigned int retry = 3;

do {
live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
if (live_status)
break;
mdelay(10);
} while (--retry);

Regards,
Sonika

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Wang, Gary C
Sent: Friday, December 11, 2015 7:39 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: Correct max delay for HDMI hotplug live 
status checking

The total delay of HDMI hotplug detecting with 30ms should have been split into 
a resolution of 3 retries of 10ms each, for the worst cases. But it still 
suffered from only waiting 10ms at most in intel_hdmi_detect(). This patch 
corrects it by reading hotplug status with 4 times at most for 30ms delay.

Reviewed-by: Cooper Chiou <cooper.ch...@intel.com>
Cc: Gavin Hindman <gavin.hind...@intel.com>
Signed-off-by: Gary Wang <gary.c.w...@intel.com>
---
 drivers/gpu/drm/i915/intel_hdmi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)  mode change 100644 => 100755 
drivers/gpu/drm/i915/intel_hdmi.c

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
old mode 100644
new mode 100755
index be7fab9..888401b
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1387,16 +1387,19 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
bool live_status = false;
-   unsigned int retry = 3;
+   // read hotplug status 4 times at most for 30ms delay (3 retries of 
10ms each)
+   unsigned int retry = 4;
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
 
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
 
-   while (!live_status && --retry) {
+   while (!live_status && retry--) {
live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+   if (live_status || !retry)
+   break;
mdelay(10);
}
 
--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Also disable PSR on Sink when disabling it on Source.

2015-11-23 Thread Jindal, Sonika

Reviewed-by: Sonika Jindal <sonika.jin...@intel.com>

-Original Message-
From: Vivi, Rodrigo 
Sent: Tuesday, November 24, 2015 3:50 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; Jindal, Sonika
Subject: [PATCH] drm/i915: Also disable PSR on Sink when disabling it on Source.

It is not a bad idea to disable the PSR feature on Sink when we are disabling 
on the Source.

v2: Move dpcd write inside mutex protected area as suggested by Sonika.

Cc: Sonika Jindal <sonika.jin...@intel.com>
Suggested-by: Sonika Jindal <sonika.jin...@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
---
 drivers/gpu/drm/i915/intel_psr.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2b2f84d..3bbb270 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -518,11 +518,15 @@ void intel_psr_disable(struct intel_dp *intel_dp)
return;
}
 
+   /* Disable PSR on Source */
if (HAS_DDI(dev))
hsw_psr_disable(intel_dp);
else
vlv_psr_disable(intel_dp);
 
+   /* Disable PSR on Sink */
+   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
+
dev_priv->psr.enabled = NULL;
mutex_unlock(_priv->psr.lock);
 
--
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for SKL+

2015-11-19 Thread Jindal, Sonika

Hmm, please help me understand more about it.
As per bspec this is a RW register.
Also, restoring the register values, isn't it part of the firmware's job?
Do we have any communication from HW team on this?

Regards,
Sonika

-Original Message-
From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com] 
Sent: Friday, November 20, 2015 12:01 AM
To: Jindal, Sonika
Cc: R, Durgadoss; Vivi, Rodrigo; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for SKL+

On Wed, Nov 18, 2015 at 11:45 PM, Jindal, Sonika <sonika.jin...@intel.com> 
wrote:
> Hi Rodrigo,
>
> Which platform have you observed this issue on?

Skylake and Kabylake

> This looks really strange.

It is expected actually.
On DC5/6 states all read-only registers are reset and cannot be restored. 
including this counter.

> Have you checked whether we are able to enter PSR at sink side or not in such 
> cases?
> Are we sure we are not entering PSR? I mean the PSR_STATE register says it 
> correctly?

I'm sure PSR is working well in entry state with links off and Perf counter 
goes to zero when DC5/6 states enters.
So this patch just removes the counter to avoid confusion. People would think 
PSR isn't work, when it is.

>
> Regards,
> Sonika
>
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On 
> Behalf Of R, Durgadoss
> Sent: Thursday, November 19, 2015 11:39 AM
> To: Vivi, Rodrigo; intel-gfx@lists.freedesktop.org
> Cc: Vivi, Rodrigo
> Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter 
> for SKL+
>
>
>
>>-Original Message-
>>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On 
>>Behalf Of Rodrigo Vivi
>>Sent: Thursday, November 19, 2015 6:10 AM
>>To: intel-gfx@lists.freedesktop.org
>>Cc: Vivi, Rodrigo
>>Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for
>>SKL+
>>
>>Whenever DMC firmware put the HW into DC State a bunch of registers 
>>including this perf counter is reset to 0 and never restored.
>>
>>So, even with PSR active and working we could still read
>>"Performance_Counter: 0" what will misslead people to believe PSR is 
>>broken.
>>
>>So, it is better to remove this counter information while we don't 
>>have a better way to track PSR residency.
>
> Agreed..
>
> Reviewed-by: Durgadoss R <durgados...@intel.com>
>
> Thanks,
> Durga
>
>>
>>Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
>>---
>> drivers/gpu/drm/i915/i915_debugfs.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>>b/drivers/gpu/drm/i915/i915_debugfs.c
>>index 038d5c6..71e1666 100644
>>--- a/drivers/gpu/drm/i915/i915_debugfs.c
>>+++ b/drivers/gpu/drm/i915/i915_debugfs.c
>>@@ -2580,8 +2580,11 @@ static int i915_edp_psr_status(struct seq_file *m, 
>>void *data)
>>   }
>>   seq_puts(m, "\n");
>>
>>-  /* CHV PSR has no kind of performance counter */
>>-  if (HAS_DDI(dev)) {
>>+  /*
>>+   * VLV/CHV PSR has no kind of performance counter
>>+   * SKL+ Perf counter is reset to 0 everytime DC state is entered
>>+   */
>>+  if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
>>   psrperf = I915_READ(EDP_PSR_PERF_CNT) &
>>   EDP_PSR_PERF_CNT_MASK;
>>
>>--
>>2.4.3
>>
>>___
>>Intel-gfx mailing list
>>Intel-gfx@lists.freedesktop.org
>>http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Also disable PSR on Sink when disabling it on Source.

2015-11-18 Thread Jindal, Sonika

Why not move it inside the mutex_lock/unlock on psr.lock ?

Regards,
Sonika

-Original Message-
From: Vivi, Rodrigo 
Sent: Thursday, November 19, 2015 6:10 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; Jindal, Sonika
Subject: [PATCH 3/3] drm/i915: Also disable PSR on Sink when disabling it on 
Source.

It is not a bad idea to disable the PSR feature on Sink when we are disabling 
on the Source.

Cc: Sonika Jindal <sonika.jin...@intel.com>
Suggested-by: Sonika Jindal <sonika.jin...@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
---
 drivers/gpu/drm/i915/intel_psr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 38ea4d0..de31162 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -527,6 +527,9 @@ void intel_psr_disable(struct intel_dp *intel_dp)
mutex_unlock(_priv->psr.lock);
 
cancel_delayed_work_sync(_priv->psr.work);
+
+   /* Disable PSR on Sink */
+   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
 }
 
 static void intel_psr_work(struct work_struct *work)
--
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for SKL+

2015-11-18 Thread Jindal, Sonika

Hi Rodrigo,

Which platform have you observed this issue on?
This looks really strange.
Have you checked whether we are able to enter PSR at sink side or not in such 
cases?
Are we sure we are not entering PSR? I mean the PSR_STATE register says it 
correctly?

Regards,
Sonika

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
R, Durgadoss
Sent: Thursday, November 19, 2015 11:39 AM
To: Vivi, Rodrigo; intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for SKL+



>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On 
>Behalf Of Rodrigo Vivi
>Sent: Thursday, November 19, 2015 6:10 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for 
>SKL+
>
>Whenever DMC firmware put the HW into DC State a bunch of registers 
>including this perf counter is reset to 0 and never restored.
>
>So, even with PSR active and working we could still read
>"Performance_Counter: 0" what will misslead people to believe PSR is 
>broken.
>
>So, it is better to remove this counter information while we don't have 
>a better way to track PSR residency.

Agreed..

Reviewed-by: Durgadoss R 

Thanks,
Durga

>
>Signed-off-by: Rodrigo Vivi 
>---
> drivers/gpu/drm/i915/i915_debugfs.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>b/drivers/gpu/drm/i915/i915_debugfs.c
>index 038d5c6..71e1666 100644
>--- a/drivers/gpu/drm/i915/i915_debugfs.c
>+++ b/drivers/gpu/drm/i915/i915_debugfs.c
>@@ -2580,8 +2580,11 @@ static int i915_edp_psr_status(struct seq_file *m, void 
>*data)
>   }
>   seq_puts(m, "\n");
>
>-  /* CHV PSR has no kind of performance counter */
>-  if (HAS_DDI(dev)) {
>+  /*
>+   * VLV/CHV PSR has no kind of performance counter
>+   * SKL+ Perf counter is reset to 0 everytime DC state is entered
>+   */
>+  if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
>   psrperf = I915_READ(EDP_PSR_PERF_CNT) &
>   EDP_PSR_PERF_CNT_MASK;
>
>--
>2.4.3
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: force link training when requested by Sink

2015-11-04 Thread Jindal, Sonika

Looks good to me.
Reviewed-by: Sonika Jindal 
Signed-off-by: Shubhangi Shrivastava 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index 7bc75ef..3c7fc58 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4466,7 +4466,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
 
-   if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
+   /* if link training is requested we should perform it always */
+   if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
+   (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
  intel_encoder->base.name);
intel_dp_start_link_train(intel_dp);
--
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Cleanup test data during long/short hotplug

2015-11-04 Thread Jindal, Sonika

Looks good to me.
Reviewed-by: Sonika Jindal 
Signed-off-by: Shubhangi Shrivastava 
---
 drivers/gpu/drm/i915/intel_dp.c | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index 18bcfbe..99b8d8c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4317,13 +4317,6 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
uint8_t rxdata = 0;
int status = 0;
 
-   intel_dp->compliance_test_active = 0;
-   intel_dp->compliance_test_type = 0;
-   intel_dp->compliance_test_data = 0;
-
-   intel_dp->aux.i2c_nack_count = 0;
-   intel_dp->aux.i2c_defer_count = 0;
-
status = drm_dp_dpcd_read(_dp->aux, DP_TEST_REQUEST, , 1);
if (status <= 0) {
DRM_DEBUG_KMS("Could not read test request from sink\n"); @@ 
-4439,6 +4432,14 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 
+   /*
+* Clearing compliance test variables to allow capturing
+* of values for next automated test request.
+*/
+   intel_dp->compliance_test_active = 0;
+   intel_dp->compliance_test_type = 0;
+   intel_dp->compliance_test_data = 0;
+
if (!intel_encoder->base.crtc)
return;
 
@@ -4817,8 +4818,13 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
status = ironlake_dp_detect(intel_dp);
else
status = g4x_dp_detect(intel_dp);
-   if (status != connector_status_connected)
+   if (status != connector_status_connected) {
+   intel_dp->compliance_test_active = 0;
+   intel_dp->compliance_test_type = 0;
+   intel_dp->compliance_test_data = 0;
+
goto out;
+   }
 
intel_dp_probe_oui(intel_dp);
 
@@ -4832,6 +4838,14 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
goto out;
}
 
+   /*
+* Clearing NACK and defer counts to get their exact values
+* while reading EDID which are required by Compliance tests
+* 4.2.2.4 and 4.2.2.5
+*/
+   intel_dp->aux.i2c_nack_count = 0;
+   intel_dp->aux.i2c_defer_count = 0;
+
intel_dp_set_edid(intel_dp);
 
if (intel_encoder->type != INTEL_OUTPUT_EDP)
--
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Cleanup test data during long/short hotplug

2015-10-27 Thread Jindal, Sonika

For the edid read test, if we are capturing i2c_nack_count and i2c_defer_count, 
it will be better if you move the resetting of these variable just before the 
edid read.
Also, please add some comment why we need to reset compliance_test_* at two 
places.

Regards,
Sonika

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Shubhangi Shrivastava
Sent: Wednesday, October 14, 2015 2:57 PM
To: intel-gfx@lists.freedesktop.org
Cc: Shrivastava, Shubhangi
Subject: [Intel-gfx] [PATCH 1/2] drm/i915: Cleanup test data during long/short 
hotplug

Automated test data that is updated when a test is requested is not cleared 
till next automated test request is recevied which can cause various problems. 
This patch fixes this by clearing this during the next short pulse and on hot 
unplug.

For example, when TEST_LINK_TRAINING is requested it is updated to appropriate 
variable inside intel_dp_handle_test_request but is also cleared only inside 
the same function. if the next short pulse does not have the 
AUTOMATED_TEST_REQUEST bits set the variable will not be cleared resulting in 
carrying incorrect test status in local variables.

Signed-off-by: Sivakumar Thulasimani 
Signed-off-by: Shubhangi Shrivastava 
---
 drivers/gpu/drm/i915/intel_dp.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index 18bcfbe..7bc75ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4317,13 +4317,6 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
uint8_t rxdata = 0;
int status = 0;
 
-   intel_dp->compliance_test_active = 0;
-   intel_dp->compliance_test_type = 0;
-   intel_dp->compliance_test_data = 0;
-
-   intel_dp->aux.i2c_nack_count = 0;
-   intel_dp->aux.i2c_defer_count = 0;
-
status = drm_dp_dpcd_read(_dp->aux, DP_TEST_REQUEST, , 1);
if (status <= 0) {
DRM_DEBUG_KMS("Could not read test request from sink\n"); @@ 
-4439,6 +4432,10 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 
+   intel_dp->compliance_test_active = 0;
+   intel_dp->compliance_test_type = 0;
+   intel_dp->compliance_test_data = 0;
+
if (!intel_encoder->base.crtc)
return;
 
@@ -4817,8 +4814,16 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
status = ironlake_dp_detect(intel_dp);
else
status = g4x_dp_detect(intel_dp);
-   if (status != connector_status_connected)
+   if (status != connector_status_connected) {
+   intel_dp->compliance_test_active = 0;
+   intel_dp->compliance_test_type = 0;
+   intel_dp->compliance_test_data = 0;
+
+   intel_dp->aux.i2c_nack_count = 0;
+   intel_dp->aux.i2c_defer_count = 0;
+
goto out;
+   }
 
intel_dp_probe_oui(intel_dp);
 
--
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Call encoder hotplug for init and resume cases

2015-10-14 Thread Jindal, Sonika

Had some discussion with Daniel on IRC about how we can fix the deadlock.
We couldn't decide upon any solution but I can give it a try.
He suggested to have a work function for ->hot_plug which will get the power 
domain lock and not allow ->hot_plug if the power_domain is shut.
Then when it calls hpt_init again from power_domain get, ->hot_plug gets called.
But this looks racy, we can try this out.
If there are any other suggestions, please let me know.
I will work on this after 26th Oct.

Regards,
Sonika

-Original Message-
From: Sharma, Shashank 
Sent: Monday, October 12, 2015 5:54 PM
To: Ville Syrjälä; Vetter, Daniel
Cc: intel-gfx@lists.freedesktop.org; Mukherjee, Indranil; Jindal, Sonika
Subject: RE: [Intel-gfx] [PATCH 1/2] drm/i915: Call encoder hotplug for init 
and resume cases

We were debugging this issue, and we could find the root cause:
In function:
Intel_hpd_init()
|
encoder->hotplug()
|
display_power_get()
|
Intel_powe_well_enable()
|
power_well->ops->enable()
|
chv_pipe_power_well_enable()
|
vlv_display_power_well_init()
|
intel_hdp_init()

This function ends up calling intel_hpd_init, Which is causing the mutex 
deadlock due to recursion, as we are calling encoder->hotplug() from hpd_init().

Intel_hpd_init()
|
encoder->hotplug()
|
display_power_get()

There are two solutions here:
- remove hpd_init() from get_calls
- remove encoder->hotplug() function call from hpd_init() and put it in some 
other place. We have added this function from encoder_init() for android trees, 
and it works well there. 

Regards
Shashank
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Ville Syrjälä
Sent: Thursday, October 08, 2015 7:06 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Call encoder hotplug for init 
and resume cases

On Mon, Oct 05, 2015 at 04:43:14PM +0530, Sonika Jindal wrote:
> For all the encoders, call the hot_plug if it is registered.
> This is required for connected boot and resume cases to generate fake 
> hpd resulting in reading of edid.
> Removing the initial sdvo hot_plug call too so that it will be called 
> just once from this loop.
> 
> Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_hotplug.c |   11 +++
>  drivers/gpu/drm/i915/intel_sdvo.c|1 -
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 53c0173..eac4757 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -458,6 +458,7 @@ void intel_hpd_init(struct drm_i915_private
> *dev_priv)  {
>   struct drm_device *dev = dev_priv->dev;
>   struct drm_mode_config *mode_config = >mode_config;
> + struct intel_encoder *encoder;
>   struct drm_connector *connector;
>   int i;
>  
> @@ -482,6 +483,16 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
>   if (dev_priv->display.hpd_irq_setup)
>   dev_priv->display.hpd_irq_setup(dev);
>   spin_unlock_irq(_priv->irq_lock);
> +
> + /*
> +  * Connected boot / resume scenarios can't generate new hot plug.
> +  * So, probe it manually.
> +  */
> + list_for_each_entry(encoder, >mode_config.encoder_list,
> + base.head) {
> + if (encoder->hot_plug)
> + encoder->hot_plug(encoder);
> + }


This breaks the world on CHV

[ 3187.575198] [drm:intel_hdmi_hot_plug] Live status not up!
[ 3187.585154] =
[ 3187.595010] [ INFO: possible recursive locking detected ]
[ 3187.604685] 4.3.0-rc4-bsw+ #2488 Tainted: G U  W  
[ 3187.614366] -
[ 3187.623892] Xorg/32212 is trying to acquire lock:
[ 3187.632635]  (_domains->lock){+.+...}, at: [] 
intel_display_power_get+0x38/0xcb [i915] [ 3187.647492] [ 3187.647492] but task 
is already holding lock:
[ 3187.661054]  (_domains->lock){+.+...}, at: [] 
intel_display_power_get+0x38/0xcb [i915] [ 3187.675960] [ 3187.675960] other 
info that might help us debug this:
[ 3187.690459]  Possible unsafe locking scenario:
[ 3187.690459] 
[ 3187.704224]CPU0
[ 3187.710485]
[ 3187.716711]   lock(_domains->lock);
[ 3187.724718]   lock(_domains->lock);
[ 3187.732663]
[ 3187.732663]  *** DEADLOCK ***
[ 3187.732663]
[ 3187.749460]  May be due to missing lock nesting notation [ 3187.749460] [ 
3187.763833] 5 locks held by Xorg/32212:
[ 3187.771523]  #0:  (drm_global_mutex){+.+.+.}, at: [] 
drm_release+0x3b/0x49b [drm] [ 3187.785216]  #1:  
(>mode_config.mutex){+.+.+.}

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Call encoder hotplug for init and resume cases

2015-10-08 Thread Jindal, Sonika




On 10/9/2015 1:24 AM, Daniel Vetter wrote:

On Thu, Oct 08, 2015 at 05:38:58PM +0300, Jani Nikula wrote:

On Thu, 08 Oct 2015, Ville Syrjälä  wrote:

On Mon, Oct 05, 2015 at 04:43:14PM +0530, Sonika Jindal wrote:

For all the encoders, call the hot_plug if it is registered.
This is required for connected boot and resume cases to generate
fake hpd resulting in reading of edid.
Removing the initial sdvo hot_plug call too so that it will be called
just once from this loop.

Signed-off-by: Sonika Jindal 
---
  drivers/gpu/drm/i915/intel_hotplug.c |   11 +++
  drivers/gpu/drm/i915/intel_sdvo.c|1 -
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 53c0173..eac4757 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -458,6 +458,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
  {
struct drm_device *dev = dev_priv->dev;
struct drm_mode_config *mode_config = >mode_config;
+   struct intel_encoder *encoder;
struct drm_connector *connector;
int i;

@@ -482,6 +483,16 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
if (dev_priv->display.hpd_irq_setup)
dev_priv->display.hpd_irq_setup(dev);
spin_unlock_irq(_priv->irq_lock);
+
+   /*
+* Connected boot / resume scenarios can't generate new hot plug.
+* So, probe it manually.
+*/
+   list_for_each_entry(encoder, >mode_config.encoder_list,
+   base.head) {
+   if (encoder->hot_plug)
+   encoder->hot_plug(encoder);
+   }



This breaks the world on CHV


Also patch 2/2 breaks: https://bugs.freedesktop.org/show_bug.cgi?id=88081



Hmm, will check why live status is not up for chv..

Regards,
Sonika

Both reverted, thanks for the reveport.
-Daniel



BR,
Jani.




[ 3187.575198] [drm:intel_hdmi_hot_plug] Live status not up!
[ 3187.585154] =
[ 3187.595010] [ INFO: possible recursive locking detected ]
[ 3187.604685] 4.3.0-rc4-bsw+ #2488 Tainted: G U  W
[ 3187.614366] -
[ 3187.623892] Xorg/32212 is trying to acquire lock:
[ 3187.632635]  (_domains->lock){+.+...}, at: [] 
intel_display_power_get+0x38/0xcb [i915]
[ 3187.647492]
[ 3187.647492] but task is already holding lock:
[ 3187.661054]  (_domains->lock){+.+...}, at: [] 
intel_display_power_get+0x38/0xcb [i915]
[ 3187.675960]
[ 3187.675960] other info that might help us debug this:
[ 3187.690459]  Possible unsafe locking scenario:
[ 3187.690459]
[ 3187.704224]CPU0
[ 3187.710485]
[ 3187.716711]   lock(_domains->lock);
[ 3187.724718]   lock(_domains->lock);
[ 3187.732663]
[ 3187.732663]  *** DEADLOCK ***
[ 3187.732663]
[ 3187.749460]  May be due to missing lock nesting notation
[ 3187.749460]
[ 3187.763833] 5 locks held by Xorg/32212:
[ 3187.771523]  #0:  (drm_global_mutex){+.+.+.}, at: [] 
drm_release+0x3b/0x49b [drm]
[ 3187.785216]  #1:  (>mode_config.mutex){+.+.+.}, at: 
[] drm_modeset_lock_all+0x54/0xcd [drm]
[ 3187.800437]  #2:  (crtc_ww_class_acquire){+.+.+.}, at: [] 
drm_modeset_lock_all+0x5e/0xcd [drm]
[ 3187.815488]  #3:  (crtc_ww_class_mutex){+.+.+.}, at: [] 
drm_modeset_lock+0x75/0xfc [drm]
[ 3187.830094]  #4:  (_domains->lock){+.+...}, at: [] 
intel_display_power_get+0x38/0xcb [i915]
[ 3187.845534]
[ 3187.845534] stack backtrace:
[ 3187.857685] CPU: 2 PID: 32212 Comm: Xorg Tainted: G U  W   
4.3.0-rc4-bsw+ #2488
[ 3187.870331] Hardware name: Intel Corporation CHERRYVIEW C0 PLATFORM/Braswell 
CRB, BIOS BRAS.X64.B085.R00.1509110553 09/11/2015
[ 3187.886827]   880175eff8e0 8128d59e 
823f5ee0
[ 3187.898904]  880175eff958 810a7a08  
880179d1c5d0
[ 3187.910954]  0004 0006 45422a91588a4c3e 
0005
[ 3187.923011] Call Trace:
[ 3187.929451]  [] dump_stack+0x4e/0x79
[ 3187.938912]  [] __lock_acquire+0x7ab/0x12af
[ 3187.949027]  [] lock_acquire+0x10e/0x1a9
[ 3187.958859]  [] ? intel_display_power_get+0x38/0xcb [i915]
[ 3187.970476]  [] ? intel_display_power_get+0x38/0xcb [i915]
[ 3187.982011]  [] mutex_lock_nested+0x71/0x346
[ 3187.992167]  [] ? intel_display_power_get+0x38/0xcb [i915]
[ 3188.003655]  [] ? _raw_spin_unlock_irqrestore+0x4b/0x60
[ 3188.014829]  [] ? __pm_runtime_resume+0x71/0x7e
[ 3188.025269]  [] intel_display_power_get+0x38/0xcb [i915]
[ 3188.036544]  [] ? intel_display_power_get+0x38/0xcb [i915]
[ 3188.047968]  [] intel_hdmi_set_edid+0x3f/0xd6 [i915]
[ 3188.058766]  [] intel_hdmi_hot_plug+0xbf/0xfb [i915]
[ 3188.069484]  [] intel_hpd_init+0xfa/0x10b [i915]
[ 3188.079753]  [] vlv_display_power_well_init+0xdb/0xe8 
[i915]
[ 3188.091224]  [] chv_pipe_power_well_enable+0x62/0x67 [i915]
[ 3188.102594]  []

Re: [Intel-gfx] [PATCH] drm/i915: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-07 Thread Jindal, Sonika




On 10/7/2015 3:31 PM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.

Signed-off-by: Tvrtko Ursulin 
Cc: Sonika Jindal 
---
  drivers/gpu/drm/i915/intel_display.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 539c3737e823..6328788193e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11126,9 +11126,10 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
  {
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_plane *plane = intel_crtc->base.primary;
struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
const enum pipe pipe = intel_crtc->pipe;
-   u32 ctl, stride;
+   u32 ctl, stride, tile_height;

ctl = I915_READ(PLANE_CTL(pipe, 0));
ctl &= ~PLANE_CTL_TILED_MASK;
@@ -11152,9 +11153,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
 * The stride is either expressed as a multiple of 64 bytes chunks for
 * linear buffers or in number of tiles for tiled buffers.
 */
-   stride = fb->pitches[0] /
-intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+   if (intel_rotation_90_or_270(plane->state->rotation)) {
+   /* stride = Surface height in tiles */
+   tile_height = intel_tile_height(dev, fb->pixel_format,
+   fb->modifier[0], 0);
+   stride = DIV_ROUND_UP(fb->height, tile_height);
Wouldn't we need a PLANE_SIZE update somewhere in case of 90/270? For 
the cases where the plane is not square and can fit after rotation as well?



+   } else {
+   stride = fb->pitches[0] /
+   intel_fb_stride_alignment(dev, fb->modifier[0],
+ fb->pixel_format);
+   }

/*
 * Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add hot_plug hook for hdmi encoder

2015-09-28 Thread Jindal, Sonika




On 9/28/2015 7:04 PM, Daniel Vetter wrote:

On Mon, Sep 28, 2015 at 02:26:04PM +0530, Sonika Jindal wrote:

This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.

The current implementation of hdmi_detect()
function re-sets the cached HDMI edid (in connector->detect_edid) in
every detect call.This function gets called many times, sometimes
directly from userspace probes, forcing drivers to read EDID every
detect function call.This causes several problems like:

1. Race conditions in multiple hot_plug / unplug cases, between
interrupts bottom halves and userspace detections.
2. Many Un-necessary EDID reads for single hotplug/unplug
3. HDMI complaince failures which expects only one EDID read per hotplug

This function will be serving the purpose of really reading the EDID
by really probing the DDC channel, and updating the cached EDID.

The plan is to:
1. i915 IRQ handler bottom half function already calls
intel_encoder->hotplug() function. Adding This probe function which
will read the EDID only in case of a hotplug / unplug.
2. During init_connector this probe will be called to read the edid
3. Reuse the cached EDID in hdmi_detect() function.

The "< gen7" check is there because this was tested only for >=gen7
platforms. For older platforms the hotplug/reading edid path remains same.

v2: Calling set_edid instead of hdmi_probe during init.
Also, for platforms having DDI, intel_encoder for DP and HDMI is same
(taken from intel_dig_port), so for DP also, hot_plug function gets called
which is not intended here. So, check for HDMI in intel_hdmi_probe
Rely on HPD for updating edid only for platforms gen > 8 and also for VLV.

v3: Dropping the gen < 8 || !VLV  check. Now all platforms should rely on
hotplug or init for updating the edid.(Daniel)
Also, calling hdmi_probe in init instead of set_edid

v4: Renaming intel_hdmi_probe to intel_hdmi_hot_plug and changing the patch
subject. Also calling this hotplug handler from intel_hpd_init to take care
of init resume scenarios.

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 
---
  drivers/gpu/drm/i915/intel_hdmi.c|   54 +++---
  drivers/gpu/drm/i915/intel_hotplug.c |   11 +++
  2 files changed, 54 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index bb33c66..9c1a308 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1369,18 +1369,16 @@ intel_hdmi_set_edid(struct drm_connector *connector, 
bool force)
return connected;
  }

-static enum drm_connector_status
-intel_hdmi_detect(struct drm_connector *connector, bool force)
+void intel_hdmi_hot_plug(struct intel_encoder *intel_encoder)
  {
-   enum drm_connector_status status;
-   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
-   struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   struct intel_hdmi *intel_hdmi =
+   enc_to_intel_hdmi(_encoder->base);
+   struct intel_connector *intel_connector =
+   intel_hdmi->attached_connector;
+   struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
bool live_status = false;
unsigned int retry = 3;

-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
- connector->base.id, connector->name);
-
while (!live_status && --retry) {
live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
@@ -1390,15 +1388,48 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
if (!live_status)
DRM_DEBUG_KMS("Live status not up!");

-   intel_hdmi_unset_edid(connector);
+   /*
+* We are here, means there is a hotplug or a force
+* detection. Clear the cached EDID and probe the
+* DDC bus to check the current status of HDMI.
+*/
+   intel_hdmi_unset_edid(_connector->base);
+   if (intel_hdmi_set_edid(_connector->base, live_status))
+   DRM_DEBUG_DRIVER("DDC probe: got EDID\n");
+   else
+   DRM_DEBUG_DRIVER("DDC probe: no EDID\n");
+}

-   if (intel_hdmi_set_edid(connector, live_status)) {
+static enum drm_connector_status
+intel_hdmi_detect(struct drm_connector *connector, bool force)
+{
+   enum drm_connector_status status;
+   struct intel_connector *intel_connector =
+   to_intel_connector(connector);
+
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+
+   /*
+* There are many userspace calls which probe EDID from
+* detect path. In case of multiple hotplug/unplug, these
+* can cause race conditions while

Re: [Intel-gfx] [PATCH 1/2] drm/i915/bxt: Set oscaledcompmethod to enable scale value

2015-09-23 Thread Jindal, Sonika

Thanks Imre for the explanation.
I will repost the patch..

Regards,
Sonika

-Original Message-
From: Deak, Imre 
Sent: Wednesday, September 23, 2015 5:15 PM
To: Jindal, Sonika
Cc: Thulasimani, Sivakumar; intel-gfx@lists.freedesktop.org; Ville Syrjälä
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/bxt: Set oscaledcompmethod to 
enable scale value

On ke, 2015-09-23 at 09:37 +0530, Jindal, Sonika wrote:
> 
> On 9/23/2015 1:02 AM, Imre Deak wrote:
> > On Wed, 2015-09-23 at 00:01 +0530, Sivakumar Thulasimani wrote:
> >>
> >> On 9/22/2015 6:32 PM, Imre Deak wrote:
> >>> On ma, 2015-09-21 at 23:00 +0530, Sivakumar Thulasimani wrote:
> >>>> Reviewed-by: Sivakumar Thulasimani 
> >>>> <sivakumar.thulasim...@intel.com>
> >>>>
> >>>> On 9/18/2015 2:11 PM, Sonika Jindal wrote:
> >>>>> Bspec update tells that we have to enable oscaledcompmethod 
> >>>>> instead of ouniqetrangenmethod for enabling scale value during swing 
> >>>>> programming.
> >>>>> Also, scale value is 'don't care' for other levels except the 
> >>>>> last entry translation table. So, make it 0 instead of 0x9A.
> >>>>>
> >>>>> Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
> >>>>> ---
> >>>>> drivers/gpu/drm/i915/i915_reg.h  |2 +-
> >>>>> drivers/gpu/drm/i915/intel_ddi.c |   22 +++---
> >>>>> 2 files changed, 12 insertions(+), 12 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >>>>> b/drivers/gpu/drm/i915/i915_reg.h index 812b7b2..cec6546 100644
> >>>>> --- a/drivers/gpu/drm/i915/i915_reg.h
> >>>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >>>>> @@ -1395,7 +1395,7 @@ enum skl_disp_power_wells {
> >>>>> #define BXT_PORT_TX_DW3_LN0(port)   _PORT3(port, 
> >>>>> _PORT_TX_DW3_LN0_A,  \
> >>>>>  
> >>>>> _PORT_TX_DW3_LN0_B,  \
> >>>>>  _PORT_TX_DW3_LN0_C)
> >>>>> -#define   UNIQE_TRANGE_EN_METHOD   (1 << 27)
> >>>>> +#define   SCALE_DCOMP_METHOD   (1 << 26)
> >>>>>
> >>>>> #define _PORT_TX_DW4_LN0_A  0x162510
> >>>>> #define _PORT_TX_DW4_LN0_B  0x6C510
> >>>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >>>>> b/drivers/gpu/drm/i915/intel_ddi.c
> >>>>> index fec51df..0d9b304 100644
> >>>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >>>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >>>>> @@ -261,15 +261,15 @@ struct bxt_ddi_buf_trans {
> >>>>>  */
> >>>>> static const struct bxt_ddi_buf_trans bxt_ddi_translations_dp[] = {
> >>>>> /* Idx  NT mV diff  db  */
> >>>>> -   { 52,  0x9A, 0, 128, true  },   /* 0:   400 0   */
> >>>>> -   { 78,  0x9A, 0, 85,  false },   /* 1:   400 3.5 */
> >>>>> -   { 104, 0x9A, 0, 64,  false },   /* 2:   400 6   */
> >>>>> -   { 154, 0x9A, 0, 43,  false },   /* 3:   400 9.5 */
> >>>>> -   { 77,  0x9A, 0, 128, false },   /* 4:   600 0   */
> >>>>> -   { 116, 0x9A, 0, 85,  false },   /* 5:   600 3.5 */
> >>>>> -   { 154, 0x9A, 0, 64,  false },   /* 6:   600 6   */
> >>>>> -   { 102, 0x9A, 0, 128, false },   /* 7:   800 0   */
> >>>>> -   { 154, 0x9A, 0, 85,  false },   /* 8:   800 3.5 */
> >>>>> +   { 52,  0, 0, 128, true  },  /* 0:   400 0   */
> >>>>> +   { 78,  0, 0, 85,  false },  /* 1:   400 3.5 */
> >>>>> +   { 104, 0, 0, 64,  false },  /* 2:   400 6   */
> >>>>> +   { 154, 0, 0, 43,  false },  /* 3:   400 9.5 */
> >>>>> +   { 77,  0, 0, 128, false },  /* 4:   600 0   */
> >>>>> +   { 116, 0, 0, 85,  false },  /* 5:   600 3.5 */
> >>>>> +   { 154, 0, 0, 64,  false },  /* 6:   600 6   */
> >>>>> +   { 102, 0, 0,

Re: [Intel-gfx] [PATCH 1/2] drm/i915/bxt: Set oscaledcompmethod to enable scale value

2015-09-22 Thread Jindal, Sonika




On 9/23/2015 1:02 AM, Imre Deak wrote:

On Wed, 2015-09-23 at 00:01 +0530, Sivakumar Thulasimani wrote:


On 9/22/2015 6:32 PM, Imre Deak wrote:

On ma, 2015-09-21 at 23:00 +0530, Sivakumar Thulasimani wrote:

Reviewed-by: Sivakumar Thulasimani 

On 9/18/2015 2:11 PM, Sonika Jindal wrote:

Bspec update tells that we have to enable oscaledcompmethod instead of
ouniqetrangenmethod for enabling scale value during swing programming.
Also, scale value is 'don't care' for other levels except the last entry
translation table. So, make it 0 instead of 0x9A.

Signed-off-by: Sonika Jindal 
---
drivers/gpu/drm/i915/i915_reg.h  |2 +-
drivers/gpu/drm/i915/intel_ddi.c |   22 +++---
2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 812b7b2..cec6546 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1395,7 +1395,7 @@ enum skl_disp_power_wells {
#define BXT_PORT_TX_DW3_LN0(port)   _PORT3(port, _PORT_TX_DW3_LN0_A,  \
 _PORT_TX_DW3_LN0_B,  \
 _PORT_TX_DW3_LN0_C)
-#define   UNIQE_TRANGE_EN_METHOD   (1 << 27)
+#define   SCALE_DCOMP_METHOD   (1 << 26)

#define _PORT_TX_DW4_LN0_A  0x162510
#define _PORT_TX_DW4_LN0_B  0x6C510
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fec51df..0d9b304 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -261,15 +261,15 @@ struct bxt_ddi_buf_trans {
 */
static const struct bxt_ddi_buf_trans bxt_ddi_translations_dp[] = {
/* Idx  NT mV diff  db  */
-   { 52,  0x9A, 0, 128, true  },   /* 0:   400 0   */
-   { 78,  0x9A, 0, 85,  false },   /* 1:   400 3.5 */
-   { 104, 0x9A, 0, 64,  false },   /* 2:   400 6   */
-   { 154, 0x9A, 0, 43,  false },   /* 3:   400 9.5 */
-   { 77,  0x9A, 0, 128, false },   /* 4:   600 0   */
-   { 116, 0x9A, 0, 85,  false },   /* 5:   600 3.5 */
-   { 154, 0x9A, 0, 64,  false },   /* 6:   600 6   */
-   { 102, 0x9A, 0, 128, false },   /* 7:   800 0   */
-   { 154, 0x9A, 0, 85,  false },   /* 8:   800 3.5 */
+   { 52,  0, 0, 128, true  },  /* 0:   400 0   */
+   { 78,  0, 0, 85,  false },  /* 1:   400 3.5 */
+   { 104, 0, 0, 64,  false },  /* 2:   400 6   */
+   { 154, 0, 0, 43,  false },  /* 3:   400 9.5 */
+   { 77,  0, 0, 128, false },  /* 4:   600 0   */
+   { 116, 0, 0, 85,  false },  /* 5:   600 3.5 */
+   { 154, 0, 0, 64,  false },  /* 6:   600 6   */
+   { 102, 0, 0, 128, false },  /* 7:   800 0   */
+   { 154, 0, 0, 85,  false },  /* 8:   800 3.5 */

There is no point in changing the above values as they are don't-care in
any case. In fact the reset value is 0x98 so I'd program that for these
cases if we ever wanted to change them. For now I'd leave this as-is to
keep in sync with the bxt_ddi_translations_hdmi table and also what CHV
does.

Now it doesn't make a difference after we have set the oscalecompmethod 
correctly. But when we were not doing that, this 'don't care' value was 
making a difference. It was being considered.
I am sure of this because with low vswing table, only when I added 0x9A, 
it worked for me because we were not unsetting the oscaledcompmenthod.


So, I think its better to reset it to some value other than 0x9A.
Regarding 0x98 being the reset value, is it mentioned in bspec? I 
couldn't find that in the table. If that is the case, we can make it 
0x98 instead of 0x9A.



{ 154, 0x9A, 1, 128, false },   /* 9:   12000   */
};




@@ -2151,9 +2151,9 @@ static void bxt_ddi_vswing_sequence(struct drm_device 
*dev, u32 level,
I915_WRITE(BXT_PORT_TX_DW2_GRP(port), val);

val = I915_READ(BXT_PORT_TX_DW3_LN0(port));
-   val &= ~UNIQE_TRANGE_EN_METHOD;
+   val &= ~SCALE_DCOMP_METHOD;
if (ddi_translations[level].enable)
-   val |= UNIQE_TRANGE_EN_METHOD;
+   val |= SCALE_DCOMP_METHOD;

Please still leave behind a DRM_ERROR in case UNIQE_TRANGE_EN_METHOD was
set in the register and we are disabling scaling. The scaling value does
seem to depend on this bit too, so seeing if it was set can help
tracking down problems.

Again, I couldn't find it mentioned anywhere that scaling value depends 
on "ouniqetrangenmethod" ? Is it in bspec?

Although it does seem to make a difference in case of low vswing table.
With default table, it edp continues to work if set or not set this

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Use intel_encoder->hpd_pin to check live status

2015-09-14 Thread Jindal, Sonika




On 9/14/2015 2:04 PM, Daniel Vetter wrote:

On Fri, Sep 11, 2015 at 04:58:32PM +0530, Sonika Jindal wrote:

Using intel_encoder's hpd_pin to check the live status
because of BXT A0/A1 WA for HPD pins and hpd_pin contains the
updated pin for the corresponding port.

Signed-off-by: Sonika Jindal 
---
  drivers/gpu/drm/i915/intel_dp.c |9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 796f930..bf17030 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4663,11 +4663,14 @@ static bool vlv_digital_port_connected(struct 
drm_i915_private *dev_priv,
  }

  static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+  struct intel_digital_port 
*intel_dig_port)
  {
+   struct intel_encoder *intel_encoder = _dig_port->base;
+   enum port port;
u32 bit;

-   switch (port->port) {
+   intel_hpd_pin_to_port(intel_encoder->hpd_pin, );


This looks very wrong - the function you're calling here maps from hpd_pin
to the port, but what you actually want is to map from port to pin. That
mapping is in intel_encoder->hpd_pin.
-Daniel

No, I want to find out the correct port whose hpd bit we need to check.
That port we are finding based upon the hpd_pin we have set for that 
encoder. This was the whole point of using hpd_pin for the BXT A0/A1 WA.
That instead of checking different HPD bit based upon the port, just 
change the hpd_pin itself in intel_encoder.


Regards,
Sonika



+   switch (port) {
case PORT_A:
bit = BXT_DE_PORT_HP_DDIA;
break;
@@ -4678,7 +4681,7 @@ static bool bxt_digital_port_connected(struct 
drm_i915_private *dev_priv,
bit = BXT_DE_PORT_HP_DDIC;
break;
default:
-   MISSING_CASE(port->port);
+   MISSING_CASE(port);
return false;
}

--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check live status before reading edid

2015-09-14 Thread Jindal, Sonika




On 9/14/2015 2:12 PM, Daniel Vetter wrote:

On Fri, Sep 11, 2015 at 05:56:47PM +, Rodrigo Vivi wrote:

Thanks

Reviewed-by: Rodrigo Vivi 


On Fri, Sep 11, 2015 at 4:38 AM Sonika Jindal 
wrote:


The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.

The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.

This is explained here in, in a rough way:
HPD line  
  |\ T1 = Monitor Hotplug causing IRQ
  | \__
  | |
  | |
  | |   T2 = Live status is stable
  | |  _
  | | /|
Live status _|_|/ |
  | |  |
  | |  |
  | |  |
 T0 T1  T2

(Between T1 and T2 Live status fluctuates or can be even low, depending on
  the monitor)

After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.

This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.

v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
 which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 


Since this is tricky stuff and other patches in this series are blocked
until we have a clearer picture can you please rebase this to be the first
patch on top of -nightly so that I can pull it in directly?

I tried to do that but proved a bit too messy.
-Daniel

Hmm, since rebasing this will require these changes (check for live 
status) to go in detect and then later when we reach a conclusion on

hot_plug hook, we would need to move it to that function.
I think lets wait for the conclusion on the placement of that function.
What do you suggest?

Regards,
Sonika

---
  drivers/gpu/drm/i915/intel_dp.c   |2 +-
  drivers/gpu/drm/i915/intel_drv.h  |2 ++
  drivers/gpu/drm/i915/intel_hdmi.c |   26 +++---
  3 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index bf17030..fedf6d1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4695,7 +4695,7 @@ static bool bxt_digital_port_connected(struct
drm_i915_private *dev_priv,
   *
   * Return %true if @port is connected, %false otherwise.
   */
-static bool intel_digital_port_connected(struct drm_i915_private
*dev_priv,
+bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
  struct intel_digital_port *port)
  {
 if (HAS_PCH_IBX(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index b6c2c20..ac6d748 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1210,6 +1210,8 @@ void intel_edp_drrs_disable(struct intel_dp
*intel_dp);
  void intel_edp_drrs_invalidate(struct drm_device *dev,
 unsigned frontbuffer_bits);
  void intel_edp_drrs_flush(struct drm_device *dev, unsigned
frontbuffer_bits);
+bool

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Use intel_encoder->hpd_pin to check live status

2015-09-12 Thread Jindal, Sonika

Thanks Rodrigo.
This is always true. The hpd_pin is the right pin which we set for particular 
port. So no fallback needed.

Regards,
Sonika

From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
Sent: Friday, September 11, 2015 11:31 PM
To: Jindal, Sonika; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Use intel_encoder->hpd_pin to 
check live status


On Fri, Sep 11, 2015 at 4:40 AM Sonika Jindal 
<sonika.jin...@intel.com<mailto:sonika.jin...@intel.com>> wrote:
Using intel_encoder's hpd_pin to check the live status
because of BXT A0/A1 WA for HPD pins and hpd_pin contains the
updated pin for the corresponding port.

It makes sense, but is it always true? or we should have a fallback to 
intel_dig_port->port in some case or in some stepping after A0/A1?

With this clarified feel free to use:
Reviewed-by: Rodrigo Vivi 
<rodrigo.v...@intel.com<mailto:rodrigo.v...@intel.com>>


Signed-off-by: Sonika Jindal 
<sonika.jin...@intel.com<mailto:sonika.jin...@intel.com>>
---
 drivers/gpu/drm/i915/intel_dp.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 796f930..bf17030 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4663,11 +4663,14 @@ static bool vlv_digital_port_connected(struct 
drm_i915_private *dev_priv,
 }

 static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+  struct intel_digital_port 
*intel_dig_port)
 {
+   struct intel_encoder *intel_encoder = _dig_port->base;
+   enum port port;
u32 bit;

-   switch (port->port) {
+   intel_hpd_pin_to_port(intel_encoder->hpd_pin, );
+   switch (port) {
case PORT_A:
bit = BXT_DE_PORT_HP_DDIA;
break;
@@ -4678,7 +4681,7 @@ static bool bxt_digital_port_connected(struct 
drm_i915_private *dev_priv,
bit = BXT_DE_PORT_HP_DDIC;
break;
default:
-   MISSING_CASE(port->port);
+   MISSING_CASE(port);
return false;
}

--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org<mailto:Intel-gfx@lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add HDMI probe function

2015-09-11 Thread Jindal, Sonika




On 9/10/2015 12:25 AM, Rodrigo Vivi wrote:

I liked the approach and agree with Daniel, so with his suggestions feel
free to use:
Reviewed-by: Rodrigo Vivi >

On Fri, Sep 4, 2015 at 7:46 AM Daniel Vetter > wrote:

On Fri, Sep 04, 2015 at 06:56:12PM +0530, Sonika Jindal wrote:
 > From: Shashank Sharma >
 >
 > This patch adds a separate probe function for HDMI
 > EDID read over DDC channel. This function has been
 > registered as a .hot_plug handler for HDMI encoder.
 >
 > The current implementation of hdmi_detect()
 > function re-sets the cached HDMI edid (in connector->detect_edid) in
 > every detect call.This function gets called many times, sometimes
 > directly from userspace probes, forcing drivers to read EDID every
 > detect function call.This causes several problems like:
 >
 > 1. Race conditions in multiple hot_plug / unplug cases, between
 >interrupts bottom halves and userspace detections.
 > 2. Many Un-necessary EDID reads for single hotplug/unplug
 > 3. HDMI complaince failures which expects only one EDID read per
hotplug
 >
 > This function will be serving the purpose of really reading the EDID
 > by really probing the DDC channel, and updating the cached EDID.
 >
 > The plan is to:
 > 1. i915 IRQ handler bottom half function already calls
 >intel_encoder->hotplug() function. Adding This probe function
which
 >will read the EDID only in case of a hotplug / unplug.
 > 2. During init_connector his probe will be called to read the edid
 > 3. Reuse the cached EDID in hdmi_detect() function.
 >
 > The "< gen7" check is there because this was tested only for >=gen7
 > platforms. For older platforms the hotplug/reading edid path
remains same.
 >
 > v2: Calling set_edid instead of hdmi_probe during init.
 > Also, for platforms having DDI, intel_encoder for DP and HDMI is same
 > (taken from intel_dig_port), so for DP also, hot_plug function
gets called
 > which is not intended here. So, check for HDMI in intel_hdmi_probe
 > Rely on HPD for updating edid only for platforms gen > 8 and also
for VLV.
 >
 > v3: Dropping the gen < 8 || !VLV  check. Now all platforms should
rely on
 > hotplug or init for updating the edid.(Daniel)
 > Also, calling hdmi_probe in init instead of set_edid
 >
 > Signed-off-by: Shashank Sharma >
 > Signed-off-by: Sonika Jindal >
 > ---
 >  drivers/gpu/drm/i915/intel_hdmi.c |   46
-
 >  1 file changed, 40 insertions(+), 6 deletions(-)
 >
 > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
 > index 5bdb386..1eda71a 100644
 > --- a/drivers/gpu/drm/i915/intel_hdmi.c
 > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 > @@ -1368,23 +1368,53 @@ intel_hdmi_set_edid(struct drm_connector
*connector)
 >   return connected;
 >  }
 >
 > +void intel_hdmi_probe(struct intel_encoder *intel_encoder)

Please call it _hot_plug if it's for the _hot_plug path.


Hmm, initial plan was to call it from other places if any..
But now it seems more logical to name it _hot_plug.
I will do that.


 > +{
 > + struct intel_hdmi *intel_hdmi =
 > + enc_to_intel_hdmi(_encoder->base);
 > + struct intel_connector *intel_connector =
 > + intel_hdmi->attached_connector;
 > +
 > + /*
 > +  * We are here, means there is a hotplug or a force
 > +  * detection. Clear the cached EDID and probe the
 > +  * DDC bus to check the current status of HDMI.
 > +  */
 > + intel_hdmi_unset_edid(_connector->base);
 > + if (intel_hdmi_set_edid(_connector->base))
 > + DRM_DEBUG_DRIVER("DDC probe: got EDID\n");
 > + else
 > + DRM_DEBUG_DRIVER("DDC probe: no EDID\n");
 > +}
 > +
 >  static enum drm_connector_status
 >  intel_hdmi_detect(struct drm_connector *connector, bool force)
 >  {
 >   enum drm_connector_status status;
 > + struct intel_connector *intel_connector =
 > + to_intel_connector(connector);
 >
 >   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
 > connector->base.id ,
connector->name);
 > + /*
 > +  * There are many userspace calls which probe EDID from
 > +  * detect path. In case of multiple hotplug/unplug, these
 > +  * can cause race conditions while probing EDID. Also its

Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Fix irq_port for eDP

2015-09-10 Thread Jindal, Sonika

All this is because of the BXT A0/A1 workaround for HPD pins.
As you can see, this is only done for BXT A0/A1 and can be removed when we have 
newer stable steppings.
Durga can add more..

Regards,
Sonika

From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
Sent: Thursday, September 10, 2015 12:54 AM
To: Jindal, Sonika; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Fix irq_port for eDP

Nak: I don't believe we need this... Actually I believe we need the opposite... 
we need to enable HPD on port A for eDP errors handling...




On Fri, Sep 4, 2015 at 6:38 AM Sonika Jindal 
<sonika.jin...@intel.com<mailto:sonika.jin...@intel.com>> wrote:
From: Durgadoss R <durgados...@intel.com<mailto:durgados...@intel.com>>

Currently, HDMI hotplug with eDP as local panel is failing
because the HDMI hpd is detected as a long hpd for eDP; and is
thus rightfully ignored. But, it should really be handled as
an interrupt on port B for HDMI (due to BXT A1 platform having
HPD pins A and B swapped). This patch sets the irq_port[PORT_A]
to NULL in case eDP is on port A so that irq handler does not
treat it as a 'dig_port' interrupt.

Signed-off-by: Durgadoss R <durgados...@intel.com<mailto:durgados...@intel.com>>
---
 drivers/gpu/drm/i915/intel_ddi.c |   15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4823184..fec51df 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3218,15 +3218,20 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
goto err;

intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
+   dev_priv->hotplug.irq_port[port] = intel_dig_port;
/*
 * On BXT A0/A1, sw needs to activate DDIA HPD logic and
 * interrupts to check the external panel connection.
+* If eDP is connected on port A, set irq_port to NULL
+* so that we do not assume an interrupt here as a
+* 'dig_port' interrupt.
 */
-   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
-&& port == PORT_B)
-   dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
-   else
-   dev_priv->hotplug.irq_port[port] = intel_dig_port;
+   if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
+   if (port == PORT_B)
+   dev_priv->hotplug.irq_port[PORT_A] = 
intel_dig_port;
+   else if (intel_encoder->type == INTEL_OUTPUT_EDP)
+   dev_priv->hotplug.irq_port[port] = NULL;
+   }
}

/* In theory we don't need the encoder->type check, but leave it just in
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org<mailto:Intel-gfx@lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/6] drm/i915: drm/i915: Process hpd only for hdmi inside hotplug_work_func

2015-09-09 Thread Jindal, Sonika

Since, the port is enumerated as DP as well as hdmi, the init connector is 
called for both and the same intel encoder gets attached to both the connectors.
Now the intel_encoder’s type could be a differentiator. But since, hdmi’s 
detect gets called, the type of the encoder remains hdmi.
When hpd occurs, it checks from the list of connectors whose hpd pin is same as 
the one asserted.
Since both dp and hdmi are INITed, both the connectors have that pin and since 
DP’s connector is first in the list, it calls the ->hot_plug once when it finds 
DP connector matching and then again when HDMI connector is found matching as 
per the pin.

This code check will avoid calling in the case when we have found the DP 
connector because we are sure that there is no ->hot_plug hook for DP.
Anyways, that was not a generic implementation.

Regards,
Sonika

From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
Sent: Thursday, September 10, 2015 12:51 AM
To: Jindal, Sonika; Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: drm/i915: Process hpd only for 
hdmi inside hotplug_work_func

I was also going to say that I believe this breaks DP hotplug, but this was 
agreed already...

But I also don't understand how hot_plug is called twice since it calls 
encoder->hot_plug...
and dp has no ->hot_plug...
And also if this is happening how this code that checks for connector would 
help... there is something else strange happening...

On Sat, Sep 5, 2015 at 9:31 PM Jindal, Sonika 
<sonika.jin...@intel.com<mailto:sonika.jin...@intel.com>> wrote:

On 9/4/2015 8:17 PM, Daniel Vetter wrote:
> On Fri, Sep 04, 2015 at 06:56:15PM +0530, Sonika Jindal wrote:
>> If the same port is enumerated as hdmi as well as DP, this will get
>> called for DP connector as well which is not required because
>> i915_hotplug_work_func is solely to handle hdmi HPD.
>>
>> Signed-off-by: Sonika Jindal 
>> <sonika.jin...@intel.com<mailto:sonika.jin...@intel.com>>
>> ---
>>   drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
>> b/drivers/gpu/drm/i915/intel_hotplug.c
>> index 53c0173..8e1c43e 100644
>> --- a/drivers/gpu/drm/i915/intel_hotplug.c
>> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
>> @@ -325,7 +325,8 @@ static void i915_hotplug_work_func(struct work_struct 
>> *work)
>>
>>  list_for_each_entry(connector, _config->connector_list, head) {
>>  intel_connector = to_intel_connector(connector);
>> -if (!intel_connector->encoder)
>> +if (!intel_connector->encoder
>> +&& connector->connector_type != 
>> DRM_MODE_CONNECTOR_HDMIA)
>>  continue;
>
> Pretty sure this breaks hotplug detection for everything but HDMI (since
> now nothing but hdmi gets called it's ->detect function, and only if that
> signals a status change will we send out an uevent to userspace). Does
> this really not break DP hotplug?
>
> Yes we probe both hdmi and DP always, and probably we could be more
> intelligent with the fallback between the too. But this here doesn't seem
> to be the right solution.
> -Daniel

Hmm :(
This doesn't allow detect to be called for dp. I missed the part that
hpd_pulse only handles mst. From the name and comments it looks like it
should handle hpd for dp completely. I think this this code needs some
refactoring.

For now, I think I better move this check to intel_encoder->hot_plug
function because for the connectors with dp and hdmi both, this hot_plug
hook gets called twice.

>
>>  intel_encoder = intel_connector->encoder;
>>  if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
>> --
>> 1.7.10.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org<mailto:Intel-gfx@lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org<mailto:Intel-gfx@lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Call encoder hot_plug hook only for hdmi

2015-09-09 Thread Jindal, Sonika



-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, September 9, 2015 8:48 PM
To: Jindal, Sonika
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Sharma, Shashank
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Call encoder hot_plug hook only for 
hdmi

On Tue, Sep 08, 2015 at 05:08:02PM +0530, Jindal, Sonika wrote:
> 
> 
> On 9/8/2015 10:12 AM, Jindal, Sonika wrote:
> >
> >
> >On 9/7/2015 9:56 PM, Daniel Vetter wrote:
> >>On Mon, Sep 07, 2015 at 10:34:34AM +0530, Sonika Jindal wrote:
> >>>If the same port is enumerated as hdmi as well as DP, this will 
> >>>call hot_plug hook for DP as well which is not required here.
> >>>This splitting of edid read and detect is done only for HDMI with 
> >>>this series.
> >>>
> >>>v2: Avoid breaking DP hpd. Also corrected the commit message and 
> >>>description accordingly. (Daniel)
> >>>
> >>>Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
> >>>---
> >>>  drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
> >>>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> >>>b/drivers/gpu/drm/i915/intel_hotplug.c
> >>>index 53c0173..ff4692a 100644
> >>>--- a/drivers/gpu/drm/i915/intel_hotplug.c
> >>>+++ b/drivers/gpu/drm/i915/intel_hotplug.c
> >>>@@ -331,7 +331,8 @@ static void i915_hotplug_work_func(struct 
> >>>work_struct *work)
> >>>  if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
> >>>  DRM_DEBUG_KMS("Connector %s (pin %i) received hotplug 
> >>>event.\n",
> >>>connector->name, intel_encoder->hpd_pin);
> >>>-if (intel_encoder->hot_plug)
> >>>+if (intel_encoder->hot_plug
> >>>+&& connector->connector_type ==
> >>>DRM_MODE_CONNECTOR_HDMIA)
> >>
> >>Please use something like grep to find all the other ->hot_plug 
> >>implementations and then please tell me why you don't break them all.
> >>-Daniel
> >>
> >Hmm, I only checked for hot_plug for DP/edp which is not there. 
> >Failed to notice that there is one in intel_sdvo.c.
> >My mistake. I will place it properly somewhere else.
> >
> >Regards,
> >Sonika
> 
> Is there any suggestion about how we can differentiate if it is actual 
> DP or HDMI hotplug at this point? intel_encoder's type gets updated 
> after detect call. So, not sure how to have this kind of check.
> 
> For now, I think we can abandon this patch from this series.

No, hpd is shared between hdmi and dp at the hw level so we can't 
differentiate. Long term my idea would be that we merge together all the hdmi 
_and_ dp hpd handling into one overall control-flow. Then we can make sure to 
not call anything twice and also have sensible high-level flow (like first 
checking for dp vs. hdmi and then taking relevant paths).

For dealing with ->hot_plug a quick fix might be to have a separate loop going 
over encoders (to make sure we only call it once per encoder if there's more 
than one connector for 1 encoder). That behaviour would also be ok for sdvo.

 Hmm, so instead of relying on connector, we can check for the hpd_pin 
on encoder and remove the connector loop completely?

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Call encoder hot_plug hook only for hdmi

2015-09-08 Thread Jindal, Sonika




On 9/8/2015 10:12 AM, Jindal, Sonika wrote:



On 9/7/2015 9:56 PM, Daniel Vetter wrote:

On Mon, Sep 07, 2015 at 10:34:34AM +0530, Sonika Jindal wrote:

If the same port is enumerated as hdmi as well as DP, this will call
hot_plug hook for DP as well which is not required here.
This splitting of edid read and detect is done only for HDMI with this
series.

v2: Avoid breaking DP hpd. Also corrected the commit message and
description accordingly. (Daniel)

Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
---
  drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 53c0173..ff4692a 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -331,7 +331,8 @@ static void i915_hotplug_work_func(struct
work_struct *work)
  if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
  DRM_DEBUG_KMS("Connector %s (pin %i) received hotplug
event.\n",
connector->name, intel_encoder->hpd_pin);
-if (intel_encoder->hot_plug)
+if (intel_encoder->hot_plug
+&& connector->connector_type ==
DRM_MODE_CONNECTOR_HDMIA)


Please use something like grep to find all the other ->hot_plug
implementations and then please tell me why you don't break them all.
-Daniel


Hmm, I only checked for hot_plug for DP/edp which is not there. Failed
to notice that there is one in intel_sdvo.c.
My mistake. I will place it properly somewhere else.

Regards,
Sonika


Is there any suggestion about how we can differentiate if it is actual 
DP or HDMI hotplug at this point? intel_encoder's type gets updated 
after detect call. So, not sure how to have this kind of check.


For now, I think we can abandon this patch from this series.

Regards,
Sonika

  intel_encoder->hot_plug(intel_encoder);
  if (intel_hpd_irq_event(dev, connector))
  changed = true;
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Call encoder hot_plug hook only for hdmi

2015-09-07 Thread Jindal, Sonika




On 9/7/2015 9:56 PM, Daniel Vetter wrote:

On Mon, Sep 07, 2015 at 10:34:34AM +0530, Sonika Jindal wrote:

If the same port is enumerated as hdmi as well as DP, this will call
hot_plug hook for DP as well which is not required here.
This splitting of edid read and detect is done only for HDMI with this
series.

v2: Avoid breaking DP hpd. Also corrected the commit message and
description accordingly. (Daniel)

Signed-off-by: Sonika Jindal 
---
  drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 53c0173..ff4692a 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -331,7 +331,8 @@ static void i915_hotplug_work_func(struct work_struct *work)
if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
DRM_DEBUG_KMS("Connector %s (pin %i) received hotplug 
event.\n",
  connector->name, intel_encoder->hpd_pin);
-   if (intel_encoder->hot_plug)
+   if (intel_encoder->hot_plug
+   && connector->connector_type == 
DRM_MODE_CONNECTOR_HDMIA)


Please use something like grep to find all the other ->hot_plug
implementations and then please tell me why you don't break them all.
-Daniel

Hmm, I only checked for hot_plug for DP/edp which is not there. Failed 
to notice that there is one in intel_sdvo.c.

My mistake. I will place it properly somewhere else.

Regards,
Sonika

intel_encoder->hot_plug(intel_encoder);
if (intel_hpd_irq_event(dev, connector))
changed = true;
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/6] drm/i915: drm/i915: Process hpd only for hdmi inside hotplug_work_func

2015-09-05 Thread Jindal, Sonika




On 9/4/2015 8:17 PM, Daniel Vetter wrote:

On Fri, Sep 04, 2015 at 06:56:15PM +0530, Sonika Jindal wrote:

If the same port is enumerated as hdmi as well as DP, this will get
called for DP connector as well which is not required because
i915_hotplug_work_func is solely to handle hdmi HPD.

Signed-off-by: Sonika Jindal 
---
  drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 53c0173..8e1c43e 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -325,7 +325,8 @@ static void i915_hotplug_work_func(struct work_struct *work)

list_for_each_entry(connector, _config->connector_list, head) {
intel_connector = to_intel_connector(connector);
-   if (!intel_connector->encoder)
+   if (!intel_connector->encoder
+   && connector->connector_type != 
DRM_MODE_CONNECTOR_HDMIA)
continue;


Pretty sure this breaks hotplug detection for everything but HDMI (since
now nothing but hdmi gets called it's ->detect function, and only if that
signals a status change will we send out an uevent to userspace). Does
this really not break DP hotplug?

Yes we probe both hdmi and DP always, and probably we could be more
intelligent with the fallback between the too. But this here doesn't seem
to be the right solution.
-Daniel


Hmm :(
This doesn't allow detect to be called for dp. I missed the part that 
hpd_pulse only handles mst. From the name and comments it looks like it 
should handle hpd for dp completely. I think this this code needs some 
refactoring.


For now, I think I better move this check to intel_encoder->hot_plug 
function because for the connectors with dp and hdmi both, this hot_plug 
hook gets called twice.





intel_encoder = intel_connector->encoder;
if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: Add YUV pixel format in Capability list

2015-09-03 Thread Jindal, Sonika

Reviewed-by: Sonika Jindal 

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Kumar, Mahesh
Sent: Thursday, September 3, 2015 4:17 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: Add YUV pixel format in 
Capability list

GEN >= 9 supports YUV format for all planes, but it's not exported in 
Capability list of primary plane. Add YUV formats in skl_primary_formats list.

Testcase: igt/kms_universal_plane.c

Signed-off-by: Kumar, Mahesh 
Cc: Konduru, Chandra 
---
 drivers/gpu/drm/i915/intel_display.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0377520..5ab8a1a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,10 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_ABGR,
DRM_FORMAT_XRGB2101010,
DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
 };
 
 /* Cursor formats */
--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Avoid using un-initialized bits_per_pixel

2015-09-03 Thread Jindal, Sonika

Reviewed-by: Sonika Jindal 

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Kumar, Mahesh
Sent: Thursday, September 3, 2015 4:17 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Avoid using un-initialized 
bits_per_pixel

Don't rely on fb->bits_per_pixel as intel_framebuffer_init is not filling 
bits_per_pixel field of fb-struct for YUV pixel format.
This leads to divide by zero error during watermark calculation.

Signed-off-by: Kumar, Mahesh 
Cc: Konduru, Chandra 
---
 drivers/gpu/drm/i915/intel_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c 
index ea49661..1b90f03 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3170,7 +3170,8 @@ static void skl_compute_wm_pipe_parameters(struct 
drm_crtc *crtc,
if (fb) {
p->plane[0].enabled = true;
p->plane[0].bytes_per_pixel = fb->pixel_format == 
DRM_FORMAT_NV12 ?
-   drm_format_plane_cpp(fb->pixel_format, 1) : 
fb->bits_per_pixel / 8;
+   drm_format_plane_cpp(fb->pixel_format, 1) :
+   drm_format_plane_cpp(fb->pixel_format, 0);
p->plane[0].y_bytes_per_pixel = fb->pixel_format == 
DRM_FORMAT_NV12 ?
drm_format_plane_cpp(fb->pixel_format, 0) : 0;
p->plane[0].tiling = fb->modifier[0];
--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

2015-09-02 Thread Jindal, Sonika

When hpd occurs on port_b, due to the below assignment, it calls 
digital_port_wok_func first.
There it tries to check the connector status for port B (actually checking port 
A's HPD pin due to the BXT WA).
It finds it connected and continues to read the dpcd. Since this port was only 
initialized as HDMI and not initialized as DP, we haven't initialized the aux 
and causes crash in the case when the port is only enumerated as HDMI alone.
So, this part needs to be moved under the init_dp check itself.
I will be posting Durga's original patch along with hdmi patches because this 
is required for hdmi to work on bxt.

Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, September 2, 2015 5:21 PM
To: Jindal, Sonika
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

On Wed, Sep 02, 2015 at 11:48:36AM +, Jindal, Sonika wrote:
> :( This had a hole..
> Please drop this patch..

What kind of hole? It sounds like we need this to avoid blowing up when we 
handle the edp hpd interrupt everywhere? Please explain so I can understand 
what I've missed here ...

Thanks, Daniel

> 
> I am going to send another patch tested with hdmi optimization series for bxt.
> 
> Regards,
> Sonika
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
> Daniel Vetter
> Sent: Wednesday, September 2, 2015 5:17 PM
> To: Jindal, Sonika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP
> 
> On Mon, Aug 31, 2015 at 02:35:32PM +0530, Sonika Jindal wrote:
> > From: Durgadoss R <durgados...@intel.com>
> > 
> > Currently, HDMI hotplug with eDP as local panel is failing because 
> > the HDMI hpd is detected as a long hpd for eDP; and is thus 
> > rightfully ignored. But, it should really be handled as an interrupt 
> > on port B for HDMI (due to BXT A1 platform having HPD pins A and B swapped).
> > This patch sets the irq_port[PORT_A] to NULL in case eDP is on port 
> > A so that irq handler does not treat it as a 'dig_port' interrupt.
> > 
> > v2 (Sonika): Moving the setting of irq_port for BXT WA outside so 
> > that this can be set for both hdmi or dp ports. For HDMI this is 
> > required because we get interrupts for portB on the hpd line of 
> > portA for BXT A0/A1.
> > This issue occurred because hpd on edp was not disabled which was 
> > done as part of "drm/i915: Dont enable hpd for eDP" from the series:
> > http://lists.freedesktop.org/archives/intel-gfx/2015-August/073266.h
> > tm
> > l
> > 
> > This patch can be squashed to :
> > commit cf1d58833f07afbb4534b15caa3fd48baa313b2c
> > Author: Sonika Jindal <sonika.jin...@intel.com>
> > Date:   Mon Aug 10 10:35:36 2015 +0530
> > 
> > drm/i915/bxt: WA for swapped HPD pins in A stepping
> > 
> > Signed-off-by: Durgadoss R <durgados...@intel.com>
> > Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
> 
> Queued for -next, thanks for the patch.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c |   21 -
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 56d778f..bba0cb6 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3242,15 +3242,7 @@ void intel_ddi_init(struct drm_device *dev, enum 
> > port port)
> > goto err;
> >  
> > intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> > -   /*
> > -* On BXT A0/A1, sw needs to activate DDIA HPD logic and
> > -* interrupts to check the external panel connection.
> > -*/
> > -   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
> > -&& port == PORT_B)
> > -   dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> > -   else
> > -   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> > +   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> > }
> >  
> > /* In theory we don't need the encoder->type check, but leave it 
> > just in @@ -3259,6 +3251,17 @@ void intel_ddi_init(struct drm_device *dev, 
> > enum port port)
> > if (!intel_ddi_init_hdmi_connector(intel_dig_port))
> > goto err;
&

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

2015-09-02 Thread Jindal, Sonika

:( This had a hole..
Please drop this patch..

I am going to send another patch tested with hdmi optimization series for bxt.

Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, September 2, 2015 5:17 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

On Mon, Aug 31, 2015 at 02:35:32PM +0530, Sonika Jindal wrote:
> From: Durgadoss R <durgados...@intel.com>
> 
> Currently, HDMI hotplug with eDP as local panel is failing because the 
> HDMI hpd is detected as a long hpd for eDP; and is thus rightfully 
> ignored. But, it should really be handled as an interrupt on port B 
> for HDMI (due to BXT A1 platform having HPD pins A and B swapped). 
> This patch sets the irq_port[PORT_A] to NULL in case eDP is on port A 
> so that irq handler does not treat it as a 'dig_port' interrupt.
> 
> v2 (Sonika): Moving the setting of irq_port for BXT WA outside so that 
> this can be set for both hdmi or dp ports. For HDMI this is required 
> because we get interrupts for portB on the hpd line of portA for BXT 
> A0/A1.
> This issue occurred because hpd on edp was not disabled which was done 
> as part of "drm/i915: Dont enable hpd for eDP" from the series:
> http://lists.freedesktop.org/archives/intel-gfx/2015-August/073266.htm
> l
> 
> This patch can be squashed to :
> commit cf1d58833f07afbb4534b15caa3fd48baa313b2c
> Author: Sonika Jindal <sonika.jin...@intel.com>
> Date:   Mon Aug 10 10:35:36 2015 +0530
> 
> drm/i915/bxt: WA for swapped HPD pins in A stepping
> 
> Signed-off-by: Durgadoss R <durgados...@intel.com>
> Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_ddi.c |   21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 56d778f..bba0cb6 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3242,15 +3242,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> port)
>   goto err;
>  
>   intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> - /*
> -  * On BXT A0/A1, sw needs to activate DDIA HPD logic and
> -  * interrupts to check the external panel connection.
> -  */
> - if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
> -  && port == PORT_B)
> - dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> - else
> - dev_priv->hotplug.irq_port[port] = intel_dig_port;
> + dev_priv->hotplug.irq_port[port] = intel_dig_port;
>   }
>  
>   /* In theory we don't need the encoder->type check, but leave it 
> just in @@ -3259,6 +3251,17 @@ void intel_ddi_init(struct drm_device *dev, 
> enum port port)
>   if (!intel_ddi_init_hdmi_connector(intel_dig_port))
>   goto err;
>   }
> + /*
> +  * On BXT A0/A1, sw needs to activate DDIA HPD logic and
> +  * interrupts to check the external panel connection.
> +  */
> + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
> + if (port == PORT_B) {
> + dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> + intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> + } else if (intel_encoder->type == INTEL_OUTPUT_EDP)
> + dev_priv->hotplug.irq_port[port] = NULL;
> + }
>  
>   return;
>  
> --
> 1.7.10.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Retry for live status

2015-08-26 Thread Jindal, Sonika

HPD bits control the interrupt but the live status (with some monitors) takes 
time to get set.
We had experienced this with VLV and CHV with few monitors.
So Android code always has this retry for live status.

Yes, this was not added in the previous series because we planned to add the 
next set of optimization a little while later.
But this seems to be an important one.

It will be great if you can try it with your ivb. But for that you would need 
to first change the gen check and add a call to check live status for ivb.

Regards,
Sonika
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, August 26, 2015 3:10 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Retry for live status

On Tue, Aug 25, 2015 at 05:31:33PM +0530, Sonika Jindal wrote:
 Some monitors take time in setting the live status.
 So retry for few times if this is a connect HPD
 
 Signed-off-by: Sonika Jindal sonika.jin...@intel.com

Why was this bugfix not part of the original series? Now I have to retest on my 
ivb to figure out whether maybe this one here is the issue ...

Also how exactly does this work? I thought the hpd bits control whether we get 
an interrupt, not the other way round? Why exactly does this help?
Definitely needs a lot more explanation.

Also this seems to break bisect, since before the preceeding patch to check hpd 
status we just retried edid reading for a while.

This kind of hacking doesn't really convince me that hpd status is working, 
just that our own testing isn't good enough to catch all real-world issues.
-Daniel

 ---
  drivers/gpu/drm/i915/intel_hdmi.c |   15 +++
  1 file changed, 15 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
 b/drivers/gpu/drm/i915/intel_hdmi.c
 index 59518b4..239d70d 100644
 --- a/drivers/gpu/drm/i915/intel_hdmi.c
 +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 @@ -1415,6 +1415,7 @@ void intel_hdmi_probe(struct intel_encoder 
 *intel_encoder)
   struct intel_connector *intel_connector =
   intel_hdmi-attached_connector;
   bool live_status = false;
 + unsigned int retry = 3;
  
   /*
* Sometimes DDI ports are enumerated as DP as well as HDMI and @@ 
 -1425,6 +1426,20 @@ void intel_hdmi_probe(struct intel_encoder *intel_encoder)
   return;
  
   live_status = intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi));
 + if (!intel_connector-detect_edid  live_status == false) {
 + /*
 +  * Hotplug had occurred and old status was disconnected,
 +  * so it might be possible that live status is not set,
 +  * so retry for few times
 +  */
 + do {
 + mdelay(10);
 + live_status = 
 intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi));
 + if (live_status)
 + break;
 + } while (retry--);
 + }
 +
   /*
* We are here, means there is a hotplug or a force
* detection. Clear the cached EDID and probe the
 --
 1.7.10.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common intel_digital_port_connected function

2015-08-25 Thread Jindal, Sonika

So, looks like I can use intel_digital_port_connected for hdmi case.
In that case, we can make this function global and add a case for bxt as well.

Regards,
Sonika

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Jani Nikula
Sent: Thursday, August 20, 2015 1:18 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani
Subject: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common 
intel_digital_port_connected function

Add a common intel_digital_port_connected() that splits out to functions for 
different platforms. No functional changes.

v2: make the function return a boolean

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 41 ++---
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index f08859471841..f947951a01d4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,13 +4473,6 @@ edp_detect(struct intel_dp *intel_dp)
return status;
 }
 
-/*
- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
 static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
   struct intel_digital_port *port)  { @@ 
-4524,13 +4517,12 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(SDEISR)  bit;
 }
 
-static bool g4x_digital_port_connected(struct drm_device *dev,
+static bool g4x_digital_port_connected(struct drm_i915_private 
+*dev_priv,
   struct intel_digital_port *port)  {
-   struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
 
-   if (IS_VALLEYVIEW(dev)) {
+   if (IS_VALLEYVIEW(dev_priv)) {
switch (port-port) {
case PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_VLV; @@ -4565,6 
+4557,22 @@ static bool g4x_digital_port_connected(struct drm_device *dev,
return I915_READ(PORT_HOTPLUG_STAT)  bit;  }
 
+/*
+ * intel_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Return %true if @port is connected, %false otherwise.
+ */
+static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *port)
+{
+   if (HAS_PCH_SPLIT(dev_priv))
+   return ibx_digital_port_connected(dev_priv, port);
+   else
+   return g4x_digital_port_connected(dev_priv, port); }
+
 static enum drm_connector_status
 ironlake_dp_detect(struct intel_dp *intel_dp)  { @@ -4572,7 +4580,7 @@ 
ironlake_dp_detect(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 
-   if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
+   if (!intel_digital_port_connected(dev_priv, intel_dig_port))
return connector_status_disconnected;
 
return intel_dp_detect_dpcd(intel_dp); @@ -4594,7 +4602,7 @@ 
g4x_dp_detect(struct intel_dp *intel_dp)
return status;
}
 
-   if (!g4x_digital_port_connected(dev, intel_dig_port))
+   if (!intel_digital_port_connected(dev-dev_private, intel_dig_port))
return connector_status_disconnected;
 
return intel_dp_detect_dpcd(intel_dp); @@ -5057,13 +5065,8 @@ 
intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
/* indicate that we need to restart link training */
intel_dp-train_set_valid = false;
 
-   if (HAS_PCH_SPLIT(dev)) {
-   if (!ibx_digital_port_connected(dev_priv, 
intel_dig_port))
-   goto mst_fail;
-   } else {
-   if (!g4x_digital_port_connected(dev, intel_dig_port))
-   goto mst_fail;
-   }
+   if (!intel_digital_port_connected(dev_priv, intel_dig_port))
+   goto mst_fail;
 
if (!intel_dp_get_dpcd(intel_dp)) {
goto mst_fail;
--
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/7] drm/i915: move ibx_digital_port_connected to intel_dp.c

2015-08-25 Thread Jindal, Sonika

Hmm, so we might need to make it global again, because we would want to check 
the live status for hdmi in the hdmi optimization series:
http://lists.freedesktop.org/archives/intel-gfx/2015-August/074306.html 
Maybe we can drop this patch alone?

Regards,
Sonika

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Jani Nikula
Sent: Thursday, August 20, 2015 1:18 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani
Subject: [Intel-gfx] [PATCH v2 1/7] drm/i915: move ibx_digital_port_connected 
to intel_dp.c

The function can be made static there. No functional changes.

Reviewed-by: Durgadoss R durgados...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 45 --
 drivers/gpu/drm/i915/intel_dp.c  | 61 +++-
 drivers/gpu/drm/i915/intel_drv.h |  2 --
 3 files changed, 53 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f604ce1c528b..1a0670259cdf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1061,51 +1061,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc 
*crtc)
}
 }
 
-/*
- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
-bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
-   struct intel_digital_port *port)
-{
-   u32 bit;
-
-   if (HAS_PCH_IBX(dev_priv-dev)) {
-   switch (port-port) {
-   case PORT_B:
-   bit = SDE_PORTB_HOTPLUG;
-   break;
-   case PORT_C:
-   bit = SDE_PORTC_HOTPLUG;
-   break;
-   case PORT_D:
-   bit = SDE_PORTD_HOTPLUG;
-   break;
-   default:
-   return true;
-   }
-   } else {
-   switch (port-port) {
-   case PORT_B:
-   bit = SDE_PORTB_HOTPLUG_CPT;
-   break;
-   case PORT_C:
-   bit = SDE_PORTC_HOTPLUG_CPT;
-   break;
-   case PORT_D:
-   bit = SDE_PORTD_HOTPLUG_CPT;
-   break;
-   default:
-   return true;
-   }
-   }
-
-   return I915_READ(SDEISR)  bit;
-}
-
 static const char *state_string(bool enabled)  {
return enabled ? on : off;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index d32ce4841654..4aa3d664765b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,17 +4473,49 @@ edp_detect(struct intel_dp *intel_dp)
return status;
 }
 
-static enum drm_connector_status
-ironlake_dp_detect(struct intel_dp *intel_dp)
+/*
+ * ibx_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Returns true if @port is connected, false otherwise.
+ */
+static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port)
 {
-   struct drm_device *dev = intel_dp_to_dev(intel_dp);
-   struct drm_i915_private *dev_priv = dev-dev_private;
-   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   u32 bit;
 
-   if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
-   return connector_status_disconnected;
+   if (HAS_PCH_IBX(dev_priv-dev)) {
+   switch (port-port) {
+   case PORT_B:
+   bit = SDE_PORTB_HOTPLUG;
+   break;
+   case PORT_C:
+   bit = SDE_PORTC_HOTPLUG;
+   break;
+   case PORT_D:
+   bit = SDE_PORTD_HOTPLUG;
+   break;
+   default:
+   return true;
+   }
+   } else {
+   switch (port-port) {
+   case PORT_B:
+   bit = SDE_PORTB_HOTPLUG_CPT;
+   break;
+   case PORT_C:
+   bit = SDE_PORTC_HOTPLUG_CPT;
+   break;
+   case PORT_D:
+   bit = SDE_PORTD_HOTPLUG_CPT;
+   break;
+   default:
+   return true;
+   }
+   }
 
-   return intel_dp_detect_dpcd(intel_dp);
+   return I915_READ(SDEISR)  bit;
 }
 
 static int g4x_digital_port_connected(struct drm_device *dev, @@ -4528,6 
+4560,19 @@ static int

Re: [Intel-gfx] [PATCH v2 7/7] drm/i915/bxt: Use correct live status register for BXT platform

2015-08-25 Thread Jindal, Sonika

Oh, bxt is here..:) Spoke too soon..
But will need to make it based upon intel_encoder-hpd_pin because of the A0/A1 
WA for BXT.
Also, we need to make intel_digital_port_connected global to be accessed from 
intel_hdmi.c

Regards,
Sonika

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Jani Nikula
Sent: Thursday, August 20, 2015 1:18 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani
Subject: [Intel-gfx] [PATCH v2 7/7] drm/i915/bxt: Use correct live status 
register for BXT platform

BXT platform uses live status bits from 0x0 register to obtain DP status on 
hotplug. The existing g4x_digital_port_connected() uses a different register 
and hence misses DP hotplug events on BXT platform. This patch fixes it by 
using the appropriate register(0x0) and live status bits(3:5).

Based on a patch by Durgadoss R durgados...@intel.com, from whom the commit 
message is shamelessly copy pasted.

Reported-by: Durgadoss R durgados...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index 36291838409b..508156cc750d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4569,6 +4569,29 @@ static bool vlv_digital_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(PORT_HOTPLUG_STAT)  bit;  }
 
+static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port) {
+   u32 bit;
+
+   switch (port-port) {
+   case PORT_A:
+   bit = BXT_DE_PORT_HP_DDIA;
+   break;
+   case PORT_B:
+   bit = BXT_DE_PORT_HP_DDIB;
+   break;
+   case PORT_C:
+   bit = BXT_DE_PORT_HP_DDIC;
+   break;
+   default:
+   MISSING_CASE(port-port);
+   return false;
+   }
+
+   return I915_READ(GEN8_DE_PORT_ISR)  bit; }
+
 /*
  * intel_digital_port_connected - is the specified port connected?
  * @dev_priv: i915 private structure
@@ -4583,6 +4606,8 @@ static bool intel_digital_port_connected(struct 
drm_i915_private *dev_priv,
return ibx_digital_port_connected(dev_priv, port);
if (HAS_PCH_SPLIT(dev_priv))
return cpt_digital_port_connected(dev_priv, port);
+   else if (IS_BROXTON(dev_priv))
+   return bxt_digital_port_connected(dev_priv, port);
else if (IS_VALLEYVIEW(dev_priv))
return vlv_digital_port_connected(dev_priv, port);
else
--
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V2] drm/i915/skl+: Add YUV pixel format in Capability list

2015-08-24 Thread Jindal, Sonika

Can you please add the test case name to the commit message?
Also, this should be split into two patches one addressing the divide by zero 
error and another one to add plane formats.

Regards,
Sonika

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Kumar, Mahesh
Sent: Friday, July 17, 2015 7:21 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH V2] drm/i915/skl+: Add YUV pixel format in 
Capability list

GEN = 9 supports YUV format for all planes, but it's not exported in 
Capability list of primary plane. Add YUV formats in skl_primary_formats list.
Don't rely on fb-bits_per_pixel as intel_framebuffer_init is not filling 
bits_per_pixel field of fb-struct for YUV pixel format.
This leads to divide by zero error during watermark calculation.

V2: Don't break NV12 case.

Signed-off-by: Kumar, Mahesh mahesh1.ku...@intel.com
Cc: Konduru, Chandra chandra.kond...@intel.com
---

 IGT changes made for testcase will be sent in separate patch.

 drivers/gpu/drm/i915/intel_display.c | 4 
 drivers/gpu/drm/i915/intel_pm.c  | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index af0bcfe..d31704a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,10 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_ABGR,
DRM_FORMAT_XRGB2101010,
DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
 };
 
 /* Cursor formats */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c 
index 5eeddc9..5768f8c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3164,7 +3164,8 @@ static void skl_compute_wm_pipe_parameters(struct 
drm_crtc *crtc,
if (fb) {
p-plane[0].enabled = true;
p-plane[0].bytes_per_pixel = fb-pixel_format == 
DRM_FORMAT_NV12 ?
-   drm_format_plane_cpp(fb-pixel_format, 1) : 
fb-bits_per_pixel / 8;
+   drm_format_plane_cpp(fb-pixel_format, 1) :
+   drm_format_plane_cpp(fb-pixel_format, 0);
p-plane[0].y_bytes_per_pixel = fb-pixel_format == 
DRM_FORMAT_NV12 ?
drm_format_plane_cpp(fb-pixel_format, 0) : 0;
p-plane[0].tiling = fb-modifier[0];
--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Use dpcd read wake for sink crc calls.

2015-08-23 Thread Jindal, Sonika

So, sink crc during psr works now?
Great, I will give a try with this patch..

Regards,
Sonika

-Original Message-
From: Vivi, Rodrigo 
Sent: Friday, August 21, 2015 4:53 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; Antognolli, Rafael; Jindal, Sonika
Subject: [PATCH] drm/i915: Use dpcd read wake for sink crc calls.

Let's use a native read with retry as suggested per spec to fix Sink CRC on SKL 
when PSR is enabled.

With PSR enabled panel is probably taking more time to wake and dpcd read is 
faling.

v2: Fix my email domain on commit message. Thanks Rafael.

Cc: Rafael Antognolli rafael.antogno...@intel.com
Cc: Sonika Jindal sonika.jin...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index d32ce48..34f5e33 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4037,7 +4037,8 @@ static int intel_dp_sink_crc_stop(struct intel_dp 
*intel_dp)
u8 buf;
int ret = 0;
 
-   if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf)  0) {
+   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_TEST_SINK,
+   buf, 1)  0) {
DRM_DEBUG_KMS(Sink CRC couldn't be stopped properly\n);
ret = -EIO;
goto out;
@@ -4069,7 +4070,8 @@ static int intel_dp_sink_crc_start(struct intel_dp 
*intel_dp)
return ret;
}
 
-   if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK_MISC, buf)  0)
+   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_TEST_SINK_MISC,
+   buf, 1)  0)
return -EIO;
 
if (!(buf  DP_TEST_CRC_SUPPORTED))
@@ -4077,7 +4079,7 @@ static int intel_dp_sink_crc_start(struct intel_dp 
*intel_dp)
 
intel_dp-sink_crc.last_count = buf  DP_TEST_COUNT_MASK;
 
-   if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf)  0)
+   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_TEST_SINK, buf, 1)  
+0)
return -EIO;
 
hsw_disable_ips(intel_crtc);
@@ -4109,8 +4111,8 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
do {
intel_wait_for_vblank(dev, intel_crtc-pipe);
 
-   if (drm_dp_dpcd_readb(intel_dp-aux,
- DP_TEST_SINK_MISC, buf)  0) {
+   if (intel_dp_dpcd_read_wake(intel_dp-aux,
+   DP_TEST_SINK_MISC, buf, 1)  0) {
ret = -EIO;
goto stop;
}
@@ -4123,7 +4125,8 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
if (count == 0)
intel_dp-sink_crc.last_count = 0;
 
-   if (drm_dp_dpcd_read(intel_dp-aux, DP_TEST_CRC_R_CR, crc, 6) 
 0) {
+   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_TEST_CRC_R_CR,
+   crc, 6)  0) {
ret = -EIO;
goto stop;
}
--
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check live status before reading edid

2015-08-16 Thread Jindal, Sonika




On 8/10/2015 11:14 AM, Sivakumar Thulasimani wrote:



On 7/14/2015 5:21 PM, Sonika Jindal wrote:

Adding this for SKL onwards.

v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c   |4 ++--
  drivers/gpu/drm/i915/intel_drv.h  |2 ++
  drivers/gpu/drm/i915/intel_hdmi.c |   43
+
  3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
  return intel_dp_detect_dpcd(intel_dp);
  }
-static int g4x_digital_port_connected(struct drm_device *dev,
-   struct intel_digital_port *intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+   struct intel_digital_port *intel_dig_port)
  {
  struct drm_i915_private *dev_priv = dev-dev_private;
  uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp
*intel_dp);
  void intel_edp_drrs_invalidate(struct drm_device *dev,
  unsigned frontbuffer_bits);
  void intel_edp_drrs_flush(struct drm_device *dev, unsigned
frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+   struct intel_digital_port *intel_dig_port);
  /* intel_dp_mst.c */
  int intel_dp_mst_encoder_init(struct intel_digital_port
*intel_dig_port, int conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index c4b82ce..402be54 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,40 @@ intel_hdmi_unset_edid(struct drm_connector
*connector)
  to_intel_connector(connector)-detect_edid = NULL;
  }
+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+   struct intel_digital_port *port)
+{
+u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+/* TODO: Add bxt A0/A1 wa related to hpd pin swap */
+switch (port-port) {

why not pass the encoder and use its hpd_pin ? that will avoid the need
to do
A0/A1 related checks ?
This was kept to make it inline with the other functions which does the 
same thing. But because of the work around i think it will make sense to 
try the way you suggest.



+case PORT_B:
+return temp  BXT_DE_PORT_HP_DDIB;
+
+case PORT_C:
+return temp  BXT_DE_PORT_HP_DDIC;
+
+default:
+return false;
+
+}
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port
*intel_dig_port)
+{
+struct drm_device *dev = intel_dig_port-base.base.dev;
+struct drm_i915_private *dev_priv = to_i915(dev);
+
+if (IS_VALLEYVIEW(dev))
+return g4x_digital_port_connected(dev, intel_dig_port);
+else if (IS_SKYLAKE(dev))
+return ibx_digital_port_connected(dev_priv, intel_dig_port);
+else if (IS_BROXTON(dev))
+return bxt_port_connected(dev_priv, intel_dig_port);
+
+return true;
+}
+
  static bool
  intel_hdmi_set_edid(struct drm_connector *connector)
  {
@@ -1308,15 +1342,16 @@ intel_hdmi_set_edid(struct drm_connector
*connector)
  struct intel_encoder *intel_encoder =
  hdmi_to_dig_port(intel_hdmi)-base;
  enum intel_display_power_domain power_domain;
-struct edid *edid;
+struct edid *edid = NULL;
  bool connected = false;
  power_domain = intel_display_port_power_domain(intel_encoder);
  intel_display_power_get(dev_priv, power_domain);
-edid = drm_get_edid(connector,
-intel_gmbus_get_adapter(dev_priv,
-intel_hdmi-ddc_bus));
+if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+edid = drm_get_edid(connector,
+intel_gmbus_get_adapter(dev_priv,
+intel_hdmi-ddc_bus));
  intel_display_power_put(dev_priv, power_domain);



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

2015-08-14 Thread Jindal, Sonika

Looks good to me.
Reviewed-by: Sonika Jindal sonika.jin...@intel.com

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Sivakumar Thulasimani
Sent: Friday, August 7, 2015 3:15 PM
To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test 
reply

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

DP spec requires the checksum of the last block read to be written when 
replying to TEST_EDID_READ. This patch fixes the current code to do the same.

v2: removed loop for jumping blocks and performed direct addition as 
recommended by Daniel

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index f1b9f93..fa6e202 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4090,9 +4090,16 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
  intel_dp-aux.i2c_defer_count);
intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
} else {
+   struct edid *block = intel_connector-detect_edid;
+
+   /* We have to write the checksum
+* of the last block read
+*/
+   block += intel_connector-detect_edid-extensions;
+
if (!drm_dp_dpcd_write(intel_dp-aux,
DP_TEST_EDID_CHECKSUM,
-   intel_connector-detect_edid-checksum,
+   block-checksum,
1))
DRM_DEBUG_KMS(Failed to write EDID checksum\n);
 
--
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.

2015-08-12 Thread Jindal, Sonika




On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote:

On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:

On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:

-Original Message-
From: Vivi, Rodrigo
Sent: Saturday, August 8, 2015 8:34 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; Zhang, Xiong Y
Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4
lanes.

DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we
need to configure lane count propperly for both.

This was based on Sonika's
[PATCH] drm/i915/skl: Select DDIA lane capability based upon vbt

Credits-to: Sonika Jindal sonika.jin...@intel.com
Cc: Xiong Zhang xiong.y.zh...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
drivers/gpu/drm/i915/intel_dp.c  |  8 +---
  2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 110d546..557cecf 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device
*dev, enum port port)
struct intel_digital_port *intel_dig_port;
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
-   bool init_hdmi, init_dp;
+   bool init_hdmi, init_dp, ddi_e_present;
+
+   /*
+* On SKL we don't have a way to detect DDI-E so we
rely
on VBT.
+*/
+   ddie_present = IS_SKYLAKE(dev) 
+   (dev_priv
-vbt.ddi_port_info[PORT_E].supports_dp



+dev_priv
-vbt.ddi_port_info[PORT_E].supports_dvi



+dev_priv
-vbt.ddi_port_info[PORT_E].supports_hdmi);

[Zhang, Xiong Y]  ddie_present should be ddi_e_present


init_hdmi = (dev_priv
-vbt.ddi_port_info[port].supports_dvi ||
 dev_priv
-vbt.ddi_port_info[port].supports_hdmi);
@@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device
*dev, enum port port)
intel_dig_port-port = port;
intel_dig_port-saved_port_bits =
I915_READ(DDI_BUF_CTL(port)) 

  (DDI_BUF_PORT_REVERSAL |
-  DDI_A_4_LANES);
+  ddi_e_present ? 0 :
DDI_A_4_LANES);

[Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when
DDI-E doesn't exist, I think your patch will do nothing.


Actually DDI_A_4_LANES is being already set unconditionally, so
Sonika's patch has no effect.

[Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under many
conditions.
+   if (IS_SKYLAKE(dev)  port == PORT_A
+!(val  DDI_BUF_CTL_ENABLE)
+!dev_priv-vbt.ddi_e_used)
+   I915_WRITE(DDI_BUF_CTL(port), val | DDI_A_4_LANES)


saved_port_bits goes to intel_dp-DP that goes to DDI_BUF_CTL and
also it is used to calculate the number of lanes.

With this patch we stop setting DDI_A_4_LANES when ddi_e is present
so DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E

[Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES when ddi_e
is present.
But this patch won't set DDI_A_4_LANES under following conditions
which is purpose for Sonika patch 1. Bios fail to driver eDP and
doesn't enable DDI_A buffer


If DDI_A isn't enabled we don't need to set DDI_A_4_LANES

[Zhang, Xiong Y] From commit message on Sonika patch, she want to
set DDI_A_4_LANES on such case. Maybe she met such fail case on one high
resolution eDP screen. Let's Sonikia explain it.



2. Bios clear DDI_A_4_LANES
3. DDI_E isn't present


I don't agree... This is already covered on current code. DDI_A_4_LANES is
already being set when enabling DDI_A.

As Zhang mentioned and as my commit message explains, my patch is needed 
when bios failed to drive edp (In my case it was an intermediate 
frequency supported panel which was set to 3.24 GHz and bios didn't have 
support for intermediate frequencies), it will not enable DDIA in which 
case, it will not set DDI_BUF_CTL and DDI Lane capability will remain 0 
(which is DDIA with 2 lanes and DDIE with 2 lanes).
So, since the native resolution of that panel was high and couldn't work 
with 2 lanes.
So, ideally we should not rely on bios to set the initial value and set 
it based upon whether DDI_E is used or not.

So, my patch has some effect :)




thanks



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Update HAS_PSR macro to include all gen=8 platforms

2015-08-10 Thread Jindal, Sonika

I replied to Daniel last time. Pasting it on mailing list as well:

Yes this is tested on android with HW tracking. Not sure about enabling by 
default part. But this patch will be anyways required.

Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, July 21, 2015 3:18 PM
To: Lespiau, Damien
Cc: Jindal, Sonika; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Update HAS_PSR macro to include all 
gen=8 platforms

On Tue, Jul 21, 2015 at 10:31:19AM +0100, Damien Lespiau wrote:
 On Tue, Jul 21, 2015 at 02:48:31PM +0530, Sonika Jindal wrote:
  This is to get PSR support for bxt.
  
  Signed-off-by: Sonika Jindal sonika.jin...@intel.com
 
 Maybe with a drm/i915/bxt prefix:
 
 Reviewed-by: Damien Lespiau damien.lesp...@intel.com

Is this actually tested? Can we maybe enable psr by default (Rodrigo seems so 
close ...)?
-Daniel

 
 --
 Damien
 
  ---
   drivers/gpu/drm/i915/i915_drv.h |5 ++---
   1 file changed, 2 insertions(+), 3 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
  b/drivers/gpu/drm/i915/i915_drv.h index 718170c..54d2729 100644
  --- a/drivers/gpu/drm/i915/i915_drv.h
  +++ b/drivers/gpu/drm/i915/i915_drv.h
  @@ -2537,9 +2537,8 @@ struct drm_i915_cmd_table {
   
   #define HAS_DDI(dev)   (INTEL_INFO(dev)-has_ddi)
   #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)-has_fpga_dbg)
  -#define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_BROADWELL(dev) 
  || \
  -IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
  -IS_SKYLAKE(dev))
  +#define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_VALLEYVIEW(dev) 
  || \
  +INTEL_INFO(dev)-gen = 8)
   #define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
   IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
   IS_SKYLAKE(dev))
  --
  1.7.10.4
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series

2015-08-10 Thread Jindal, Sonika




On 8/10/2015 1:38 PM, Daniel Vetter wrote:

On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote:

Hi Daniel,

That patch was already merged:
http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.html

For SKL, the above patch helped in getting the correct ISR bits set.
One option is to enable the HDMI optimization from VLV onwards.
I don't have an ivb machine to try out the issue.


ivb is simple the machine I have here, but when we tried this the last
time around we had reports for all platforms (your patch still doesn't
cite the relevant sha1 btw). I think there are 3 possible explanations:


Yes, I don't know which were those patches and how to find them..


a) we do something wrong with hpd handling on these platforms. That seems
to be the explanation you favour (with the gen = 7 checks and all that),
but I think it's very unlikely: On each platform where we had reports of
hpd being broken there was also machines where hpd works perfectly fine.


Not sure, I will find one ivb system and try on that.


b) There's broken HDMI (or DVI) sinks out there. If that's the case we can
never merge your patch.
I doubt this because we have tested these patches with many sinks in the 
past with VLV/CHV.


c) There's something in vbt or somewhere else that tells the windows
driver whether using hpd or not is ok (and the hpd problem is actually an
issue with certain OEM machines ...).


No, nothing like that.


I hoped that with your hpd handling fix we'd have some indication that our
hpd troubles are of type a). But since I tested with your patch that
didn't work out.

And until we have some evidence that our hpd troubles aren't type b) I
really don't want to merge any patch which relies upon hpd bits for hdmi.
-Daniel


I will try on ivb.

Regards
Sonika



Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, August 7, 2015 6:54 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series

On Tue, Jul 14, 2015 at 05:21:20PM +0530, Sonika Jindal wrote:

This series adds some optimization related to reading of edid only
when required and when live status says so.
The comments in the patches explain more.


This series breaks my funky ivb machine with the broken hpd bits: When I unplug 
the screen the system never invalidates the edid and so never notices that it's 
gone.

Now iirc you've discovered an issue in our hpd irq handler which can cause lost 
hpd bits, but that patch isn't in this series. And iirc I asked you to resend 
everything since that hw fix also wasn't in the last series. And I can't find 
it any more. Did I just dream about this other patch to fix hpd on big core?

Thanks, Daniel


v2:
Some refactoring is with this series.

Also, right now this is done for platforms gen7 and above because we
couldn't test with older platforms. For newer platforms it works
reliably.

For HPD and live status to work on SKL, following patch is required:
drm/i915: Handle HPD when it has actually occurred

Shashank Sharma (2):
   drm/i915: add attached connector to hdmi container
   drm/i915: Add HDMI probe function

Sonika Jindal (1):
   drm/i915: Check live status before reading edid

  drivers/gpu/drm/i915/intel_dp.c   |4 +-
  drivers/gpu/drm/i915/intel_drv.h  |3 ++
  drivers/gpu/drm/i915/intel_hdmi.c |   93 +
  3 files changed, 88 insertions(+), 12 deletions(-)

--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series

2015-08-09 Thread Jindal, Sonika

Hi Daniel,

That patch was already merged:
http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.html

For SKL, the above patch helped in getting the correct ISR bits set.
One option is to enable the HDMI optimization from VLV onwards.
I don't have an ivb machine to try out the issue.

Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, August 7, 2015 6:54 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series

On Tue, Jul 14, 2015 at 05:21:20PM +0530, Sonika Jindal wrote:
 This series adds some optimization related to reading of edid only 
 when required and when live status says so.
 The comments in the patches explain more.

This series breaks my funky ivb machine with the broken hpd bits: When I unplug 
the screen the system never invalidates the edid and so never notices that it's 
gone.

Now iirc you've discovered an issue in our hpd irq handler which can cause lost 
hpd bits, but that patch isn't in this series. And iirc I asked you to resend 
everything since that hw fix also wasn't in the last series. And I can't find 
it any more. Did I just dream about this other patch to fix hpd on big core?

Thanks, Daniel

 v2:
Some refactoring is with this series.
 
Also, right now this is done for platforms gen7 and above because we
couldn't test with older platforms. For newer platforms it works
reliably.
 
For HPD and live status to work on SKL, following patch is required:
drm/i915: Handle HPD when it has actually occurred
 
 Shashank Sharma (2):
   drm/i915: add attached connector to hdmi container
   drm/i915: Add HDMI probe function
 
 Sonika Jindal (1):
   drm/i915: Check live status before reading edid
 
  drivers/gpu/drm/i915/intel_dp.c   |4 +-
  drivers/gpu/drm/i915/intel_drv.h  |3 ++
  drivers/gpu/drm/i915/intel_hdmi.c |   93 
 +
  3 files changed, 88 insertions(+), 12 deletions(-)
 
 --
 1.7.10.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping

2015-07-22 Thread Jindal, Sonika




On 7/22/2015 4:03 PM, Sivakumar Thulasimani wrote:



On 7/22/2015 3:37 PM, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c  |   12 +++-
  drivers/gpu/drm/i915/intel_dp.c   |4 
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..d5745e2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,17 @@ void intel_ddi_init(struct drm_device *dev,
enum port port)
  goto err;
  intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
-dev_priv-hotplug.irq_port[port] = intel_dig_port;
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0)) {
+if (port == PORT_B)
+dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+else if (port == PORT_A)
+dev_priv-hotplug.irq_port[PORT_C] = intel_dig_port;
+} else
+dev_priv-hotplug.irq_port[port] = intel_dig_port;
  }
  /* In theory we don't need the encoder-type check, but leave it
just in
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct
intel_digital_port *intel_dig_port,
  switch (port) {
  case PORT_A:
  intel_encoder-hpd_pin = HPD_PORT_A;
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_C;
  break;
  case PORT_B:
  intel_encoder-hpd_pin = HPD_PORT_B;
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_A;
  break;
  case PORT_C:
  intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
  intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
  else
  intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-intel_encoder-hpd_pin = HPD_PORT_B;
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_A;
+else
+intel_encoder-hpd_pin = HPD_PORT_B;
  break;
  case PORT_C:
  if (IS_BROXTON(dev_priv))

bxt_hpd_irq_setup is not touched here without this being updated i dont
think HPD can be enabled.
Now, we swap the hpd_pin, which is being used to enable HPD in 
bxt_hpd_irq_setup.


Regards,
Sonika



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping

2015-07-22 Thread Jindal, Sonika




On 7/22/2015 5:01 PM, Sivakumar Thulasimani wrote:



On 7/22/2015 4:39 PM, Jindal, Sonika wrote:



On 7/22/2015 4:03 PM, Sivakumar Thulasimani wrote:



On 7/22/2015 3:37 PM, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c  |   12 +++-
  drivers/gpu/drm/i915/intel_dp.c   |4 
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..d5745e2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,17 @@ void intel_ddi_init(struct drm_device *dev,
enum port port)
  goto err;
  intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
-dev_priv-hotplug.irq_port[port] = intel_dig_port;
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev) 
BXT_REVID_B0)) {
+if (port == PORT_B)
+dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+else if (port == PORT_A)
+dev_priv-hotplug.irq_port[PORT_C] = intel_dig_port;
+} else
+dev_priv-hotplug.irq_port[port] = intel_dig_port;
  }
  /* In theory we don't need the encoder-type check, but leave it
just in
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct
intel_digital_port *intel_dig_port,
  switch (port) {
  case PORT_A:
  intel_encoder-hpd_pin = HPD_PORT_A;
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_C;
  break;
  case PORT_B:
  intel_encoder-hpd_pin = HPD_PORT_B;
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_A;
  break;
  case PORT_C:
  intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
  intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
  else
  intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-intel_encoder-hpd_pin = HPD_PORT_B;
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_A;
+else
+intel_encoder-hpd_pin = HPD_PORT_B;
  break;
  case PORT_C:
  if (IS_BROXTON(dev_priv))

bxt_hpd_irq_setup is not touched here without this being updated i dont
think HPD can be enabled.

Now, we swap the hpd_pin, which is being used to enable HPD in
bxt_hpd_irq_setup.


yes, but the hpd_pin which is updated to HPD_PORT_A when enters
bxt_hpd_setup_irq we are enabling
only HPD B  C. so it will not enable HPDA. unless i am missing some
patch i am not seeing code to
enable HPD A with latest nightly code.


Yes, you are missing the patch 1 of this series :)
[PATCH 1/2] drm/i915/bxt: Add HPD support for DDIA


Regards,
Sonika





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] drm/i915/bxt: HPD long/short pulse detect support on port A

2015-07-21 Thread Jindal, Sonika



For the patch 3, the commit message can be changed to only long pulse 
detection instead of long/short because you are not adding support 
for short pulse detection.


Otherwise, this series looks good to me.

Reviewed-by: Sonika Jindal sonika.jin...@intel.com

On 7/21/2015 3:13 AM, Imre Deak wrote:

This patchset is a dependency for enabling generic HPD support on the
port A pin.

Imre Deak (3):
   drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
   drm/i915: don't use HPD_PORT_A as an alias for HPD_NONE
   drm/i915/bxt: add support for HPD long/short pulse detection on
 HPD_PORT_A pin

  drivers/gpu/drm/i915/i915_drv.h  |  4 +-
  drivers/gpu/drm/i915/i915_irq.c  | 72 ++--
  drivers/gpu/drm/i915/i915_reg.h  |  5 +++
  drivers/gpu/drm/i915/intel_hotplug.c | 20 ++
  4 files changed, 55 insertions(+), 46 deletions(-)


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping

2015-07-20 Thread Jindal, Sonika




On 7/18/2015 5:17 AM, Imre Deak wrote:

On Fri, 2015-07-17 at 13:47 +0530, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c  |   10 +-
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..777e3a3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,15 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
goto err;

intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
-   dev_priv-hotplug.irq_port[port] = intel_dig_port;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0)
+ port == PORT_B)
+   dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;


This happens to work but is confusing. irq_port[PORT_A] will be set here
already and the above will simply overwrite it without explanation. I
would also handle the port == PORT_A case and not set irq_port for it.

The same swapping for hpd_pin is missing from intel_dp_init_connector().


+   else
+   dev_priv-hotplug.irq_port[port] = intel_dig_port;
}

/* In theory we don't need the encoder-type check, but leave it just in
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
else
intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-   intel_encoder-hpd_pin = HPD_PORT_B;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
if (IS_BROXTON(dev_priv))


As I earlier pointed out with the above approach, you need to add
support for HPD events on the HPD_PORT_A pin. If you look at the
for_each_hpd_pin() macro and intel_hpd_irq_handler()/is_dig_port you'll
notice that any interrupt event on the HPD_PORT_A pin will be ignored
now.
Hmm :(. For now, we can fix for_each_hpd_pin and add a check in 
intel_hpd_pin_to_port to return PORT_B for pin 0 if A0/A1. Then we can 
skip the check in intel_ddi_init. But this again will look very confusing.


So two options:
1. We move back to the older approach where we just use another hpd 
ports array in i915_irq.c

2. Go with current approach.

I feel option 1 is more clean and less prone to further issues.
What do you suggest?

Regards,
Sonika


--Imre


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: WA for swapped HPD pins in A stepping

2015-07-16 Thread Jindal, Sonika




On 7/15/2015 2:37 PM, Daniel Vetter wrote:

On Wed, Jul 15, 2015 at 01:34:29PM +0530, Jindal, Sonika wrote:



On 7/15/2015 12:05 PM, Jindal, Sonika wrote:



On 7/14/2015 7:52 PM, Imre Deak wrote:

On ti, 2015-07-14 at 11:18 +0530, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
   drivers/gpu/drm/i915/intel_dp.c   |   18 --
   drivers/gpu/drm/i915/intel_hdmi.c |9 -
   2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7b54b9d..c32f3d3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5869,10 +5869,24 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
-   intel_encoder-hpd_pin = HPD_PORT_A;
+   /*
+* On BXT A0/A1, sw needs to activate DDIC HPD logic and
+* interrupts to check the eDP panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_C;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_B:
-   intel_encoder-hpd_pin = HPD_PORT_B;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;


This won't work for a couple of reasons: atm i915_digport_work_func()
assumes a fixed pin-port mapping, for example it'll call the HPD
handler for the port A encoder for a short/long pulse event triggered
via the HPD_PORT_A pin, whereas after the above patch you want to select
port B's encoder on BXT A0/1. This could be fixed by setting up
hotplug.irq_port in intel_ddi_init() according to the above change, or
not using irq_port at all, but instead looking up the encoder the same
way i915_hotplug_work_func() does using intel_encoder-hpd_pin.


Yeah that's kinda a bug in digport_work_func, but that part is also a
mess. Simplest would be to rename hotplug.irq_port to irq_pin and change
the assignment for that too.


Hmm, i didnt realize that.
Moving this check to intel_ddi_init, will again make the checks spread
all over which we wanted to avoid since hpd_pin was in place.
But looks like hpd_pin is only for i915_hotplug_work_func.
I feel we can move back to the older approach itself
What do you suggest?


But then we can remove these checks from here, and have it only in
intel_ddi_init, right? So it should look fine.

For HPD_PORT_A, I think we can skip that part as of now.

Please suggest..


I still think that fake-handling hpd A in the low-level irq handler is
massively confusing. And we need to change all the same parts anyway (i.e.
you'd have to change the digport_work_func too with the old approach).
-Daniel


So, for now, I will just correct it in intel_ddi_init and leave the 
handling of HPD for port A untouched. I will only change the irq_port 
for external DP (port B). And the other part with hpd_pin to handle hdmi 
hotplug will remain as is.

Please let me know if you see any issue in this.

Regards,
Sonika



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: WA for swapped HPD pins in A stepping

2015-07-15 Thread Jindal, Sonika




On 7/15/2015 12:05 PM, Jindal, Sonika wrote:



On 7/14/2015 7:52 PM, Imre Deak wrote:

On ti, 2015-07-14 at 11:18 +0530, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
   drivers/gpu/drm/i915/intel_dp.c   |   18 --
   drivers/gpu/drm/i915/intel_hdmi.c |9 -
   2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7b54b9d..c32f3d3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5869,10 +5869,24 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
-   intel_encoder-hpd_pin = HPD_PORT_A;
+   /*
+* On BXT A0/A1, sw needs to activate DDIC HPD logic and
+* interrupts to check the eDP panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_C;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_B:
-   intel_encoder-hpd_pin = HPD_PORT_B;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;


This won't work for a couple of reasons: atm i915_digport_work_func()
assumes a fixed pin-port mapping, for example it'll call the HPD
handler for the port A encoder for a short/long pulse event triggered
via the HPD_PORT_A pin, whereas after the above patch you want to select
port B's encoder on BXT A0/1. This could be fixed by setting up
hotplug.irq_port in intel_ddi_init() according to the above change, or
not using irq_port at all, but instead looking up the encoder the same
way i915_hotplug_work_func() does using intel_encoder-hpd_pin.


Hmm, i didnt realize that.
Moving this check to intel_ddi_init, will again make the checks spread
all over which we wanted to avoid since hpd_pin was in place.
But looks like hpd_pin is only for i915_hotplug_work_func.
I feel we can move back to the older approach itself
What do you suggest?

But then we can remove these checks from here, and have it only in 
intel_ddi_init, right? So it should look fine.


For HPD_PORT_A, I think we can skip that part as of now.

Please suggest..


Daniel, any comments?


The HPD_PORT_A HPD handling is missing in general, see
for_each_hpd_pin() and intel_hpd_irq_handler()/is_dig_port.




So if going with the above way, these issues need to be addressed first.

--Imre



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: WA for swapped HPD pins in A stepping

2015-07-15 Thread Jindal, Sonika




On 7/14/2015 7:52 PM, Imre Deak wrote:

On ti, 2015-07-14 at 11:18 +0530, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c   |   18 --
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7b54b9d..c32f3d3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5869,10 +5869,24 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
-   intel_encoder-hpd_pin = HPD_PORT_A;
+   /*
+* On BXT A0/A1, sw needs to activate DDIC HPD logic and
+* interrupts to check the eDP panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_C;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_B:
-   intel_encoder-hpd_pin = HPD_PORT_B;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;


This won't work for a couple of reasons: atm i915_digport_work_func()
assumes a fixed pin-port mapping, for example it'll call the HPD
handler for the port A encoder for a short/long pulse event triggered
via the HPD_PORT_A pin, whereas after the above patch you want to select
port B's encoder on BXT A0/1. This could be fixed by setting up
hotplug.irq_port in intel_ddi_init() according to the above change, or
not using irq_port at all, but instead looking up the encoder the same
way i915_hotplug_work_func() does using intel_encoder-hpd_pin.


Hmm, i didnt realize that.
Moving this check to intel_ddi_init, will again make the checks spread 
all over which we wanted to avoid since hpd_pin was in place.

But looks like hpd_pin is only for i915_hotplug_work_func.
I feel we can move back to the older approach itself
What do you suggest?

Daniel, any comments?


The HPD_PORT_A HPD handling is missing in general, see
for_each_hpd_pin() and intel_hpd_irq_handler()/is_dig_port.




So if going with the above way, these issues need to be addressed first.

--Imre



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check live status before reading edid

2015-07-14 Thread Jindal, Sonika




On 7/14/2015 7:59 PM, Imre Deak wrote:

On ti, 2015-07-14 at 17:21 +0530, Sonika Jindal wrote:

Adding this for SKL onwards.

v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c   |4 ++--
  drivers/gpu/drm/i915/intel_drv.h  |2 ++
  drivers/gpu/drm/i915/intel_hdmi.c |   43 +
  3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
  }

-static int g4x_digital_port_connected(struct drm_device *dev,
-  struct intel_digital_port 
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+  struct intel_digital_port *intel_dig_port)
  {
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
  void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
  void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+  struct intel_digital_port *intel_dig_port);

  /* intel_dp_mst.c */
  int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int 
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index c4b82ce..402be54 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,40 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)-detect_edid = NULL;
  }

+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port)
+{
+   u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+   /* TODO: Add bxt A0/A1 wa related to hpd pin swap */


This doesn't seem to work on my BXT A1 RVP. For me GEN8_DE_PORT_ISR
reads all 0 even while an HDMI monitor is plugged to port B.

This is really strange, I checked on atleast 3 different A1 boards and 3 
different monitors (also on two different branches) and I see 0x0 as 
0x8 after the HPD swap patch when monitor is connected and it is 0 when 
no hdmi monitor is present.

Do you think something to do with the board config?


+   switch (port-port) {
+   case PORT_B:
+   return temp  BXT_DE_PORT_HP_DDIB;
+
+   case PORT_C:
+   return temp  BXT_DE_PORT_HP_DDIC;
+
+   default:
+   return false;
+
+   }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+   struct drm_device *dev = intel_dig_port-base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (IS_VALLEYVIEW(dev))
+   return g4x_digital_port_connected(dev, intel_dig_port);
+   else if (IS_SKYLAKE(dev))
+   return ibx_digital_port_connected(dev_priv, intel_dig_port);
+   else if (IS_BROXTON(dev))
+   return bxt_port_connected(dev_priv, intel_dig_port);
+
+   return true;
+}
+
  static bool
  intel_hdmi_set_edid(struct drm_connector *connector)
  {
@@ -1308,15 +1342,16 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_encoder *intel_encoder =
hdmi_to_dig_port(intel_hdmi)-base;
enum intel_display_power_domain power_domain;
-   struct edid *edid;
+   struct edid *edid = NULL;
bool connected = false;

power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);

-   edid = drm_get_edid(connector,
-   intel_gmbus_get_adapter(dev_priv,
-   intel_hdmi-ddc_bus));
+   if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+   edid = drm_get_edid(connector,
+   intel_gmbus_get_adapter(dev_priv,
+   intel_hdmi-ddc_bus));

intel_display_power_put(dev_priv, power_domain);





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect

2015-07-13 Thread Jindal, Sonika




On 7/13/2015 5:10 PM, Chris Wilson wrote:

On Mon, Jul 13, 2015 at 04:19:15PM +0530, Sonika Jindal wrote:

During init_connector set the edid, then edid will be set/unset only during
hotplug. For the sake of older platforms where HPD is not stable, let edid
read happen from detect as well only if it is forced to do so.

v2: Removing the 'force' check, instead let detect call read the edid for
platforms older than gen 7 (Shashank)


That's enough worse. We now have a random gen check with no rationale
for why you suddenly believe all manufacturers have fixed their wiring.
There is no reason to believe that gen7 suddenly works is there? If
there is, why don't you mention it?
-Chris


This gen7 check is to be on the safer side not to affect older paltforms.
For CHV/VLV, already the live status check is stable enough to determine 
if we can read edid or not. In VPG production branches we have this 
patch already available and it was tested with variety of monitors 
extensively. So we now read the edid only during init and during hotplug.
For SKL, the [PATCH] drm/i915: Handle HPD when it has actually 
occurred patch makes HPD stable enough.
So, we can rely on the edid read from init_connector instead of reading 
edid on every detect call.


Regards,
Sonika

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check live status before reading edid

2015-07-13 Thread Jindal, Sonika




On 7/13/2015 8:25 PM, Daniel Vetter wrote:

On Mon, Jul 13, 2015 at 04:35:00PM +0530, Sonika Jindal wrote:

Adding this for SKL onwards.

v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c   |4 ++--
  drivers/gpu/drm/i915/intel_drv.h  |2 ++
  drivers/gpu/drm/i915/intel_hdmi.c |   42 +
  3 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
  }

-static int g4x_digital_port_connected(struct drm_device *dev,
-  struct intel_digital_port 
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+  struct intel_digital_port *intel_dig_port)
  {
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
  void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
  void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+  struct intel_digital_port *intel_dig_port);

  /* intel_dp_mst.c */
  int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int 
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1fb6919..7eb0d0e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,39 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)-detect_edid = NULL;
  }

+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+  struct intel_digital_port *port)
+{
+   u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+   switch (port-port) {
+   case PORT_B:
+   return temp  BXT_DE_PORT_HP_DDIB;
+
+   case PORT_C:
+   return temp  BXT_DE_PORT_HP_DDIC;
+
+   default:
+   return false;
+
+   }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+   struct drm_device *dev = intel_dig_port-base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (IS_VALLEYVIEW(dev))
+   return g4x_digital_port_connected(dev, intel_dig_port);
+   else if (IS_SKYLAKE(dev))
+   return ibx_digital_port_connected(dev_priv, intel_dig_port);
+   else if (IS_BROXTON(dev))
+   return bxt_port_connected(dev_priv, intel_dig_port);


Really I want this to be rolled out for all platforms, together with the
fix for handling hpd interrupts. Together with a reference to the old
commits we had to revert because it didn't work.

I want to test this on my ivb (since that's the machine where I can
readily reproduce this bug), and if it still doesn't work there I won't
take this.
-Daniel
Is there a formal process to raise a test for hpd on all platforms which 
might be affected by this?


Regards,
Sonika




___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping

2015-07-13 Thread Jindal, Sonika




On 7/13/2015 12:01 PM, Sivakumar Thulasimani wrote:



On 7/13/2015 9:47 AM, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.

v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/i915_irq.c |   38
+-
  1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index eb52a03..760539c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,11 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
  [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
  };
-/* BXT hpd list */
+/* Port C is not connected on bxt A0/A1 */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+[HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
  static const u32 hpd_bxt[HPD_NUM_PINS] = {
  [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
  [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -2257,6 +2261,7 @@ static void bxt_hpd_handler(struct drm_device
*dev, uint32_t iir_status)
  struct drm_i915_private *dev_priv = dev-dev_private;
  u32 hp_control, hp_trigger;
  u32 pin_mask, long_mask;
+const u32 *hpd;
  /* Get the status */
  hp_trigger = iir_status  BXT_DE_PORT_HOTPLUG_MASK;
@@ -2271,7 +2276,12 @@ static void bxt_hpd_handler(struct drm_device
*dev, uint32_t iir_status)
  /* Clear sticky bits in hpd status */
  I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
-pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control,
hpd_bxt);
+if (INTEL_REVID(dev)  BXT_REVID_B0)
+hpd = hpd_bxt_a0;
+else
+hpd = hpd_bxt;
+
+pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control,
hpd);
  intel_hpd_irq_handler(dev, pin_mask, long_mask);
  }
@@ -3315,8 +3325,15 @@ static void bxt_hpd_irq_setup(struct drm_device
*dev)
  /* Now, enable HPD */
  for_each_intel_encoder(dev, intel_encoder) {
  if (dev_priv-hotplug.stats[intel_encoder-hpd_pin].state
-== HPD_ENABLED)
-hotplug_port |= hpd_bxt[intel_encoder-hpd_pin];
+== HPD_ENABLED) {
+const u32 *hpd;
+
+if (INTEL_REVID(dev)  BXT_REVID_B0)
+hpd = hpd_bxt_a0;
+else
+hpd = hpd_bxt;
+hotplug_port |= hpd[intel_encoder-hpd_pin];
+}
  }

hpd initialization can be moved out so it is done once instead of being
repeated for each encoder.

Sure.




  /* Mask all HPD control bits */
@@ -3324,11 +3341,14 @@ static void bxt_hpd_irq_setup(struct
drm_device *dev)
  /* Enable requested port in hotplug control */
  /* TODO: implement (short) HPD support on port A */
-WARN_ON_ONCE(hotplug_port  BXT_DE_PORT_HP_DDIA);
-if (hotplug_port  BXT_DE_PORT_HP_DDIB)
-hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
-if (hotplug_port  BXT_DE_PORT_HP_DDIC)
-hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+if (INTEL_REVID(dev)  BXT_REVID_B0  (hotplug_port 
BXT_DE_PORT_HP_DDIA))
+hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;

can you add a comment here stating the swap in hpd pins ?
as i am not sure not everyone will first check the commit message for
the change here.

Ok, I'l add


+else {
+if (hotplug_port  BXT_DE_PORT_HP_DDIB)
+hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+if (hotplug_port  BXT_DE_PORT_HP_DDIC)
+hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+}
  I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
  /* Unmask DDI hotplug in IMR */






___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid

2015-07-09 Thread Jindal, Sonika




On 7/9/2015 10:57 PM, Daniel Vetter wrote:

On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote:

Adding this for SKL onwards.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com


I think this is the critical piece really, and I'd like to roll it out for
all platforms. git has the code for all the old ones, so no big deal to
digg that out. Also we need your fix for the interrupt handling first ofc,
otherwise this won't work.

We have tested this with VLV/CHV too, and it works fine. I'l add those 
platforms also in the next version of this patch and change the gen 
check in the next patch as well.



Then we can apply this and give it some good testing before we start
relying on it with caching hdmi probe status. I know this means that
things will be slower, but I've been burned a bit too much the last few
times we've tried this. And I really think we need the most amount of
testing we can get (hence rolling this out for all platforms). If your
hpd irq handling bugfix is indeed the bug that will be confirmed quickly,
otherwise it means back to debugging.


---
  drivers/gpu/drm/i915/intel_hdmi.c |   49 ++---
  1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1fb6919..769cf4f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,46 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)-detect_edid = NULL;
  }

+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+   struct drm_device *dev = intel_dig_port-base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum port port = intel_dig_port-port;
+
+   if (IS_SKYLAKE(dev)) {
+   u32 temp = I915_READ(SDEISR);
+
+   switch (port) {
+   case PORT_B:
+   return temp  SDE_PORTB_HOTPLUG_CPT;
+
+   case PORT_C:
+   return temp  SDE_PORTC_HOTPLUG_CPT;
+
+   case PORT_D:
+   return temp  SDE_PORTD_HOTPLUG_CPT;
+
+   default:
+   return false;
+   }


The old code had per-platform helper functions for this instead of a big
if-ladder. I think that would look better.

Hmm, I see g4x_digital_port_connected and ibx_digital_port_connected 
which already checks for these bits. We can reuse that here instead.

I'l send the next version.

Thanks,
Sonika


Also when you digg out these old versions please also cite the commit sha1
of the patches where we had to last revert this (and explain why it's now
save).
-Daniel


+   } else if (IS_BROXTON(dev)) {
+   u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+   switch (port) {
+   case PORT_B:
+   return temp  BXT_DE_PORT_HP_DDIB;
+
+   case PORT_C:
+   return temp  BXT_DE_PORT_HP_DDIC;
+
+   default:
+   return false;
+
+   }
+   }
+   return true;
+}
+
  static bool
  intel_hdmi_set_edid(struct drm_connector *connector)
  {
@@ -1308,15 +1348,16 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_encoder *intel_encoder =
hdmi_to_dig_port(intel_hdmi)-base;
enum intel_display_power_domain power_domain;
-   struct edid *edid;
+   struct edid *edid = NULL;
bool connected = false;

power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);

-   edid = drm_get_edid(connector,
-   intel_gmbus_get_adapter(dev_priv,
-   intel_hdmi-ddc_bus));
+   if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+   edid = drm_get_edid(connector,
+   intel_gmbus_get_adapter(dev_priv,
+   intel_hdmi-ddc_bus));

intel_display_power_put(dev_priv, power_domain);

--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Handle HPD when it has actually occurred

2015-07-07 Thread Jindal, Sonika




On 7/7/2015 6:51 PM, Ville Syrjälä wrote:

On Tue, Jul 07, 2015 at 02:22:20PM +0530, Sonika Jindal wrote:

Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.
v2: Make few variables local to if block (Ville)
v3: Add check for ibx/cpt both (Ville).
 While at it, remove the redundant check for hotplug_trigger from
 pch_get_hpd_pins

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/i915_irq.c |   32 +---
  1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..ba2c27c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1266,9 +1266,6 @@ static void pch_get_hpd_pins(u32 *pin_mask, u32 
*long_mask,
*pin_mask = 0;
*long_mask = 0;

-   if (!hotplug_trigger)
-   return;
-


Looks like BXT still depends on that. So you should change that too,
or leave this in until someone else does it.
No, for bxt, this function is called from bxt_hpd_handler which is 
called only when tmp  BXT_DE_PORT_HOTPLUG_MASK is non-zero.

So, it this is fine for bxt.




for_each_hpd_pin(i) {
if ((hpd[i]  hotplug_trigger) == 0)
continue;
@@ -1658,14 +1655,17 @@ static void ibx_irq_handler(struct drm_device *dev, u32 
pch_iir)
struct drm_i915_private *dev_priv = dev-dev_private;
int pipe;
u32 hotplug_trigger = pch_iir  SDE_HOTPLUG_MASK;
-   u32 dig_hotplug_reg;
-   u32 pin_mask, long_mask;

-   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
-   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+   if (hotplug_trigger) {
+   u32 dig_hotplug_reg, pin_mask, long_mask;

-   pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, 
dig_hotplug_reg, hpd_ibx);
-   intel_hpd_irq_handler(dev, pin_mask, long_mask);
+   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
+   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+
+   pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+   dig_hotplug_reg, hpd_ibx);


Indentation is fubar.

This was to avoid 80 char limit.



+   intel_hpd_irq_handler(dev, pin_mask, long_mask);
+   }

if (pch_iir  SDE_AUDIO_POWER_MASK) {
int port = ffs((pch_iir  SDE_AUDIO_POWER_MASK) 
@@ -1757,14 +1757,16 @@ static void cpt_irq_handler(struct drm_device *dev, u32 
pch_iir)
struct drm_i915_private *dev_priv = dev-dev_private;
int pipe;
u32 hotplug_trigger = pch_iir  SDE_HOTPLUG_MASK_CPT;
-   u32 dig_hotplug_reg;
-   u32 pin_mask, long_mask;

-   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
-   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+   if (hotplug_trigger) {
+   u32 dig_hotplug_reg, pin_mask, long_mask;

-   pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, 
dig_hotplug_reg, hpd_cpt);
-   intel_hpd_irq_handler(dev, pin_mask, long_mask);
+   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
+   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+   pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+   dig_hotplug_reg, hpd_cpt);


Ditto


This was to avoid 80 char limit.


With those fixed this is
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com


+   intel_hpd_irq_handler(dev, pin_mask, long_mask);
+   }

if (pch_iir  SDE_AUDIO_POWER_MASK_CPT) {
int port = ffs((pch_iir  SDE_AUDIO_POWER_MASK_CPT) 
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] drm/i915: Handle HPD when it has actually occurred

2015-07-06 Thread Jindal, Sonika




On 7/6/2015 2:06 PM, Daniel Vetter wrote:

On Mon, Jul 06, 2015 at 11:23:53AM +0530, Sonika Jindal wrote:

Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
Hi,

I see we don't check for hotplug_trigger before processing the HPD for any of 
the platform. Is there any reason for this?
For SKL, if I let write to PCH_PORT_HOTPLUG happen for all interrupts, somehow 
this register gets an invalid value at one point and it zeroes it out.
If I put this check before handling HPD, hotplug behaves fine.
Please let me know if you see any issue with this approach.


Nice find, this sounds really intrigueing, at least for cpt/ibx platforms.
I'm not sure whether what will happen with atom/i9xx platforms though
since the irq bits are different there. But at least bxt has a FIXME
comment that suggest we do need to save the sticky bits on those platforms
too.

If we can fix this up for all platforms then I think a subsequent patch
could try to re-enable the hpd checks in the hdmi -detect function and
make use spec compliant. Then after maybe 1-2 kernel releases of testing
we'll know whether it really works.

But I'd really want to enable this everywhere just to have maximal test
coverage - we did have reports on all platforms so it seems a generic
issue.

I think only cpt/ibx suffer from this. Bxt already set port_hotplug_stat 
only when hpd occurs.
Is there a process to get this checked on all platforms, which the fix I 
suggested?

I can only test on SKL as of now.

Regards,
Sonika

Thanks, Daniel



Thanks,
Sonika

  drivers/gpu/drm/i915/i915_irq.c |   11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..2d47372 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1760,11 +1760,12 @@ static void cpt_irq_handler(struct drm_device *dev, u32 
pch_iir)
u32 dig_hotplug_reg;
u32 pin_mask, long_mask;

-   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
-   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
-
-   pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, 
dig_hotplug_reg, hpd_cpt);
-   intel_hpd_irq_handler(dev, pin_mask, long_mask);
+   if (hotplug_trigger) {
+   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
+   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+   pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, 
dig_hotplug_reg, hpd_cpt);
+   intel_hpd_irq_handler(dev, pin_mask, long_mask);
+   }

if (pch_iir  SDE_AUDIO_POWER_MASK_CPT) {
int port = ffs((pch_iir  SDE_AUDIO_POWER_MASK_CPT) 
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] drm/i915: Handle HPD when it has actually occurred

2015-07-06 Thread Jindal, Sonika




On 7/6/2015 2:19 PM, Ville Syrjälä wrote:

On Mon, Jul 06, 2015 at 11:23:53AM +0530, Sonika Jindal wrote:

Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
Hi,

I see we don't check for hotplug_trigger before processing the HPD for any of 
the platform. Is there any reason for this?
For SKL, if I let write to PCH_PORT_HOTPLUG happen for all interrupts, somehow 
this register gets an invalid value at one point and it zeroes it out.
If I put this check before handling HPD, hotplug behaves fine.
Please let me know if you see any issue with this approach.

Thanks,
Sonika

  drivers/gpu/drm/i915/i915_irq.c |   11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..2d47372 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1760,11 +1760,12 @@ static void cpt_irq_handler(struct drm_device *dev, u32 
pch_iir)
u32 dig_hotplug_reg;
u32 pin_mask, long_mask;

-   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
-   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
-
-   pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, 
dig_hotplug_reg, hpd_cpt);
-   intel_hpd_irq_handler(dev, pin_mask, long_mask);
+   if (hotplug_trigger) {
+   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
+   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+   pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, 
dig_hotplug_reg, hpd_cpt);
+   intel_hpd_irq_handler(dev, pin_mask, long_mask);
+   }


Deja vu. I think I have the same patch (also for IBX) in my stalled
(and never posted) port A HPD branch. So yeah, I think this
makes sense.

You can also move the dig_hotplug_reg, pin_mask, and long_mask declarations
into the if block since they're not needed elsewhere.

Sure. Do you think I should add this for ibx as well?






if (pch_iir  SDE_AUDIO_POWER_MASK_CPT) {
int port = ffs((pch_iir  SDE_AUDIO_POWER_MASK_CPT) 
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Read HDMI EDID only when required

2015-07-06 Thread Jindal, Sonika




On 7/6/2015 1:08 PM, Daniel Vetter wrote:

On Thu, Jul 02, 2015 at 08:24:12AM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 7/1/2015 6:26 PM, Daniel Vetter wrote:

On Tue, Jun 30, 2015 at 09:49:57PM +0530, Shashank Sharma wrote:

Userspace always sets force. Are you sure this actually improves anything?

Yes we do. We have had this code for commercial projects, and that's really
  important to have proper interrupt handling as well as to avoid race
condition between multiple HDMI detects from interrupt handler and
userspace detect calls. This is a must for HDMI compliance also.


There's no race, we have locks for this. And we already have a little bit
of edid caching, and you're code won't add more caching for the force =
true case. Which is why I wondered whether you've really seen improvements
with this on latest upstream, and not just an older android tree.

This caching is not useful, as in every detect call, we are doing a unset
EDID, and doing a set EDID again. The actual reason behind multiple HDMI
EDID reads is detect() getting called from user space only.So every time
there is a detect call, there is HDMI EDID read.

We should read EDID only on hotplug, cache it, and reuse it until hot
unplug.


But that's not what your patch is doing. You drop the cache when force is
set in -detect, which is always the case when called on userspace's
behalf. That's why I wondered whether you've managed to measure any real
improvement here.


Actually the plan is to use this force for GEN  6 HW only, where the
hotplug doesn't work reliably (I remember our last conversation on some old
HW which doesn't support HPD properly). For vlv+, we can (will) use only
the cached EDID.


Ok, once more: HDMI hpd is unreliable everywhere. I have a gen7 here which
is half-busted it seems, and we've found examples for every single
platform that supports hdmi out there. The problem isn't necessarily spec
compliant HDMI sinks, but all the other crap ppl like to plug in.

Yes this means we'll not be spec compliant, but if we have reality vs.
spec, reality wins. At least in upstream.


We have tested HPD with several HDMI monitors for VLV, CHV SKL and now for
BXT also. We are getting reliable hotplugs and unplugs across these
platforms, with accurate information on long/short pulses. Can you please
give some details about what is your observation ?

Its very important for the Android projects to comply with the spec due to
certification pressure from customers. And we can get a common path for us,
if we know what exactly is the problem. But for sure we cant ignore this
factor that compliance is essential.


Well we've tried this a few years back and had to revert on all machines
because somehow hdp signalling isn't reliable. It might have been trouble
with non-spec compliant sinks, but people where still annoyed about them
no longer working.

And I have a HP LP2475w here which is affected it seems: When unpluggint
the hpd irq sometimes doesn't happen. And yes this is with a hdmi sink
connector, not some hdmi-dvi cable or some other horror show. Last time I
looked at it the hpd status bits where also unreliable (i.e. hpd indicated
disconnected when the screen was clearly connected and working). Another
hdmi screen I have here works. So yeah it's a sink problem, it's probably
shitty/broken hw, but it means that it's completely independant of the
platform.

I see this problem with SKL HPD also.. and I figured out writing again 
and again to the port_hpd_hotplug stat somehow screws the state of hotplug.
Currently we update to that reg for any interrupt. After putting a check 
to write to that reg only if a real hpd is triggered, it works good.

Please check:
[PATCH] [RFC] drm/i915: Handle HPD when it has actually occurred


This means we _have_ to be spec incompliant to make real world hw word,
and for upstream real world hw always beats specs. Which means I really
can't merge any patch which assumes that hdmi hpd works. Or we figure out
what has been broken with these screens and try to re-enable, but then we
need to try this on every platfrom we support hdmi on since it's a clearly
a sink problem.


Also the goal should be to keep things cache for a few calls from
userspace (since often it pokes a few times in a row unfortuantely), for
which we need a proper timeout to clear the edid again.


Can you please let us know why ? Why do we need to clear this EDID caching
? We should clear it only in the next hot-unplug, and maintain this cached
EDID for all userspace detect operations. I believe as long as we have the
state machine maintained, we need not to clear it.


hotplug is not reliable, at least not outside of labs and validation
testers. And your code here throws the cached edid away every time force =
true is set, which is pretty much always. At least on upstream.

The only place where we don't set force is in the poll worker, and that's
only run when we have a hpd storm.
-Daniel

The new code doesn't throw away cached

Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: BUNs related to port PLL

2015-07-01 Thread Jindal, Sonika

Looks good to me..
Reviewed-by: Sonika Jindal sonika.jin...@intel.com

-Original Message-
From: Kannan, Vandana 
Sent: Wednesday, July 1, 2015 11:04 AM
To: intel-gfx@lists.freedesktop.org
Cc: Thulasimani, Sivakumar; Jindal, Sonika; Deak, Imre; Kannan, Vandana
Subject: [PATCH v2] drm/i915/bxt: BUNs related to port PLL

This patch contains changes based on 2 updates to the spec:
Port PLL VCO restriction raised up to 6700.
Port PLL now needs DCO amp override enable for all VCO frequencies.

v2: Sonika's review comment addressed
- dcoampovr_en_h variable not required
Based on a discussion with Siva, the following changes have been made.
- replace dco_amp var with #define BXT_DCO_AMPLITUDE
- set pll10 in a single assignment

Signed-off-by: Vandana Kannan vandana.kan...@intel.com
---
 drivers/gpu/drm/i915/intel_ddi.c | 16 ++--
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 42c1487..1eadc14 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1445,6 +1445,8 @@ static const struct bxt_clk_div bxt_dp_clk_val[] = {
{432000, 3, 1, 32, 1677722, 1, 1}
 };
 
+#define BXT_DCO_AMPLITUDE  15
+
 static bool
 bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
   struct intel_crtc_state *crtc_state, @@ -1455,7 +1457,7 @@ 
bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
struct bxt_clk_div clk_div = {0};
int vco = 0;
uint32_t prop_coef, int_coef, gain_ctl, targ_cnt;
-   uint32_t dcoampovr_en_h, dco_amp, lanestagger;
+   uint32_t lanestagger;
 
if (intel_encoder-type == INTEL_OUTPUT_HDMI) {
intel_clock_t best_clock;
@@ -1494,9 +1496,7 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
vco = clock * 10 / 2 * clk_div.p1 * clk_div.p2;
}
 
-   dco_amp = 15;
-   dcoampovr_en_h = 0;
-   if (vco = 620  vco = 648) {
+   if (vco = 620  vco = 670) {
prop_coef = 4;
int_coef = 9;
gain_ctl = 3;
@@ -1507,8 +1507,6 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
int_coef = 11;
gain_ctl = 3;
targ_cnt = 9;
-   if (vco = 480  vco  540)
-   dcoampovr_en_h = 1;
} else if (vco == 540) {
prop_coef = 3;
int_coef = 8;
@@ -1550,10 +1548,8 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
 
crtc_state-dpll_hw_state.pll8 = targ_cnt;
 
-   if (dcoampovr_en_h)
-   crtc_state-dpll_hw_state.pll10 = PORT_PLL_DCO_AMP_OVR_EN_H;
-
-   crtc_state-dpll_hw_state.pll10 |= PORT_PLL_DCO_AMP(dco_amp);
+   crtc_state-dpll_hw_state.pll10 = PORT_PLL_DCO_AMP(BXT_DCO_AMPLITUDE)
+   | PORT_PLL_DCO_AMP_OVR_EN_H;
 
crtc_state-dpll_hw_state.pcsdw12 =
LANESTAGGER_STRAP_OVRD | lanestagger; diff --git 
a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index eb665d7..e04be45 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -409,7 +409,7 @@ static const intel_limit_t intel_limits_chv = {  static 
const intel_limit_t intel_limits_bxt = {
/* FIXME: find real dot limits */
.dot = { .min = 0, .max = INT_MAX },
-   .vco = { .min = 480, .max = 648 },
+   .vco = { .min = 480, .max = 670 },
.n = { .min = 1, .max = 1 },
.m1 = { .min = 2, .max = 2 },
/* FIXME: find real m2 limits */
--
2.0.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Calculate port clock

2015-06-30 Thread Jindal, Sonika

I think Imre already has a patch for this:
[Intel-gfx] [PATCH v2 5/5] drm/i915/bxt: add DDI port HW readoutsupport


-Original Message-
From: Kannan, Vandana 
Sent: Tuesday, June 30, 2015 1:27 PM
To: intel-gfx@lists.freedesktop.org
Cc: Thulasimani, Sivakumar; Jindal, Sonika; Deak, Imre; Kannan, Vandana
Subject: [PATCH] drm/i915/bxt: Calculate port clock

bxt_calc_pll_link() has been returning 0 all this while.
This patch adds calculation in bxt_calc_pll_link() based on the chv calculation 
used in bxt_find_best_dpll().

Signed-off-by: Vandana Kannan vandana.kan...@intel.com
---
 drivers/gpu/drm/i915/i915_reg.h  |  2 ++  drivers/gpu/drm/i915/intel_ddi.c | 
38 --
 2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h 
index ac985c5..1d9c5dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1171,8 +1171,10 @@ enum skl_disp_power_wells {
 #define _PORT_PLL_EBB_0_B  0x6C034
 #define _PORT_PLL_EBB_0_C  0x6C340
 #define   PORT_PLL_P1_MASK (0x07  13)
+#define   PORT_PLL_P1_SHIFT13
 #define   PORT_PLL_P1(x)   ((x)   13)
 #define   PORT_PLL_P2_MASK (0x1f  8)
+#define   PORT_PLL_P2_SHIFT8
 #define   PORT_PLL_P2(x)   ((x)   8)
 #define BXT_PORT_PLL_EBB_0(port)   _PORT3(port, _PORT_PLL_EBB_0_A, \
_PORT_PLL_EBB_0_B,  \
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 42c1487..a8fbcc6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -968,8 +968,42 @@ static void hsw_ddi_clock_get(struct intel_encoder 
*encoder,  static int bxt_calc_pll_link(struct drm_i915_private *dev_priv,
enum intel_dpll_id dpll)
 {
-   /* FIXME formula not available in bspec */
-   return 0;
+   enum port port = (enum port)dpll;   /* 1:1 port-PLL mapping */
+   uint32_t ebb0, pll0, pll2;
+   uint32_t m2_int, m2_frac;
+   intel_clock_t clock;
+   int refclk = 10;
+
+   /*
+* FIXME:
+* The below calculation needs to be revisited if/when
+* the calculation in bxt_find_best_dpll() changes.
+*/
+   clock.n = 1;
+   clock.m1 = 2;
+
+   ebb0 = I915_READ(BXT_PORT_PLL_EBB_0(port));
+   clock.p1 = (ebb0  PORT_PLL_P1_MASK)  PORT_PLL_P1_SHIFT;
+   clock.p2 = (ebb0  PORT_PLL_P2_MASK)  PORT_PLL_P2_SHIFT;
+
+   pll0 = I915_READ(BXT_PORT_PLL(port, 0));
+   m2_int = (pll0  PORT_PLL_M2_MASK)  22;
+
+   pll2 = I915_READ(BXT_PORT_PLL(port, 2));
+   m2_frac = (pll2  PORT_PLL_M2_FRAC_MASK);
+
+   clock.m2 = m2_int | m2_frac;
+
+   clock.m = clock.m1 * clock.m2;
+   clock.p = clock.p1 * clock.p2;
+   if (WARN_ON(clock.n == 0 || clock.p == 0))
+   return 0;
+
+   clock.vco = DIV_ROUND_CLOSEST_ULL((uint64_t)refclk * clock.m,
+   clock.n  22);
+   clock.dot = DIV_ROUND_CLOSEST(clock.vco, clock.p);
+
+   return (clock.dot / 5);
 }
 
 static void bxt_ddi_clock_get(struct intel_encoder *encoder,
--
2.0.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: BUNs related to port PLL

2015-06-30 Thread Jindal, Sonika




On 7/1/2015 10:06 AM, Vandana Kannan wrote:

This patch contains changes based on 2 updates to the spec:
Port PLL VCO restriction raised up to 6700.
Port PLL now needs DCO amp override enable for all VCO frequencies.

Signed-off-by: Vandana Kannan vandana.kan...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c | 7 +++
  drivers/gpu/drm/i915/intel_display.c | 2 +-
  2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 42c1487..677096d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1495,8 +1495,8 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
}

dco_amp = 15;
-   dcoampovr_en_h = 0;
-   if (vco = 620  vco = 648) {
+   dcoampovr_en_h = 1;

You dont need this variable now..


+   if (vco = 620  vco = 670) {
prop_coef = 4;
int_coef = 9;
gain_ctl = 3;
@@ -1550,8 +1550,7 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,

crtc_state-dpll_hw_state.pll8 = targ_cnt;

-   if (dcoampovr_en_h)
-   crtc_state-dpll_hw_state.pll10 = PORT_PLL_DCO_AMP_OVR_EN_H;
+   crtc_state-dpll_hw_state.pll10 = PORT_PLL_DCO_AMP_OVR_EN_H;

crtc_state-dpll_hw_state.pll10 |= PORT_PLL_DCO_AMP(dco_amp);

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index eb665d7..e04be45 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -409,7 +409,7 @@ static const intel_limit_t intel_limits_chv = {
  static const intel_limit_t intel_limits_bxt = {
/* FIXME: find real dot limits */
.dot = { .min = 0, .max = INT_MAX },
-   .vco = { .min = 480, .max = 648 },
+   .vco = { .min = 480, .max = 670 },
.n = { .min = 1, .max = 1 },
.m1 = { .min = 2, .max = 2 },
/* FIXME: find real m2 limits */


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/vlv: move the vlv PLL helper next to its platform counterparts

2015-06-29 Thread Jindal, Sonika


Reviewed-by: Sonika Jindal sonika.jin...@intel.com

On 6/23/2015 2:05 AM, Imre Deak wrote:

Move the helper next to the PLL helpers of the other platforms for
clarity.

No functional change.

Signed-off-by: Imre Deak imre.d...@intel.com
---
  drivers/gpu/drm/i915/intel_display.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b030ce4..fb7fd5f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -418,16 +418,6 @@ static const intel_limit_t intel_limits_bxt = {
.p2 = { .p2_slow = 1, .p2_fast = 20 },
  };

-static void vlv_clock(int refclk, intel_clock_t *clock)
-{
-   clock-m = clock-m1 * clock-m2;
-   clock-p = clock-p1 * clock-p2;
-   if (WARN_ON(clock-n == 0 || clock-p == 0))
-   return;
-   clock-vco = DIV_ROUND_CLOSEST(refclk * clock-m, clock-n);
-   clock-dot = DIV_ROUND_CLOSEST(clock-vco, clock-p);
-}
-
  static bool
  needs_modeset(struct drm_crtc_state *state)
  {
@@ -589,6 +579,16 @@ static void i9xx_clock(int refclk, intel_clock_t *clock)
clock-dot = DIV_ROUND_CLOSEST(clock-vco, clock-p);
  }

+static void vlv_clock(int refclk, intel_clock_t *clock)
+{
+   clock-m = clock-m1 * clock-m2;
+   clock-p = clock-p1 * clock-p2;
+   if (WARN_ON(clock-n == 0 || clock-p == 0))
+   return;
+   clock-vco = DIV_ROUND_CLOSEST(refclk * clock-m, clock-n);
+   clock-dot = DIV_ROUND_CLOSEST(clock-vco, clock-p);
+}
+
  static void chv_clock(int refclk, intel_clock_t *clock)
  {
clock-m = clock-m1 * clock-m2;


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915/vlv: factor out vlv_calc_port_clock

2015-06-24 Thread Jindal, Sonika




On 6/18/2015 7:55 PM, Imre Deak wrote:

This functionality will be needed by the next patch adding HW readout
support for DDI ports on BXT, so factor it out.

No functional change.

Signed-off-by: Imre Deak imre.d...@intel.com
---
  drivers/gpu/drm/i915/intel_display.c | 18 ++
  drivers/gpu/drm/i915/intel_drv.h |  2 ++
  2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0e5c613..6cf2a15 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7993,6 +7993,14 @@ static void i9xx_get_pfit_config(struct intel_crtc *crtc,
I915_READ(LVDS)  LVDS_BORDER_ENABLE;
  }

+int vlv_calc_port_clock(int refclk, intel_clock_t *pll_clock)
+{
+   chv_clock(refclk, pll_clock);

Is vlv_clock function same as chv_clock ?
I see one clock-n  22 in chv_clock which is not there in vlv_clock.


+
+   /* clock.dot is the fast clock */
+   return pll_clock-dot / 5;
+}
+
  static void vlv_crtc_clock_get(struct intel_crtc *crtc,
   struct intel_crtc_state *pipe_config)
  {
@@ -8017,10 +8025,7 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
clock.p1 = (mdiv  DPIO_P1_SHIFT)  7;
clock.p2 = (mdiv  DPIO_P2_SHIFT)  0x1f;

-   vlv_clock(refclk, clock);
-
-   /* clock.dot is the fast clock */
-   pipe_config-port_clock = clock.dot / 5;
+   pipe_config-port_clock = vlv_calc_port_clock(refclk, clock);
  }

  static void
@@ -8116,10 +8121,7 @@ static void chv_crtc_clock_get(struct intel_crtc *crtc,
clock.p1 = (cmn_dw13  DPIO_CHV_P1_DIV_SHIFT)  0x7;
clock.p2 = (cmn_dw13  DPIO_CHV_P2_DIV_SHIFT)  0x1f;

-   chv_clock(refclk, clock);
-
-   /* clock.dot is the fast clock */
-   pipe_config-port_clock = clock.dot / 5;
+   pipe_config-port_clock = vlv_calc_port_clock(refclk, clock);
  }

  static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bcafefc..95e14bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1139,6 +1139,8 @@ ironlake_check_encoder_dotclock(const struct 
intel_crtc_state *pipe_config,
int dotclock);
  bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state, int target_clock,
intel_clock_t *best_clock);
+int vlv_calc_port_clock(int refclk, intel_clock_t *pll_clock);
+
  bool intel_crtc_active(struct drm_crtc *crtc);
  void hsw_enable_ips(struct intel_crtc *crtc);
  void hsw_disable_ips(struct intel_crtc *crtc);


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915/bxt: add missing DDI PLL registers to the state checking

2015-06-24 Thread Jindal, Sonika




On 6/18/2015 7:55 PM, Imre Deak wrote:

Although we have a fixed setting for the PLL9 and EBB4 registers, it
still makes sense to check them together with the rest of PLL registers.

While at it also remove a redundant comment about 10 bit clock enabling.

Signed-off-by: Imre Deak imre.d...@intel.com
---
  drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
  drivers/gpu/drm/i915/i915_reg.h  |  3 ++-
  drivers/gpu/drm/i915/intel_ddi.c | 16 +---
  drivers/gpu/drm/i915/intel_display.c |  6 --
  4 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 491ef0c..bf235ff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -366,7 +366,8 @@ struct intel_dpll_hw_state {
uint32_t cfgcr1, cfgcr2;

/* bxt */
-   uint32_t ebb0, pll0, pll1, pll2, pll3, pll6, pll8, pll10, pcsdw12;
+   uint32_t ebb0, ebb4, pll0, pll1, pll2, pll3, pll6, pll8, pll9, pll10,
+pcsdw12;
  };

  struct intel_shared_dpll_config {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4bbc85a..bba0691 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1207,7 +1207,8 @@ enum skl_disp_power_wells {
  /* PORT_PLL_8_A */
  #define   PORT_PLL_TARGET_CNT_MASK0x3FF
  /* PORT_PLL_9_A */
-#define  PORT_PLL_LOCK_THRESHOLD_MASK  0xe
+#define  PORT_PLL_LOCK_THRESHOLD_SHIFT 1
+#define  PORT_PLL_LOCK_THRESHOLD_MASK  (0x7  PORT_PLL_LOCK_THRESHOLD_SHIFT)
  /* PORT_PLL_10_A */
  #define  PORT_PLL_DCO_AMP_OVR_EN_H(127)
  #define  PORT_PLL_DCO_AMP_MASK0x3c00
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index bdc5677..ca970ba 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1476,11 +1476,15 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,

crtc_state-dpll_hw_state.pll8 = targ_cnt;

+   crtc_state-dpll_hw_state.pll9 = 5  PORT_PLL_LOCK_THRESHOLD_SHIFT;
+
if (dcoampovr_en_h)
crtc_state-dpll_hw_state.pll10 = PORT_PLL_DCO_AMP_OVR_EN_H;

crtc_state-dpll_hw_state.pll10 |= PORT_PLL_DCO_AMP(dco_amp);

+   crtc_state-dpll_hw_state.ebb4 = PORT_PLL_10BIT_CLK_ENABLE;
You can add  | PORT_PLL_RECALIBRATE and check for this one as well in 
bxt_ddi_pll_get_hw_state.



+
crtc_state-dpll_hw_state.pcsdw12 =
LANESTAGGER_STRAP_OVRD | lanestagger;

@@ -2414,7 +2418,7 @@ static void bxt_ddi_pll_enable(struct drm_i915_private 
*dev_priv,

temp = I915_READ(BXT_PORT_PLL(port, 9));
temp = ~PORT_PLL_LOCK_THRESHOLD_MASK;
-   temp |= (5  1);
+   temp |= pll-config.hw_state.pll9;
I915_WRITE(BXT_PORT_PLL(port, 9), temp);

temp = I915_READ(BXT_PORT_PLL(port, 10));
@@ -2427,8 +2431,8 @@ static void bxt_ddi_pll_enable(struct drm_i915_private 
*dev_priv,
temp = I915_READ(BXT_PORT_PLL_EBB_4(port));
temp |= PORT_PLL_RECALIBRATE;
I915_WRITE(BXT_PORT_PLL_EBB_4(port), temp);
-   /* Enable 10 bit clock */
I think it is OK to keep this comment here because all the steps are 
mentioned in comments, even disable 10 bit clock.



-   temp |= PORT_PLL_10BIT_CLK_ENABLE;
+   temp = ~PORT_PLL_10BIT_CLK_ENABLE;
+   temp |= pll-config.hw_state.ebb4;
I915_WRITE(BXT_PORT_PLL_EBB_4(port), temp);

/* Enable PLL */
@@ -2481,6 +2485,9 @@ static bool bxt_ddi_pll_get_hw_state(struct 
drm_i915_private *dev_priv,
hw_state-ebb0 = I915_READ(BXT_PORT_PLL_EBB_0(port));
hw_state-ebb0 = PORT_PLL_P1_MASK | PORT_PLL_P2_MASK;

+   hw_state-ebb4 = I915_READ(BXT_PORT_PLL_EBB_4(port));
+   hw_state-ebb4 = PORT_PLL_10BIT_CLK_ENABLE;
+
hw_state-pll0 = I915_READ(BXT_PORT_PLL(port, 0));
hw_state-pll0 = PORT_PLL_M2_MASK;

@@ -2501,6 +2508,9 @@ static bool bxt_ddi_pll_get_hw_state(struct 
drm_i915_private *dev_priv,
hw_state-pll8 = I915_READ(BXT_PORT_PLL(port, 8));
hw_state-pll8 = PORT_PLL_TARGET_CNT_MASK;

+   hw_state-pll9 = I915_READ(BXT_PORT_PLL(port, 9));
+   hw_state-pll9 = PORT_PLL_LOCK_THRESHOLD_MASK;
+
hw_state-pll10 = I915_READ(BXT_PORT_PLL(port, 10));
hw_state-pll10 = PORT_PLL_DCO_AMP_OVR_EN_H |
   PORT_PLL_DCO_AMP_MASK;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9149410..6f79680 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11905,17 +11905,19 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
DRM_DEBUG_KMS(double wide: %i\n, pipe_config-double_wide);

if (IS_BROXTON(dev)) {
-   DRM_DEBUG_KMS(ddi_pll_sel: %u; dpll_hw_state: ebb0: 0x%x, 
+   DRM_DEBUG_KMS(ddi_pll_sel: %u; dpll_hw_state: ebb0: 0x%x, ebb4: 
0x%x,
  pll0: 0x%x, pll1: 0x%x, pll2: 0x%x,

Re: [Intel-gfx] [PATCH 1/5] drm/i915/bxt: mask off the DPLL state checker bits we don't program

2015-06-24 Thread Jindal, Sonika


Looks good to me.
Reviewed-by: Sonika Jindal sonika.jin...@intel.com

On 6/18/2015 7:55 PM, Imre Deak wrote:

For the purpose of state checking we only care about the DPLL HW flags
that we actually program, so mask off the ones that we don't.

This fixes one set of DPLL state check failures.

Signed-off-by: Imre Deak imre.d...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9ae297a..bdc5677 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2479,13 +2479,32 @@ static bool bxt_ddi_pll_get_hw_state(struct 
drm_i915_private *dev_priv,
return false;

hw_state-ebb0 = I915_READ(BXT_PORT_PLL_EBB_0(port));
+   hw_state-ebb0 = PORT_PLL_P1_MASK | PORT_PLL_P2_MASK;
+
hw_state-pll0 = I915_READ(BXT_PORT_PLL(port, 0));
+   hw_state-pll0 = PORT_PLL_M2_MASK;
+
hw_state-pll1 = I915_READ(BXT_PORT_PLL(port, 1));
+   hw_state-pll1 = PORT_PLL_N_MASK;
+
hw_state-pll2 = I915_READ(BXT_PORT_PLL(port, 2));
+   hw_state-pll2 = PORT_PLL_M2_FRAC_MASK;
+
hw_state-pll3 = I915_READ(BXT_PORT_PLL(port, 3));
+   hw_state-pll3 = PORT_PLL_M2_FRAC_ENABLE;
+
hw_state-pll6 = I915_READ(BXT_PORT_PLL(port, 6));
+   hw_state-pll6 = PORT_PLL_PROP_COEFF_MASK |
+ PORT_PLL_INT_COEFF_MASK |
+ PORT_PLL_GAIN_CTL_MASK;
+
hw_state-pll8 = I915_READ(BXT_PORT_PLL(port, 8));
+   hw_state-pll8 = PORT_PLL_TARGET_CNT_MASK;
+
hw_state-pll10 = I915_READ(BXT_PORT_PLL(port, 10));
+   hw_state-pll10 = PORT_PLL_DCO_AMP_OVR_EN_H |
+  PORT_PLL_DCO_AMP_MASK;
+
/*
 * While we write to the group register to program all lanes at once we
 * can read only lane registers. We configure all lanes the same way, so
@@ -2496,6 +2515,7 @@ static bool bxt_ddi_pll_get_hw_state(struct 
drm_i915_private *dev_priv,
DRM_DEBUG_DRIVER(lane stagger config different for lane 01 (%08x) 
and 23 (%08x)\n,
 hw_state-pcsdw12,
 I915_READ(BXT_PORT_PCS_DW12_LN23(port)));
+   hw_state-pcsdw12 = LANE_STAGGER_MASK | LANESTAGGER_STRAP_OVRD;

return true;
  }


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915/bxt: add PLL10 to the PLL state dumper

2015-06-24 Thread Jindal, Sonika


Looks good to me:
Reviewed-by: Sonika Jindal sonika.jin...@intel.com

On 6/18/2015 7:55 PM, Imre Deak wrote:

Signed-off-by: Imre Deak imre.d...@intel.com
---
  drivers/gpu/drm/i915/intel_display.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6f79680..0e5c613 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11907,7 +11907,7 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
if (IS_BROXTON(dev)) {
DRM_DEBUG_KMS(ddi_pll_sel: %u; dpll_hw_state: ebb0: 0x%x, ebb4: 
0x%x,
  pll0: 0x%x, pll1: 0x%x, pll2: 0x%x, pll3: 0x%x, 
- pll6: 0x%x, pll8: 0x%x, pll9: 0x%x, pcsdw12: 
0x%x\n,
+ pll6: 0x%x, pll8: 0x%x, pll9: 0x%x, pll10: 0x%x, 
pcsdw12: 0x%x\n,
  pipe_config-ddi_pll_sel,
  pipe_config-dpll_hw_state.ebb0,
  pipe_config-dpll_hw_state.ebb4,
@@ -11918,6 +11918,7 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
  pipe_config-dpll_hw_state.pll6,
  pipe_config-dpll_hw_state.pll8,
  pipe_config-dpll_hw_state.pll9,
+ pipe_config-dpll_hw_state.pll10,
  pipe_config-dpll_hw_state.pcsdw12);
} else if (IS_SKYLAKE(dev)) {
DRM_DEBUG_KMS(ddi_pll_sel: %u; dpll_hw_state: 


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915/bxt: add missing DDI PLL registers to the state checking

2015-06-24 Thread Jindal, Sonika



Looks good to me:
Reviewed-by: Sonika Jindal sonika.jin...@intel.com

On 6/24/2015 3:49 PM, Imre Deak wrote:

On ke, 2015-06-24 at 15:37 +0530, Jindal, Sonika wrote:


On 6/18/2015 7:55 PM, Imre Deak wrote:

Although we have a fixed setting for the PLL9 and EBB4 registers, it
still makes sense to check them together with the rest of PLL registers.

While at it also remove a redundant comment about 10 bit clock enabling.

Signed-off-by: Imre Deak imre.d...@intel.com
---
   drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
   drivers/gpu/drm/i915/i915_reg.h  |  3 ++-
   drivers/gpu/drm/i915/intel_ddi.c | 16 +---
   drivers/gpu/drm/i915/intel_display.c |  6 --
   4 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 491ef0c..bf235ff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -366,7 +366,8 @@ struct intel_dpll_hw_state {
uint32_t cfgcr1, cfgcr2;

/* bxt */
-   uint32_t ebb0, pll0, pll1, pll2, pll3, pll6, pll8, pll10, pcsdw12;
+   uint32_t ebb0, ebb4, pll0, pll1, pll2, pll3, pll6, pll8, pll9, pll10,
+pcsdw12;
   };

   struct intel_shared_dpll_config {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4bbc85a..bba0691 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1207,7 +1207,8 @@ enum skl_disp_power_wells {
   /* PORT_PLL_8_A */
   #define   PORT_PLL_TARGET_CNT_MASK   0x3FF
   /* PORT_PLL_9_A */
-#define  PORT_PLL_LOCK_THRESHOLD_MASK  0xe
+#define  PORT_PLL_LOCK_THRESHOLD_SHIFT 1
+#define  PORT_PLL_LOCK_THRESHOLD_MASK  (0x7  PORT_PLL_LOCK_THRESHOLD_SHIFT)
   /* PORT_PLL_10_A */
   #define  PORT_PLL_DCO_AMP_OVR_EN_H   (127)
   #define  PORT_PLL_DCO_AMP_MASK   0x3c00
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index bdc5677..ca970ba 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1476,11 +1476,15 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,

crtc_state-dpll_hw_state.pll8 = targ_cnt;

+   crtc_state-dpll_hw_state.pll9 = 5  PORT_PLL_LOCK_THRESHOLD_SHIFT;
+
if (dcoampovr_en_h)
crtc_state-dpll_hw_state.pll10 = PORT_PLL_DCO_AMP_OVR_EN_H;

crtc_state-dpll_hw_state.pll10 |= PORT_PLL_DCO_AMP(dco_amp);

+   crtc_state-dpll_hw_state.ebb4 = PORT_PLL_10BIT_CLK_ENABLE;

You can add  | PORT_PLL_RECALIBRATE and check for this one as well in
bxt_ddi_pll_get_hw_state.


I'm not sure. This bit is cleared after the PLL gets enabled, so we'd
have a mismatch when reading out the HW state. I'd regard this as a
control bit that's not part of the programmed state.


Hmm correct, checked the description now..



+
crtc_state-dpll_hw_state.pcsdw12 =
LANESTAGGER_STRAP_OVRD | lanestagger;

@@ -2414,7 +2418,7 @@ static void bxt_ddi_pll_enable(struct drm_i915_private 
*dev_priv,

temp = I915_READ(BXT_PORT_PLL(port, 9));
temp = ~PORT_PLL_LOCK_THRESHOLD_MASK;
-   temp |= (5  1);
+   temp |= pll-config.hw_state.pll9;
I915_WRITE(BXT_PORT_PLL(port, 9), temp);

temp = I915_READ(BXT_PORT_PLL(port, 10));
@@ -2427,8 +2431,8 @@ static void bxt_ddi_pll_enable(struct drm_i915_private 
*dev_priv,
temp = I915_READ(BXT_PORT_PLL_EBB_4(port));
temp |= PORT_PLL_RECALIBRATE;
I915_WRITE(BXT_PORT_PLL_EBB_4(port), temp);
-   /* Enable 10 bit clock */

I think it is OK to keep this comment here because all the steps are
mentioned in comments, even disable 10 bit clock.


Yea, but some of those comments just say what is really obvious from the
code right afterwards.


Yes :). Maybe clean up the other comments in the next attempt.




-   temp |= PORT_PLL_10BIT_CLK_ENABLE;
+   temp = ~PORT_PLL_10BIT_CLK_ENABLE;
+   temp |= pll-config.hw_state.ebb4;
I915_WRITE(BXT_PORT_PLL_EBB_4(port), temp);

/* Enable PLL */
@@ -2481,6 +2485,9 @@ static bool bxt_ddi_pll_get_hw_state(struct 
drm_i915_private *dev_priv,
hw_state-ebb0 = I915_READ(BXT_PORT_PLL_EBB_0(port));
hw_state-ebb0 = PORT_PLL_P1_MASK | PORT_PLL_P2_MASK;

+   hw_state-ebb4 = I915_READ(BXT_PORT_PLL_EBB_4(port));
+   hw_state-ebb4 = PORT_PLL_10BIT_CLK_ENABLE;
+
hw_state-pll0 = I915_READ(BXT_PORT_PLL(port, 0));
hw_state-pll0 = PORT_PLL_M2_MASK;

@@ -2501,6 +2508,9 @@ static bool bxt_ddi_pll_get_hw_state(struct 
drm_i915_private *dev_priv,
hw_state-pll8 = I915_READ(BXT_PORT_PLL(port, 8));
hw_state-pll8 = PORT_PLL_TARGET_CNT_MASK;

+   hw_state-pll9 = I915_READ(BXT_PORT_PLL(port, 9));
+   hw_state-pll9 = PORT_PLL_LOCK_THRESHOLD_MASK;
+
hw_state-pll10 = I915_READ(BXT_PORT_PLL(port, 10));
hw_state-pll10 = PORT_PLL_DCO_AMP_OVR_EN_H |
   PORT_PLL_DCO_AMP_MASK;
diff --git a/drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH] drm/i915/skl: Buffer translation improvements

2015-06-23 Thread Jindal, Sonika




On 6/23/2015 4:42 PM, David Weinehall wrote:

On Thu, Jun 18, 2015 at 05:05:21PM +0200, Daniel Vetter wrote:

On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:

@@ -3520,6 +3545,9 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp, 
uint32_t *DP)
} else if (HAS_DDI(dev)) {
signal_levels = hsw_signal_levels(train_set);
mask = DDI_BUF_EMP_MASK;
+
+   if (IS_SKYLAKE(dev))
+   skl_set_iboost(intel_dp);


Imo this should be put into hsw_signal_levels and then hsw_signal_levels
be moved into intel_ddi.c - that way everything related to low-level ddi
DP signal level code in intel_ddi.c.


I'm guessing the BXT code should be moved there too
and preferably folded in under HAS_DDI(dev)?
No, it is not required. The Vswing programming for SKL and BXT is 
completely different. So, better keep it separate.





Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915/bxt: eDP Panel Power sequencing

2015-06-18 Thread Jindal, Sonika

Looks good to me.
Reviewed-by: Sonika Jindal sonika.jin...@intel.com

 -Original Message-
 From: Kannan, Vandana
 Sent: Thursday, June 18, 2015 11:01 AM
 To: intel-gfx@lists.freedesktop.org
 Cc: Jindal, Sonika; Kannan, Vandana
 Subject: [PATCH v5] drm/i915/bxt: eDP Panel Power sequencing
 
 Changes for BXT - added a IS_BROXTON check to use the macro related to
 PPS registers for BXT.
 BXT does not have PP_DIV register. Making changes to handle this.
 Second set of PPS registers have been defined but will be used when VBT
 provides a selection between the 2 sets of registers.
 
 v2:
 [Jani] Added 2nd set of PPS registers and the macro Jani's review comments
   - remove reference in i915_suspend.c
   - Use BXT PP macro
 Squashing all PPS related patches into one.
 
 v3: Jani's review comments addressed
   - Use pp_ctl instead of pp
   - ironlake_get_pp_control() is not required for BXT
   - correct the use of  in the print statement
   - drop the shift in the print statement
 
 v4: Jani's comments
   - modify ironlake_get_pp_control() - dont set unlock key for bxt
 
 v5: Sonika's comments addressed
   - check alignment
   - move pp_ctrl_reg write (after ironlake_get_pp_control())
   to !IS_BROXTON case.
   - check before subtracting 1 for t11_t12
 
 Signed-off-by: Vandana Kannan vandana.kan...@intel.com
 Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com
 ---
  drivers/gpu/drm/i915/i915_reg.h | 13 +++
 drivers/gpu/drm/i915/intel_dp.c | 82
 -
  2 files changed, 78 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_reg.h
 b/drivers/gpu/drm/i915/i915_reg.h index 0b979ad..27eb49e 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -6391,6 +6391,8 @@ enum skl_disp_power_wells {
  #define PCH_PP_CONTROL   0xc7204
  #define  PANEL_UNLOCK_REGS   (0xabcd  16)
  #define  PANEL_UNLOCK_MASK   (0x  16)
 +#define  BXT_POWER_CYCLE_DELAY_MASK  (0x1f0)
 +#define  BXT_POWER_CYCLE_DELAY_SHIFT 4
  #define  EDP_FORCE_VDD   (1  3)
  #define  EDP_BLC_ENABLE  (1  2)
  #define  PANEL_POWER_RESET   (1  1)
 @@ -6419,6 +6421,17 @@ enum skl_disp_power_wells {
  #define  PANEL_POWER_CYCLE_DELAY_MASK(0x1f)
  #define  PANEL_POWER_CYCLE_DELAY_SHIFT   0
 
 +/* BXT PPS changes - 2nd set of PPS registers */
 +#define _BXT_PP_STATUS2  0xc7300
 +#define _BXT_PP_CONTROL2 0xc7304
 +#define _BXT_PP_ON_DELAYS2   0xc7308
 +#define _BXT_PP_OFF_DELAYS2  0xc730c
 +
 +#define BXT_PP_STATUS(n) ((!n) ? PCH_PP_STATUS : _BXT_PP_STATUS2)
 +#define BXT_PP_CONTROL(n)((!n) ? PCH_PP_CONTROL :
 _BXT_PP_CONTROL2)
 +#define BXT_PP_ON_DELAYS(n)  ((!n) ? PCH_PP_ON_DELAYS :
 _BXT_PP_ON_DELAYS2)
 +#define BXT_PP_OFF_DELAYS(n) ((!n) ? PCH_PP_OFF_DELAYS :
 _BXT_PP_OFF_DELAYS2)
 +
  #define PCH_DP_B 0xe4100
  #define PCH_DPB_AUX_CH_CTL   0xe4110
  #define PCH_DPB_AUX_CH_DATA1 0xe4114
 diff --git a/drivers/gpu/drm/i915/intel_dp.c
 b/drivers/gpu/drm/i915/intel_dp.c index f52eef1..c2145e7 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -567,7 +567,9 @@ static u32 _pp_ctrl_reg(struct intel_dp *intel_dp)  {
   struct drm_device *dev = intel_dp_to_dev(intel_dp);
 
 - if (HAS_PCH_SPLIT(dev))
 + if (IS_BROXTON(dev))
 + return BXT_PP_CONTROL(0);
 + else if (HAS_PCH_SPLIT(dev))
   return PCH_PP_CONTROL;
   else
   return
 VLV_PIPE_PP_CONTROL(vlv_power_sequencer_pipe(intel_dp));
 @@ -577,7 +579,9 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)  {
   struct drm_device *dev = intel_dp_to_dev(intel_dp);
 
 - if (HAS_PCH_SPLIT(dev))
 + if (IS_BROXTON(dev))
 + return BXT_PP_STATUS(0);
 + else if (HAS_PCH_SPLIT(dev))
   return PCH_PP_STATUS;
   else
   return
 VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
 @@ -1702,8 +1706,10 @@ static  u32 ironlake_get_pp_control(struct
 intel_dp *intel_dp)
   lockdep_assert_held(dev_priv-pps_mutex);
 
   control = I915_READ(_pp_ctrl_reg(intel_dp));
 - control = ~PANEL_UNLOCK_MASK;
 - control |= PANEL_UNLOCK_REGS;
 + if (!IS_BROXTON(dev)) {
 + control = ~PANEL_UNLOCK_MASK;
 + control |= PANEL_UNLOCK_REGS;
 + }
   return control;
  }
 
 @@ -5092,8 +5098,8 @@ intel_dp_init_panel_power_sequencer(struct
 drm_device *dev,
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct edp_power_seq cur, vbt, spec,
   *final = intel_dp-pps_delays;
 - u32 pp_on, pp_off, pp_div, pp;
 - int pp_ctrl_reg, pp_on_reg, pp_off_reg, pp_div_reg;
 + u32 pp_on, pp_off, pp_div = 0, pp_ctl = 0;
 + int pp_ctrl_reg, pp_on_reg, pp_off_reg, pp_div_reg = 0;
 
   lockdep_assert_held(dev_priv-pps_mutex);
 
 @@ -5101,7 +5107,16 @@ intel_dp_init_panel_power_sequencer(struct
 drm_device *dev

Re: [Intel-gfx] [PATCH v4] drm/i915/bxt: eDP Panel Power sequencing

2015-06-17 Thread Jindal, Sonika




On 6/12/2015 3:57 PM, Vandana Kannan wrote:

Changes for BXT - added a IS_BROXTON check to use the macro related to PPS
registers for BXT.
BXT does not have PP_DIV register. Making changes to handle this.
Second set of PPS registers have been defined but will be used when VBT
provides a selection between the 2 sets of registers.

v2:
[Jani] Added 2nd set of PPS registers and the macro
Jani's review comments
- remove reference in i915_suspend.c
- Use BXT PP macro
Squashing all PPS related patches into one.

v3: Jani's review comments addressed
- Use pp_ctl instead of pp
- ironlake_get_pp_control() is not required for BXT
- correct the use of  in the print statement
- drop the shift in the print statement

v4: Jani's comments
- modify ironlake_get_pp_control() - dont set unlock key for bxt

Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com
Cc: Jani Nikula jani.nik...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_reg.h | 13 +++
  drivers/gpu/drm/i915/intel_dp.c | 76 -
  2 files changed, 72 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7213224..cc03b5b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6377,6 +6377,8 @@ enum skl_disp_power_wells {
  #define PCH_PP_CONTROL0xc7204
  #define  PANEL_UNLOCK_REGS(0xabcd  16)
  #define  PANEL_UNLOCK_MASK(0x  16)
+#define  BXT_POWER_CYCLE_DELAY_MASK(0x1f0)
+#define  BXT_POWER_CYCLE_DELAY_SHIFT   4
  #define  EDP_FORCE_VDD(1  3)
  #define  EDP_BLC_ENABLE   (1  2)
  #define  PANEL_POWER_RESET(1  1)
@@ -6405,6 +6407,17 @@ enum skl_disp_power_wells {
  #define  PANEL_POWER_CYCLE_DELAY_MASK (0x1f)
  #define  PANEL_POWER_CYCLE_DELAY_SHIFT0

+/* BXT PPS changes - 2nd set of PPS registers */
+#define _BXT_PP_STATUS20xc7300

Not aligned?


+#define _BXT_PP_CONTROL2   0xc7304
+#define _BXT_PP_ON_DELAYS2 0xc7308
+#define _BXT_PP_OFF_DELAYS20xc730c
+
+#define BXT_PP_STATUS(n)   ((!n) ? PCH_PP_STATUS : _BXT_PP_STATUS2)
+#define BXT_PP_CONTROL(n)  ((!n) ? PCH_PP_CONTROL : _BXT_PP_CONTROL2)
+#define BXT_PP_ON_DELAYS(n)((!n) ? PCH_PP_ON_DELAYS : _BXT_PP_ON_DELAYS2)
+#define BXT_PP_OFF_DELAYS(n)   ((!n) ? PCH_PP_OFF_DELAYS : _BXT_PP_OFF_DELAYS2)
+
  #define PCH_DP_B  0xe4100
  #define PCH_DPB_AUX_CH_CTL0xe4110
  #define PCH_DPB_AUX_CH_DATA1  0xe4114
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 15e8892..ad9cb0e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -567,7 +567,9 @@ static u32 _pp_ctrl_reg(struct intel_dp *intel_dp)
  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);

-   if (HAS_PCH_SPLIT(dev))
+   if (IS_BROXTON(dev))
+   return BXT_PP_CONTROL(0);
+   else if (HAS_PCH_SPLIT(dev))
return PCH_PP_CONTROL;
else
return VLV_PIPE_PP_CONTROL(vlv_power_sequencer_pipe(intel_dp));
@@ -577,7 +579,9 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)
  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);

-   if (HAS_PCH_SPLIT(dev))
+   if (IS_BROXTON(dev))
+   return BXT_PP_STATUS(0);
+   else if (HAS_PCH_SPLIT(dev))
return PCH_PP_STATUS;
else
return VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
@@ -1701,8 +1705,10 @@ static  u32 ironlake_get_pp_control(struct intel_dp 
*intel_dp)
lockdep_assert_held(dev_priv-pps_mutex);

control = I915_READ(_pp_ctrl_reg(intel_dp));
-   control = ~PANEL_UNLOCK_MASK;
-   control |= PANEL_UNLOCK_REGS;
+   if (!IS_BROXTON(dev)) {
+   control = ~PANEL_UNLOCK_MASK;
+   control |= PANEL_UNLOCK_REGS;
+   }
return control;
  }

@@ -5091,8 +5097,8 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = dev-dev_private;
struct edp_power_seq cur, vbt, spec,
*final = intel_dp-pps_delays;
-   u32 pp_on, pp_off, pp_div, pp;
-   int pp_ctrl_reg, pp_on_reg, pp_off_reg, pp_div_reg;
+   u32 pp_on, pp_off, pp_div = 0, pp_ctl = 0;
+   int pp_ctrl_reg, pp_on_reg, pp_off_reg, pp_div_reg = 0;

lockdep_assert_held(dev_priv-pps_mutex);

@@ -5100,7 +5106,16 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
if (final-t11_t12 != 0)
return;

-   if (HAS_PCH_SPLIT(dev)) {
+   if (IS_BROXTON(dev)) {
+   /*
+* TODO: BXT has 2 sets of PPS registers.
+* Correct Register for Broxton need to be identified
+* using VBT. hardcoding for now
+*/
+   pp_ctrl_reg =

Re: [Intel-gfx] [PATCH v2 04/10] drm: Add Gamma correction structure

2015-06-05 Thread Jindal, Sonika




On 6/4/2015 7:12 PM, Kausal Malladi wrote:

From: Kausal Malladi kausal.mall...@intel.com

This patch adds a new structure in DRM layer for Gamma color correction.
This structure will be used by all user space agents to configure
appropriate Gamma precision and Gamma level.

struct drm_intel_gamma {
__u32 gamma_level;
(The gamma_level variable indicates if the Gamma correction is to be
Do you have any macro defines for these levels? Maybe an enum will be 
better?

applied on Pipe/plane)
__u32 gamma_precision;
(The Gamma precision indicates the Gamma mode to be applied)

Supported precisions are -
#define I915_GAMMA_PRECISION_UNKNOWN0
#define I915_GAMMA_PRECISION_CURRENT0x
#define I915_GAMMA_PRECISION_LEGACY (1  0)
#define I915_GAMMA_PRECISION_10BIT  (1  1)
#define I915_GAMMA_PRECISION_12BIT  (1  2)
#define I915_GAMMA_PRECISION_14BIT  (1  3)
#define I915_GAMMA_PRECISION_16BIT  (1  4)

__u32 num_samples;
(The num_samples indicates the number of Gamma correction
coefficients)
__u32 reserved;

You need this reserved?

__u16 values[0];
(An array of size 0, to accommodate the num_samples number of
R16G16B16 pixels, dynamically)
};

v2: Addressing Daniel Stone's comment, added a variable sized array to
carry Gamma correction values as blob property.

Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Kausal Malladi kausal.mall...@intel.com
---
  include/drm/drm_crtc.h |  3 +++
  include/uapi/drm/drm.h | 10 ++
  2 files changed, 13 insertions(+)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 2a75d7d..bc44f27 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -483,6 +483,9 @@ struct drm_crtc {
 * acquire context.
 */
struct drm_modeset_acquire_ctx *acquire_ctx;
+

Just trying to understand, why do we need to store the blob id separately?

+   /* Color Management Blob IDs */
+   u32 gamma_blob_id;
  };

  /**
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..fc2661c 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,16 @@ struct drm_event_vblank {
__u32 reserved;
  };

+/* Color Management structure for Gamma */
+struct drm_gamma {
+   __u32 flags;
+   __u32 gamma_level;
+   __u32 gamma_precision;
+   __u32 num_samples;
+   __u32 reserved;
+   __u16 values[0];
+};
+
  /* typedef area */
  #ifndef __KERNEL__
  typedef struct drm_clip_rect drm_clip_rect_t;


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 07/10] drm/i915: Add pipe level Gamma correction for CHV/BSW

2015-06-05 Thread Jindal, Sonika




On 6/4/2015 7:12 PM, Kausal Malladi wrote:

From: Kausal Malladi kausal.mall...@intel.com

This patch does the following:
1. Adds the core function to program Gamma correction values for CHV/BSW
platform
2. Adds Gamma correction macros/defines
3. Adds drm_mode_crtc_update_color_property function, which replaces the
old blob for the property with the new one
4. Adds a pointer to hold blob for Gamma property in drm_crtc

v2: Addressed all review comments from Sonika and Daniel Stone.

Instead you can mention the changes briefly.



Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Kausal Malladi kausal.mall...@intel.com
---
  drivers/gpu/drm/i915/intel_atomic.c|   6 ++
  drivers/gpu/drm/i915/intel_color_manager.c | 161 +
  drivers/gpu/drm/i915/intel_color_manager.h |  62 +++
  3 files changed, 229 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index b5c78d8..4726847 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -428,6 +428,12 @@ intel_crtc_atomic_set_property(struct drm_crtc *crtc,
   struct drm_property *property,
   uint64_t val)
  {
+   struct drm_device *dev = crtc-dev;
+   struct drm_mode_config *config = dev-mode_config;
+
+   if (property == config-gamma_property)
+   return intel_color_manager_set_gamma(dev, crtc-base, val);
+
DRM_DEBUG_KMS(Unknown crtc property '%s'\n, property-name);
return -EINVAL;
  }
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 8d4ee8f..421c267 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,167 @@

  #include intel_color_manager.h

+int chv_set_gamma(struct drm_device *dev, uint32_t blob_id,
+   struct drm_crtc *crtc)
+{
+   struct drm_gamma *gamma_data;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct drm_property_blob *blob;
+   struct drm_mode_config *config = dev-mode_config;
+   u32 cgm_control_reg = 0;
+   u32 cgm_gamma_reg = 0;
+   u32 reg, val;
+   enum pipe pipe;
+   u16 red, green, blue;
+   struct rgb_pixel correct_rgb;
+   u32 count = 0;
+   struct rgb_pixel *correction_values = NULL;
+   u32 num_samples;
+   u32 word;
+   u32 palette;
+   int ret = 0, length;
+
+   blob = drm_property_lookup_blob(dev, blob_id);
+   if (!blob) {
+   DRM_ERROR(Invalid Blob ID\n);
+   return -EINVAL;
+   }
+
+   gamma_data = (struct drm_gamma *)blob-data;
+   pipe = to_intel_crtc(crtc)-pipe;
+   num_samples = gamma_data-num_samples;
+   length = num_samples * sizeof(struct rgb_pixel);
+
+   if (gamma_data-gamma_precision == I915_GAMMA_PRECISION_UNKNOWN) {

Switch/case instead?

Also, is UNKNOWN for disabling? Why not rename it to DISABLE then?

+
+   /* Disable Gamma functionality on Pipe - CGM Block */
+   cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+   cgm_control_reg = ~CGM_GAMMA_EN;
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+   DRM_DEBUG_DRIVER(Gamma disabled on Pipe %c\n,
+   pipe_name(pipe));
+   ret = 0;
+   } else if (gamma_data-gamma_precision == I915_GAMMA_PRECISION_LEGACY) {
+
+   if (num_samples != CHV_8BIT_GAMMA_MAX_VALS) {
+   DRM_ERROR(Incorrect number of samples received\n);
+   return -EINVAL;
+   }
+
+   /* First, disable CGM Gamma, if already set */
+   cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+   cgm_control_reg = ~CGM_GAMMA_EN;
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+   /* Enable (Legacy) Gamma on Pipe */
+   palette = _PIPE_GAMMA_BASE(pipe);
+
+   count = 0;
+   correction_values = (struct rgb_pixel *)gamma_data-values;
+   while (count  num_samples) {
+   correct_rgb = correction_values[count];
+   blue = correction_values[count].blue;
+   green = correction_values[count].green;
+   red = correction_values[count].red;
+
+   blue = blue  CHV_8BIT_GAMMA_MSB_SHIFT;
+   green = green  CHV_8BIT_GAMMA_MSB_SHIFT;
+   red = red  CHV_8BIT_GAMMA_MSB_SHIFT;
+
+   /* Red (23:16), Green (15:8), Blue (7:0) */
+   word = (red  CHV_8BIT_GAMMA_SHIFT_RED_REG) |
+   (green 
+CHV_8BIT_GAMMA_SHIFT_GREEN_REG) |
+   blue;
+

Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

2015-06-04 Thread Jindal, Sonika

HI Kausal,

You don't need to send the entire series again .
Just send the updated patch --in-reply-to to the last message.
Otherwise the thread gets lost.

You can send the entire series once the review is complete and you feel that 
the patches are too nested inside.
Please keep sending the patches using --in-reply-to tag.

Regards,
Sonika

-Original Message-
From: Malladi, Kausal 
Sent: Thursday, June 4, 2015 7:13 PM
To: Roper, Matthew D; Barnes, Jesse; Lespiau, Damien; Jindal, Sonika; R, 
Durgadoss; Purushothaman, Vijay A; intel-gfx@lists.freedesktop.org; 
dri-de...@lists.freedesktop.org
Cc: Vetter, Daniel; Sharma, Shashank; Kamath, Sunil; Mukherjee, Indranil; 
Matheson, Annie J; R, Dhanya p; Palleti, Avinash Reddy; Malladi, Kausal
Subject: [PATCH v2 00/10] Color Manager Implementation

From: Kausal Malladi kausal.mall...@intel.com

This patch set adds color manager implementation in drm/i915 layer.
Color Manager is an extension in i915 driver to support color 
correction/enhancement. Various Intel platforms support several color 
correction capabilities. Color Manager provides abstraction of these properties 
and allows a user space UI agent to correct/enhance the display.

The first three patches add code for the framework, which will be common across 
all the Intel platforms. 
  drm/i915: Initialize Color Manager
  drm/i915: Attach color properties to CRTC
  drm/i915: Add Set property interface for CRTC

In the next patches, we are adding support for Gamma and CSC color properties. 
Please note that:
1. The current implementation is only limited for CHV/BSW platforms, and the 
support for
   other platforms will be following up soon.
2. The current patch set implements only the set part of the properties, 
get part will
   be following up soon.

The design of color management on linux is done by:
Jesse Barnes
Sirisha Muppavarapu
Shashank Sharma
Susanta Bhattacharjee

The complete design is explained in the design document, which is available at 
https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSDb_2w/edit#

v2: Addressed review comments from Sonika and Daniel Stone.

Kausal Malladi (10):
  drm/i915: Initialize Color Manager
  drm/i915: Attach color properties to CRTC
  drm/i915: Add atomic set property interface for CRTC
  drm: Add Gamma correction structure
  drm: Add a new function for updating color blob
  drm: Avoid atomic commit path for CRTC property (Gamma)
  drm/i915: Add pipe level Gamma correction for CHV/BSW
  drm: Add CSC correction structure
  drm: Avoid atomic commit path for CSC property on CRTC
  drm/i915: Add CSC support for CHV/BSW

 drivers/gpu/drm/drm_atomic_helper.c|  18 +-
 drivers/gpu/drm/drm_crtc.c |  15 ++
 drivers/gpu/drm/i915/Makefile  |   3 +
 drivers/gpu/drm/i915/intel_atomic.c|  19 +-
 drivers/gpu/drm/i915/intel_color_manager.c | 348 + 
 drivers/gpu/drm/i915/intel_color_manager.h | 122 ++
 drivers/gpu/drm/i915/intel_display.c   |   8 +
 drivers/gpu/drm/i915/intel_drv.h   |   4 +
 include/drm/drm_crtc.h |  12 +
 include/uapi/drm/drm.h |  18 ++
 10 files changed, 563 insertions(+), 4 deletions(-)  create mode 100644 
drivers/gpu/drm/i915/intel_color_manager.c
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h

--
2.4.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: edp1.4 Intermediate Freq support

2015-06-02 Thread Jindal, Sonika


Hi Vandana,

Can you please review the v6 of this patch?

This was rebased recently on top of your patch:
 commit b6dc71f38a84e36c5445b95f9f7a2dac6b25636f
 Author: Vandana Kannan vandana.kan...@intel.com
 Date:   Wed May 13 12:18:52 2015 +0530

  drm/i915/bxt: Port PLL programming BUN

Thanks,
Sonika

On 5/26/2015 5:50 PM, Sonika Jindal wrote:

BXT supports following intermediate link rates for edp:
2.16GHz, 2.43GHz, 3.24GHz, 4.32GHz.
Adding support for programming the intermediate rates.

v2: Adding clock in bxt_clk_div struct and then look for the entry with
required rate (Ville)
v3: 'clock' has the selected value, no need to use link_bw or rate_select
for selecting pll(Ville)
v4: Make bxt_dp_clk_val const and remove size (Ville)
v5: Rebased
v6: Removed setting of vco while rebasing in v5, adding it back

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com(v4)
---
  drivers/gpu/drm/i915/intel_ddi.c |   39 --
  drivers/gpu/drm/i915/intel_dp.c  |7 ++-
  2 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cacb07b..2a2518d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1334,6 +1334,7 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,

  /* bxt clock parameters */
  struct bxt_clk_div {
+   int clock;
uint32_t p1;
uint32_t p2;
uint32_t m2_int;
@@ -1343,14 +1344,14 @@ struct bxt_clk_div {
  };

  /* pre-calculated values for DP linkrates */
-static struct bxt_clk_div bxt_dp_clk_val[7] = {
-   /* 162 */ {4, 2, 32, 1677722, 1, 1},
-   /* 270 */ {4, 1, 27,   0, 0, 1},
-   /* 540 */ {2, 1, 27,   0, 0, 1},
-   /* 216 */ {3, 2, 32, 1677722, 1, 1},
-   /* 243 */ {4, 1, 24, 1258291, 1, 1},
-   /* 324 */ {4, 1, 32, 1677722, 1, 1},
-   /* 432 */ {3, 1, 32, 1677722, 1, 1}
+static const struct bxt_clk_div bxt_dp_clk_val[] = {
+   {162000, 4, 2, 32, 1677722, 1, 1},
+   {27, 4, 1, 27,   0, 0, 1},
+   {54, 2, 1, 27,   0, 0, 1},
+   {216000, 3, 2, 32, 1677722, 1, 1},
+   {243000, 4, 1, 24, 1258291, 1, 1},
+   {324000, 4, 1, 32, 1677722, 1, 1},
+   {432000, 3, 1, 32, 1677722, 1, 1}
  };

  static bool
@@ -1390,22 +1391,14 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
vco = best_clock.vco;
} else if (intel_encoder-type == INTEL_OUTPUT_DISPLAYPORT ||
intel_encoder-type == INTEL_OUTPUT_EDP) {
-   struct drm_encoder *encoder = intel_encoder-base;
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   int i;

-   switch (intel_dp-link_bw) {
-   case DP_LINK_BW_1_62:
-   clk_div = bxt_dp_clk_val[0];
-   break;
-   case DP_LINK_BW_2_7:
-   clk_div = bxt_dp_clk_val[1];
-   break;
-   case DP_LINK_BW_5_4:
-   clk_div = bxt_dp_clk_val[2];
-   break;
-   default:
-   clk_div = bxt_dp_clk_val[0];
-   DRM_ERROR(Unknown link rate\n);
+   clk_div = bxt_dp_clk_val[0];
+   for (i = 0; i  ARRAY_SIZE(bxt_dp_clk_val); ++i) {
+   if (bxt_dp_clk_val[i].clock == clock) {
+   clk_div = bxt_dp_clk_val[i];
+   break;
+   }
}
vco = clock * 10 / 2 * clk_div.p1 * clk_div.p2;
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index abd442a..bd0f958 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -91,6 +91,8 @@ static const struct dp_link_dpll chv_dpll[] = {
{ .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
  };

+static const int bxt_rates[] = { 162000, 216000, 243000, 27,
+ 324000, 432000, 54 };
  static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
  static const int chv_rates[] = { 162000, 202500, 21, 216000,
@@ -1170,7 +1172,10 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int 
**sink_rates)
  static int
  intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
  {
-   if (IS_SKYLAKE(dev)) {
+   if (IS_BROXTON(dev)) {
+   *source_rates = bxt_rates;
+   return ARRAY_SIZE(bxt_rates);
+   } else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
} else if (IS_CHERRYVIEW(dev)) {


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Initialize Color Manager

2015-06-02 Thread Jindal, Sonika




On 6/2/2015 1:22 AM, Kausal Malladi wrote:

From: Kausal Malladi kausal.mall...@intel.com

Color Manager is an extension in i915 driver to handle color correction
and enhancements across various Intel platforms.

This patch initializes color manager framework by :
1. Adding two new files, intel_color_manager(.c/.h)
2. Introducing new pointers in DRM mode_config structure to
carry CSC and Gamma color correction properties.
3. Creating these DRM properties in Color Manager initialization
sequence.

Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Kausal Malladi kausal.mall...@intel.com
---
  drivers/gpu/drm/i915/Makefile  |3 ++
  drivers/gpu/drm/i915/intel_color_manager.c |   49 
  drivers/gpu/drm/i915/intel_color_manager.h |   32 ++
  drivers/gpu/drm/i915/intel_display.c   |5 +++
  include/drm/drm_crtc.h |4 +++
  5 files changed, 93 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
  create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b7ddf48..c62d048 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -89,6 +89,9 @@ i915-y += i915_vgpu.o
  # legacy horrors
  i915-y += i915_dma.o

+# Color Management
+i915-y += intel_color_manager.o
+
  obj-$(CONFIG_DRM_I915)  += i915.o

  CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..c83a212
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma shashank.sha...@intel.com
+ * Kausal Malladi kausal.mall...@intel.com
+ */
+
+#include intel_color_manager.h
+
+int intel_color_manager_init(struct drm_device *dev)
+{
+   struct drm_mode_config *config = dev-mode_config;
+
+   /* Create Gamma and CSC properties */
+   config-gamma_property = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB, gamma_property, 0);
+   if (!config-gamma_property)
+   DRM_ERROR(Gamma property creation failed\n);
+
+   DRM_DEBUG_DRIVER(Created Gamma property\n);
+
+   config-csc_property = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB, csc_property, 0);
+   if (!config-csc_property)
+   DRM_ERROR(CSC property creation failed\n);
+
+   DRM_DEBUG_DRIVER(Created CSC property\n);
+   return 0;
+}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
new file mode 100644
index 000..3cff09d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Add Set property interface for CRTC

2015-06-02 Thread Jindal, Sonika




On 6/2/2015 1:22 AM, Kausal Malladi wrote:

From: Kausal Malladi kausal.mall...@intel.com

This patch adds set property interface for Intel CRTC. This interface
will be used to set color correction DRM properties.

Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Kausal Malladi kausal.mall...@intel.com
---
  drivers/gpu/drm/i915/intel_display.c |8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f817cea..21e67da 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12978,11 +12978,19 @@ out:
return ret;
  }

+static int intel_crtc_set_property(struct drm_crtc *crtc,
+   struct drm_property *property, uint64_t val)
+{
+   DRM_DEBUG_KMS(Unknown crtc property '%s'\n, property-name);
+   return -EINVAL;
+}
+
  static const struct drm_crtc_funcs intel_crtc_funcs = {
.gamma_set = intel_crtc_gamma_set,
.set_config = intel_crtc_set_config,
.destroy = intel_crtc_destroy,
.page_flip = intel_crtc_page_flip,
+   .set_property = intel_crtc_set_property,
I think it should be done similar to plane set property using atomic 
helpers.



.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
  };


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/7] drm: Add Gamma correction structure

2015-06-02 Thread Jindal, Sonika




On 6/2/2015 1:22 AM, Kausal Malladi wrote:

From: Kausal Malladi kausal.mall...@intel.com

This patch adds a new structure in DRM layer for Gamma color correction.
This structure will be used by all user space agents to configure
appropriate Gamma precision and Gamma level.

struct drm_intel_gamma {
__u32 flags;
(The flag variable will indicate if the property to be set/get
is Gamma or DeGamma)
__u32 gamma_level;
(The gamma_level variable indicates if the Gamma correction is to be
applied on Pipe/plane)
__u32 gamma_precision;
(The Gamma precision indicates the Gamma mode to be applied)

Supported precisions are -
#define I915_GAMMA_PRECISION_UNKNOWN0
#define I915_GAMMA_PRECISION_CURRENT0x
#define I915_GAMMA_PRECISION_LEGACY (1  0)
#define I915_GAMMA_PRECISION_10BIT  (1  1)
#define I915_GAMMA_PRECISION_12BIT  (1  2)
#define I915_GAMMA_PRECISION_14BIT  (1  3)
#define I915_GAMMA_PRECISION_16BIT  (1  4)

__u32 num_samples;
(The num_samples indicates the number of Gamma correction
coefficients)
__u32 reserved;
__u64 gamma_ptr;
(Points to the raw Gamma color correction values)
};

Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Kausal Malladi kausal.mall...@intel.com
---
  include/uapi/drm/drm.h |   11 +++
  1 file changed, 11 insertions(+)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..fe27e5c 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,17 @@ struct drm_event_vblank {
__u32 reserved;
  };

+/* Color Management structure for Gamma */
+struct drm_intel_gamma {
I suppose, this can be used by other drivers as well? If yes, intel 
can be removed.

+   __u32 obj_id;
+   __u32 flags;
+   __u32 gamma_level;
+   __u32 gamma_precision;
+   __u32 num_samples;
+   __u32 reserved;
+   __u64 gamma_ptr;
+};
+
  /* typedef area */
  #ifndef __KERNEL__
  typedef struct drm_clip_rect drm_clip_rect_t;


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Add pipe level Gamma correction for CHV/BSW

2015-06-02 Thread Jindal, Sonika




On 6/2/2015 1:22 AM, Kausal Malladi wrote:

From: Kausal Malladi kausal.mall...@intel.com

This patch does the following:
1. Adds the core function to program Gamma correction values for CHV/BSW
platform
2. Adds Gamma correction macros/defines
3. Adds drm_mode_crtc_update_color_property function, which replaces the
old blob for the property with the new one
4. Adds a pointer to hold blob for Gamma property in drm_crtc

Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Kausal Malladi kausal.mall...@intel.com
---
  drivers/gpu/drm/drm_crtc.c |   14 ++
  drivers/gpu/drm/i915/intel_color_manager.c |  194 
  drivers/gpu/drm/i915/intel_color_manager.h |   61 +
  drivers/gpu/drm/i915/intel_display.c   |9 +-
  include/drm/drm_crtc.h |8 ++
  5 files changed, 285 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 77f87b2..50b925b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4691,6 +4691,20 @@ int drm_mode_connector_set_tile_property(struct 
drm_connector *connector)
  }
  EXPORT_SYMBOL(drm_mode_connector_set_tile_property);

+int drm_mode_crtc_update_color_property(struct drm_device *dev,
+   struct drm_property_blob **blob,
+   size_t length, const void *color_data,
+   struct drm_mode_object *obj_holds_id,
+   struct drm_property *prop_holds_id)

This can be simplified.. No need to pass so many params.

+{
+   int ret;
+
+   ret = drm_property_replace_global_blob(dev,
+   blob, length, color_data, obj_holds_id, prop_holds_id);
+
+   return ret;
+}
+
Split the patch to add drm specific changes in a separate patch. Also 
you need to export this function.


Will review the rest of the file in some time.

Regards,
Sonika

  /**
   * drm_mode_connector_update_edid_property - update the edid property of a 
connector
   * @connector: drm connector
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index b0eb679..f46857f 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,200 @@

  #include intel_color_manager.h

+int chv_set_gamma(struct drm_device *dev, uint64_t blob_id,
+   struct drm_crtc *crtc)
+{
+   struct drm_intel_gamma *gamma_data;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct drm_property_blob *blob;
+   struct drm_mode_config *config = dev-mode_config;
+
+   u32 cgm_control_reg = 0;
+   u32 cgm_gamma_reg = 0;
+   u32 reg, val, pipe;
+   u16 red, green, blue;
+   struct rgb_pixel correct_rgb;
+   u32 count = 0;
+   struct rgb_pixel *correction_values = NULL;
+   u32 num_samples;
+   u32 word;
+   u32 palette;
+   int ret = 0, length;
+
+   blob = drm_property_lookup_blob(dev, blob_id);
+   if (!blob) {
+   DRM_ERROR(Invalid Blob ID\n);
+   return -EINVAL;
+   }
+
+   gamma_data = kzalloc(sizeof(struct drm_intel_gamma), GFP_KERNEL);
+   if (!gamma_data) {
+   DRM_ERROR(Memory unavailable\n);
+   return -ENOMEM;
+   }
+   gamma_data = (struct drm_intel_gamma *)blob-data;
+   pipe = to_intel_crtc(crtc)-pipe;
+   num_samples = gamma_data-num_samples;
+   length = num_samples * sizeof(struct rgb_pixel);
+
+   if (gamma_data-gamma_precision == I915_GAMMA_PRECISION_UNKNOWN) {
+
+   /* Disable Gamma functionality on Pipe - CGM Block */
+   cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+   cgm_control_reg = ~CGM_GAMMA_EN;
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+   DRM_DEBUG_DRIVER(Gamma disabled on Pipe %c\n,
+   pipe_name(pipe));
+   ret = 0;
+   goto release_memory;
+   }
+
+   if (pipe = CHV_MAX_PIPES) {
+   DRM_ERROR(Incorrect Pipe ID\n);
+   ret = -EFAULT;
+   goto release_memory;
+   }
+
+   correction_values = kzalloc(length, GFP_KERNEL);
+   if (!correction_values) {
+   DRM_ERROR(Out of Memory\n);
+   ret = -ENOMEM;
+   goto release_memory;
+   }
+
+   ret = copy_from_user((void *)correction_values,
+   (const void __user *)gamma_data-gamma_ptr, length);
+   if (ret) {
+   DRM_ERROR(Error copying user data\n);
+   ret = -EFAULT;
+   goto release_memory;
+   }
+
+   ret = drm_mode_crtc_update_color_property(dev,
+   crtc-gamma_blob, length, (void *) correction_values,
+   crtc-base, config-gamma_property);
+   if (ret) {
+   DRM_ERROR(Error updating Gamma blob\n);
+   ret = -EFAULT;
+

Re: [Intel-gfx] [PATCH] drm/i915/bxt: edp1.4 Intermediate Freq support

2015-05-26 Thread Jindal, Sonika




On 5/26/2015 3:29 PM, Daniel Vetter wrote:

On Tue, May 26, 2015 at 12:57:26PM +0300, Jani Nikula wrote:

On Tue, 26 May 2015, Daniel Vetter dan...@ffwll.ch wrote:

On Tue, May 26, 2015 at 02:51:38PM +0530, Sonika Jindal wrote:

BXT supports following intermediate link rates for edp:
2.16GHz, 2.43GHz, 3.24GHz, 4.32GHz.
Adding support for programming the intermediate rates.

v2: Adding clock in bxt_clk_div struct and then look for the entry with
required rate (Ville)
v3: 'clock' has the selected value, no need to use link_bw or rate_select
for selecting pll(Ville)
v4: Make bxt_dp_clk_val const and remove size (Ville)
v5: Rebased

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com


This time applied for really. Somehow the previous attempt fell short, and
digging into git reflog didn't reveal any clues. Sorry for the mess I've
made.


Please drop this, the rebase does not take into account

commit b6dc71f38a84e36c5445b95f9f7a2dac6b25636f
Author: Vandana Kannan vandana.kan...@intel.com
Date:   Wed May 13 12:18:52 2015 +0530

 drm/i915/bxt: Port PLL programming BUN

and now leaves vco at zero.


Yeah dropped again. I didn't do the rebase myself because of these
functional conflicts, but then totally forgot to check that Sonika
bothered to run the patch first.

Generally when I ask for a rebase it means that there's something
nontrivial going on ...


:( Completely my mistake. Removed that line by mistake :(


Thanks, Daniel


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] kms_rotation_crc: Update rotation direction for kernel changes

2015-05-25 Thread Jindal, Sonika

Thanks for sending this.. I realized that I had a patch for this which I never 
sent :)

Reviewed-by: Sonika Jindal sonika.jin...@intel.com

-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] 
Sent: Friday, May 22, 2015 3:31 PM
To: Intel-gfx@lists.freedesktop.org
Cc: Ursulin, Tvrtko; Ville Syrjälä; Jindal, Sonika
Subject: [PATCH i-g-t] kms_rotation_crc: Update rotation direction for kernel 
changes

From: Tvrtko Ursulin tvrtko.ursu...@intel.com

commit 1e8df16778b0d8fd8102b3ee799b028f8f961089
Author: Sonika Jindal sonika.jin...@intel.com
Date:   Wed May 20 13:40:48 2015 +0530

drm/i915/skl: Swapping 90 and 270 to be compliant with Xrand

Changed the rotation direction so IGT needs to be told.

Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Sonika Jindal sonika.jin...@intel.com
---
 tests/kms_rotation_crc.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index 
e16056d..3fd77c4 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -61,21 +61,19 @@ paint_squares(data_t *data, drmModeModeInfo *mode, 
igt_rotation_t rotation,
}
 
if (rotation == IGT_ROTATION_90) {
-   /* Paint 4 squares with width == height in Blue, Red,
-   Green, White Clockwise order to look like 90 degree rotated*/
-   igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 0.0, 1.0);
-   igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
-   igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 1.0, 1.0);
-   igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0, 1.0, 0.0);
-
-   } else if (rotation == IGT_ROTATION_270) {
/* Paint 4 squares with width == height in Green, White,
Blue, Red Clockwise order to look like 270 degree rotated*/
igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 1.0, 0.0);
igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 1.0, 1.0);
igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 0.0, 0.0);
igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0, 0.0, 1.0);
-
+   } else if (rotation == IGT_ROTATION_270) {
+   /* Paint 4 squares with width == height in Blue, Red,
+   Green, White Clockwise order to look like 90 degree rotated*/
+   igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 0.0, 1.0);
+   igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
+   igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 1.0, 1.0);
+   igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0, 1.0, 0.0);
} else {
/* Paint with 4 squares of Red, Green, White, Blue Clockwise */
igt_paint_color(cr, 0, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
--
2.4.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Documentation/drm: Update rotation property with 90/270 and description

2015-05-20 Thread Jindal, Sonika




On 5/13/2015 9:57 AM, Jindal, Sonika wrote:



On 5/12/2015 6:20 PM, Ville Syrjälä wrote:

On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:

Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  Documentation/DocBook/drm.tmpl |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl
b/Documentation/DocBook/drm.tmpl
index f4976cd..266d50a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2853,9 +2853,12 @@ void intel_crt_init(struct drm_device *dev)
  td rowspan=1 valign=top Plane/td
  td valign=top “rotation”/td
  td valign=top BITMASK/td
-td valign=top { 0, rotate-0 }, { 2, rotate-180 }/td
+td valign=top { 0, rotate-0 }, { 1, rotate-90 },
+{ 2, rotate-180 }, { 3, rotate-270 }/td
  td valign=top Plane/td
-td valign=top TBD/td
+td valign=top To set plane HW rotation. This rotation
property does
+the plane rotation in counter clockwise direction which is
+inline with the way XRandr works./td


I would suggest moving the thing to the generci props section since we
have omap and i915 both supporting it.

You mean in DRM properties section?
Right now, OMAP section also has rotation property. I will remove it
from OMAP section as well if you think drm is the better place.



As for the description, we should also document the reflect flags.


Also, i915 doesn't support reflect flags. Only rotation is supported there.
For the generic part, you meant just moving to the generic group in 
i915 property section?

I might write it as something like this:
rotate-0,rotate-90,rotate-180,rotate-270 rotate the image by the
specified amount in degrees in a counter clockwise direction.
reflect-x,reflect-y reflect the image along the specified axis,
prior to rotation.


  /tr
  tr
  td rowspan=17 valign=top SDVO-TV/td
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Documentation/drm: Update rotation property with 90/270 and description

2015-05-20 Thread Jindal, Sonika




On 5/13/2015 9:57 AM, Jindal, Sonika wrote:



On 5/12/2015 6:20 PM, Ville Syrjälä wrote:

On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:

Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  Documentation/DocBook/drm.tmpl |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl
b/Documentation/DocBook/drm.tmpl
index f4976cd..266d50a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2853,9 +2853,12 @@ void intel_crt_init(struct drm_device *dev)
  td rowspan=1 valign=top Plane/td
  td valign=top “rotation”/td
  td valign=top BITMASK/td
-td valign=top { 0, rotate-0 }, { 2, rotate-180 }/td
+td valign=top { 0, rotate-0 }, { 1, rotate-90 },
+{ 2, rotate-180 }, { 3, rotate-270 }/td
  td valign=top Plane/td
-td valign=top TBD/td
+td valign=top To set plane HW rotation. This rotation
property does
+the plane rotation in counter clockwise direction which is
+inline with the way XRandr works./td


I would suggest moving the thing to the generci props section since we
have omap and i915 both supporting it.

You mean in DRM properties section?
Right now, OMAP section also has rotation property. I will remove it
from OMAP section as well if you think drm is the better place.



As for the description, we should also document the reflect flags.

i915 doesn't support reflect flags. It only create rotation property 
with rotation flags.


For generic section, you mean moving to generic group of properties in 
i915 only right?

I might write it as something like this:
rotate-0,rotate-90,rotate-180,rotate-270 rotate the image by the
specified amount in degrees in a counter clockwise direction.
reflect-x,reflect-y reflect the image along the specified axis,
prior to rotation.


  /tr
  tr
  td rowspan=17 valign=top SDVO-TV/td
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Documentation/drm: Update rotation property with 90/270 and description

2015-05-12 Thread Jindal, Sonika




On 5/12/2015 6:20 PM, Ville Syrjälä wrote:

On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:

Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  Documentation/DocBook/drm.tmpl |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f4976cd..266d50a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2853,9 +2853,12 @@ void intel_crt_init(struct drm_device *dev)
td rowspan=1 valign=top Plane/td
td valign=top “rotation”/td
td valign=top BITMASK/td
-   td valign=top { 0, rotate-0 }, { 2, rotate-180 }/td
+   td valign=top { 0, rotate-0 }, { 1, rotate-90 },
+   { 2, rotate-180 }, { 3, rotate-270 }/td
td valign=top Plane/td
-   td valign=top TBD/td
+   td valign=top To set plane HW rotation. This rotation property does
+   the plane rotation in counter clockwise direction which is
+   inline with the way XRandr works./td


I would suggest moving the thing to the generci props section since we
have omap and i915 both supporting it.

You mean in DRM properties section?
Right now, OMAP section also has rotation property. I will remove it 
from OMAP section as well if you think drm is the better place.




As for the description, we should also document the reflect flags.

I might write it as something like this:
rotate-0,rotate-90,rotate-180,rotate-270 rotate the image by the
specified amount in degrees in a counter clockwise direction.
reflect-x,reflect-y reflect the image along the specified axis,
prior to rotation.


/tr
tr
td rowspan=17 valign=top SDVO-TV/td
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915/bxt: edp1.4 Intermediate Freq support

2015-05-07 Thread Jindal, Sonika




On 5/7/2015 2:11 PM, Ville Syrjälä wrote:

On Thu, May 07, 2015 at 09:52:09AM +0530, Sonika Jindal wrote:

BXT supports following intermediate link rates for edp:
2.16GHz, 2.43GHz, 3.24GHz, 4.32GHz.
Adding support for programming the intermediate rates.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c |   44 --
  drivers/gpu/drm/i915/intel_dp.c  |7 +-
  2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9c1e74a..c0cb5f7 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1397,8 +1397,7 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
clk_div.lanestagger = 0x04;
else
clk_div.lanestagger = 0x02;
-   } else if (intel_encoder-type == INTEL_OUTPUT_DISPLAYPORT ||
-   intel_encoder-type == INTEL_OUTPUT_EDP) {
+   } else if (intel_encoder-type == INTEL_OUTPUT_DISPLAYPORT) {
struct drm_encoder *encoder = intel_encoder-base;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);

@@ -1416,8 +1415,49 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
clk_div = bxt_dp_clk_val[0];
DRM_ERROR(Unknown link rate\n);
}
+   } else if (intel_encoder-type == INTEL_OUTPUT_EDP) {
+   struct drm_encoder *encoder = intel_encoder-base;
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   int link_rate;
+
+   /*
+* If edp1.4 intermediate frequency support is present, we set
+* link_bw to 0 and a valid rate index in rate_select.
+*/
+   if (intel_dp-link_bw)
+   link_rate = 
drm_dp_bw_code_to_link_rate(intel_dp-link_bw);
+   else
+   link_rate = intel_dp-sink_rates[intel_dp-rate_select];


The chosen clock should already be passed in, so no there should be no
need for this. I see the DP case does has the same issue.

Yes it was copied from DP :)




+
+   switch (link_rate) {
+   case 162000:
+   clk_div = bxt_dp_clk_val[0];
+   break;
+   case 216000:
+   clk_div = bxt_dp_clk_val[3];
+   break;
+   case 243000:
+   clk_div = bxt_dp_clk_val[4];
+   break;
+   case 27:
+   clk_div = bxt_dp_clk_val[1];
+   break;
+   case 324000:
+   clk_div = bxt_dp_clk_val[5];
+   break;
+   case 432000:
+   clk_div = bxt_dp_clk_val[6];
+   break;
+   case 54:
+   clk_div = bxt_dp_clk_val[2];
+   break;
+   default:
+   clk_div = bxt_dp_clk_val[0];
+   DRM_ERROR(Unknown link rate\n);
+   }


This looks rather fragile. I would suggest storing the link rate in
the bxt_clk_div structure and just looping through the array looking for
the correct rate. That will also work for normal DP, so less code in the
end.

Ok, I will do that.




}

+


Spurious whitespace.

:(



crtc_state-dpll_hw_state.ebb0 =
PORT_PLL_P1(clk_div.p1) | PORT_PLL_P2(clk_div.p2);
crtc_state-dpll_hw_state.pll0 = clk_div.m2_int;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c9d50d1..e6ee7c6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -85,6 +85,8 @@ static const struct dp_link_dpll chv_dpll[] = {
{ .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
  };

+static const int bxt_rates[] = { 162000, 216000, 243000, 27,
+ 324000, 432000, 54 };
  static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
  static const int chv_rates[] = { 162000, 202500, 21, 216000,
@@ -1161,7 +1163,10 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int 
**sink_rates)
  static int
  intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
  {
-   if (IS_SKYLAKE(dev)) {
+   if (IS_BROXTON(dev)) {
+   *source_rates = bxt_rates;
+   return ARRAY_SIZE(bxt_rates);
+   } else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
} else if (IS_CHERRYVIEW(dev)) {
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Removing redundant is_edp_psr

2015-05-06 Thread Jindal, Sonika

Oh great then :)

Thanks,
Sonika

-Original Message-
From: R, Durgadoss 
Sent: Thursday, May 7, 2015 11:19 AM
To: Jindal, Sonika; intel-gfx@lists.freedesktop.org
Subject: RE: [PATCH] Removing redundant is_edp_psr

-Original Message-
From: Jindal, Sonika
Sent: Thursday, May 7, 2015 9:58 AM
To: intel-gfx@lists.freedesktop.org
Cc: Jindal, Sonika; R, Durgadoss
Subject: [PATCH] Removing redundant is_edp_psr

Since we already store the sink's psr status in dev_priv, use it.
Without this we were ignoring the case where sink supports psr2.

Looks like it is already updated in this patch from Rodrigo:
drm/i915: Add psr_ready on pipe_config
[https://tango.freedesktop.org/patch/45695/]

Thanks,
Durga


Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
 drivers/gpu/drm/i915/intel_psr.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c 
b/drivers/gpu/drm/i915/intel_psr.c
index 27608ce..406d3ac 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -56,11 +56,6 @@
 #include intel_drv.h
 #include i915_drv.h

-static bool is_edp_psr(struct intel_dp *intel_dp) -{
-  return intel_dp-psr_dpcd[0]  DP_PSR_IS_SUPPORTED;
-}
-
 static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int 
pipe)  {
   struct drm_i915_private *dev_priv = dev-dev_private; @@ -365,7 
+360,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
   return;
   }

-  if (!is_edp_psr(intel_dp)) {
+  if (!dev_priv-psr.sink_support) {
   DRM_DEBUG_KMS(PSR not supported by this panel\n);
   return;
   }
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Add module parameter to select edp vswing table

2015-05-05 Thread Jindal, Sonika




On 5/5/2015 7:28 PM, Jani Nikula wrote:

On Tue, 05 May 2015, Damien Lespiau damien.lesp...@intel.com wrote:

On Tue, May 05, 2015 at 02:39:48PM +0300, Jani Nikula wrote:

There's still the question whether we can default to using the vbt value
if that can be broken...


This is a workaround for SDPs loaded with a default VBT which doesn't
correspond to the full fleet of SPDs. For actual product, it's really
expected to have a VBT with a correct low vswing bit set, otherwise the
panel won't lit up (even on Windows!).

It's probably a good idea to add a comment saying that's it's a
workaround for early platform with generic-ish VBT. Something that we
should remove in a bit.


Thanks for the clarification, Damien. That settles the default then. I'd
still like the module parameter to be effective even if changed runtime.

This is used while preparing ddi buffers to program ddi_buf_trans during 
driver load. It will not really have any effect at runtime until power 
well is disabled/re-enabled.
PLease let me know if you still see the need of moving the check 
directly in prepare_ddi_buffers.


Regards,
Sonika

BR,
Jani.





--
Damien



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 7/7] kms_rotation_crc: Use main test for negative cases

2015-04-23 Thread Jindal, Sonika


Thanks Tvrtko.
This series makes kms_rotation_crc much cleaner :)

Reviewed-by: Sonika Jindal sonika.jin...@intel.com


On 4/22/2015 9:16 PM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin tvrtko.ursu...@intel.com

Saves a good amount of code duplication by supporting expected
failures from the main loop.

Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Sonika Jindal sonika.jin...@intel.com
---
  tests/kms_rotation_crc.c | 106 +++
  1 file changed, 33 insertions(+), 73 deletions(-)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 45a9284..0661b6b 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -41,6 +41,8 @@ typedef struct {
int pos_x;
int pos_y;
unsigned int w, h;
+   uint32_t override_fmt;
+   uint64_t override_tiling;
  } data_t;

  static void
@@ -92,8 +94,10 @@ static void prepare_crtc(data_t *data, igt_output_t *output, 
enum pipe pipe,
igt_display_t *display = data-display;
int fb_id, fb_modeset_id;
unsigned int w, h;
-   uint64_t tiling = LOCAL_DRM_FORMAT_MOD_NONE;
-   uint32_t pixel_format = DRM_FORMAT_XRGB;
+   uint64_t tiling = data-override_tiling ?
+ data-override_tiling : LOCAL_DRM_FORMAT_MOD_NONE;
+   uint32_t pixel_format = data-override_fmt ?
+   data-override_fmt : DRM_FORMAT_XRGB;
enum igt_commit_style commit = COMMIT_LEGACY;
igt_plane_t *primary;

@@ -132,10 +136,12 @@ static void prepare_crtc(data_t *data, igt_output_t 
*output, enum pipe pipe,
 */
if (data-rotation == IGT_ROTATION_90 ||
data-rotation == IGT_ROTATION_270) {
-   tiling = LOCAL_I915_FORMAT_MOD_Y_TILED;
+   tiling = data-override_tiling ?
+data-override_tiling : LOCAL_I915_FORMAT_MOD_Y_TILED;
w = h =  mode-vdisplay;
} else if (plane-is_cursor) {
-   pixel_format = DRM_FORMAT_ARGB;
+   pixel_format = data-override_fmt ?
+  data-override_fmt : DRM_FORMAT_ARGB;
w = h = 128;
}

@@ -196,67 +202,6 @@ static void cleanup_crtc(data_t *data, igt_output_t 
*output, igt_plane_t *plane)
igt_display_commit(display);
  }

-static void test_unsupported_tiling_pixel_format(data_t *data, enum igt_plane 
plane_type)
-{
-   drmModeModeInfo *mode;
-   igt_display_t *display = data-display;
-   igt_output_t *output;
-   enum pipe pipe;
-   int fb_tiling_id, fb_565_id;
-   struct igt_fb fb_565, fb_tiling;
-
-   for_each_connected_output(display, output) {
-   for_each_pipe(display, pipe) {
-   igt_plane_t *plane;
-
-   igt_output_set_pipe(output, pipe);
-
-   plane = igt_output_get_plane(output, plane_type);
-   igt_require(igt_plane_supports_rotation(plane));
-   mode = igt_output_get_mode(output);
-
-   fb_tiling_id = igt_create_fb(data-gfx_fd,
-   mode-hdisplay, mode-vdisplay,
-   DRM_FORMAT_XRGB,
-   LOCAL_DRM_FORMAT_MOD_NONE,
-   fb_tiling);
-   igt_assert(fb_tiling_id);
-   igt_plane_set_fb(plane, fb_tiling);
-   /* For the first modeset with legacy commit */
-   igt_display_commit(display);
-   igt_plane_set_rotation(plane, data-rotation);
-   /* Shud fail because 90/270 is only supported with Y/Yf 
*/
-   igt_assert(igt_display_try_commit2(display, 
COMMIT_UNIVERSAL) == -EINVAL);
-
-   fb_565_id = igt_create_fb(data-gfx_fd,
-   mode-hdisplay, mode-vdisplay,
-   DRM_FORMAT_RGB565,
-   LOCAL_I915_FORMAT_MOD_Y_TILED,
-   fb_565);
-   igt_assert(fb_565_id);
-   igt_plane_set_fb(plane, fb_565);
-   igt_plane_set_rotation(plane, data-rotation);
-   /* Shud fail because 90/270 is not supported with 
RGB565 */
-   igt_assert(igt_display_try_commit2(display, 
COMMIT_UNIVERSAL) == -EINVAL);
-
-   /*
-* check the rotation state has been reset when the VT
-* mode is restored
-*/
-   kmstest_restore_vt_mode();
-   kmstest_set_vt_graphics_mode();
-   prepare_crtc(data, output, pipe, plane);
-
-   igt_remove_fb(data-gfx_fd, fb_tiling);
-

Re: [Intel-gfx] [PATCH 2/2] Documentation/drm: Update rotation property with 90/270 and description

2015-04-15 Thread Jindal, Sonika




On 4/15/2015 3:57 PM, Daniel Vetter wrote:

On Wed, Apr 15, 2015 at 03:35:08PM +0530, Sonika Jindal wrote:

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  Documentation/DocBook/drm.tmpl |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f4976cd..266d50a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2853,9 +2853,12 @@ void intel_crt_init(struct drm_device *dev)
td rowspan=1 valign=top Plane/td
td valign=top “rotation”/td
td valign=top BITMASK/td
-   td valign=top { 0, rotate-0 }, { 2, rotate-180 }/td
+   td valign=top { 0, rotate-0 }, { 1, rotate-90 },
+   { 2, rotate-180 }, { 3, rotate-270 }/td
td valign=top Plane/td
-   td valign=top TBD/td
+   td valign=top To set plane HW rotation. This rotation property does
+   the plane rotation in counter clockwise direction which is
+   inline with the way XRandr works./td


Since this touches shared code can you please resend this patch with
dri-devel added to cc? BKM is to add a Cc: dri-devel ... line to the sob
section of the patch, then git send-email will automatically pick it up.
-Daniel


But I am changing the description for only the rotation property for i915.

/tr
tr
td rowspan=17 valign=top SDVO-TV/td
--
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Support for 90/270 rotation

2015-04-14 Thread Jindal, Sonika




On 4/14/2015 5:09 AM, Matt Roper wrote:

On Mon, Apr 13, 2015 at 01:49:22PM +0300, Ville Syrjälä wrote:

On Mon, Apr 13, 2015 at 03:53:22PM +0530, Jindal, Sonika wrote:



On 4/13/2015 3:40 PM, Ville Syrjälä wrote:

On Mon, Apr 13, 2015 at 09:36:02AM +0530, Jindal, Sonika wrote:



On 4/10/2015 8:14 PM, Ville Syrjälä wrote:

On Fri, Apr 10, 2015 at 04:17:17PM +0200, Daniel Vetter wrote:

On Fri, Apr 10, 2015 at 02:37:29PM +0530, Sonika Jindal wrote:

v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_* for offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
v7: Moving pixel_format check to intel_atomic_plane_check (Matt)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Matt Roper matthew.d.ro...@intel.com


Patches are missing the Testcase: tag, please add that. Also, are all the
igt committed or not yet? Pulled these two in meanwhile.


Things are going somewhat broken because you didn't apply my plane
state stuff. Hmm. Actually it sort of looks that it might work by luck
as long as the primary plane doesn't get clipped since this is bashing
the user state directly into the hardware registers and not the derived
state (ie. clipped coordinates).


I was hoping your changes get merged, but not sure why they are held up.


Also I see my review comment about the 90 vs. 270 rotation mixup was
ignored at least.


I never really got the to understand the need of reversing 90 and 270 :)
The last discussion was not concluded, AFAIR.
Things look correct to me and work fine with the testcase also.
Is there something completely different which I am unable to get?


BSpec gives me the impression the hw rotation is cw, whereas the drm one
is ccw.


Yes, HW rotation is cw as per bspec. In drm, where do we consider it as
anti-cw? I assume it is cw because all the macros work as expected, ie cw.


The ccw rule was inherited from XRandR. I'm not sure what macros you
mean, but drm_rect_rotate() will certainly give you wrong results if
you assume cw.


It seems like this information needs to be added to the property section
of the DRM DocBook; continuing to follow XRandR probably makes sense if
that's what's agreed on, but there's no indication of that design
philosophy in the actual DRM documentation today, so we're in danger of
having different driver authors use conflicting interpretations.

Ok, I will create a DocBook patch with description for 90/270 rotation 
(Anyways 90/270 rotation is not added in the rotation property in 
documentation). Will there be any other place for this or i915's 
rotation property?


Also, I will send a patch to flip 90/270 in i915. I am just worried, 
that it will look confusing to check for DRM_ROTATE_90 and use 
PLANE_CTL_ROTATE_270 for programming. I will add a comment though.

Sounds good?

-Sonika

90/270 rotation is already supported by existing drivers (omap for
several years now and atmel-hlcdc just recently).  I think it's too late
to try to redefine the meaning of rotation property values that are
already in active use, so we probably need to check whether omap is
using a cw or ccw scheme and follow (and document!) that.


Matt







-Sonika


-Daniel


---
drivers/gpu/drm/i915/i915_reg.h   |2 +
drivers/gpu/drm/i915/intel_atomic_plane.c |   24 
drivers/gpu/drm/i915/intel_display.c  |   88 
-
drivers/gpu/drm/i915/intel_drv.h  |6 ++
drivers/gpu/drm/i915/intel_sprite.c   |   52 -
5 files changed, 131 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..564bbd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4854,7 +4854,9 @@ enum skl_disp_power_wells {
#define   PLANE_CTL_ALPHA_HW_PREMULTIPLY(  3  4)
#define   PLANE_CTL_ROTATE_MASK 0x3
#define   PLANE_CTL_ROTATE_00x0
+#define   PLANE_CTL_ROTATE_90  0x1
#define   PLANE_CTL_ROTATE_180  0x2
+#define   PLANE_CTL_ROTATE_270 0x3
#define _PLANE_STRIDE_1_A   0x70188
#define _PLANE_STRIDE_2_A   0x70288
#define _PLANE_STRIDE_3_A   0x70388
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 976b891..a27ee8c 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -162,6 +162,30 @@ static int intel_plane_atomic_check(struct drm_plane 
*plane,
(1

1 2 >

1 - 100 of 171 matches

Mail list logo