[PATCH 1/3] drm/i915: turn the eDP VDD on for any i2c transactions

[PATCH 1/3] drm/i915: turn the eDP VDD on for any i2c transactions

[Paulo Zanoni]

From: Paulo Zanoni <paulo.r.zanoni@intel.com>

If the eDP output is disabled, then we try to use /dev/i2c-X file to
do i2c transations, we get a WARN from intel_dp_check_edp() saying
we're trying to do AUX communication with the panel off. So this
commit reorganizes the code so we enable the VDD at
intel_dp_i2c_aux_ch() instead of just the callers inside i915.ko.

This fixes the i2c subtest from the pc8 test of intel-gpu-tools on
machines that have eDP panels.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b3cc333..05d0424 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -623,6 +623,7 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
 	int reply_bytes;
 	int ret;
 
+	ironlake_edp_panel_vdd_on(intel_dp);
 	intel_dp_check_edp(intel_dp);
 	/* Set up the command byte */
 	if (mode & MODE_I2C_READ)
@@ -665,7 +666,7 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
 				      reply, reply_bytes);
 		if (ret < 0) {
 			DRM_DEBUG_KMS("aux_ch failed %d\n", ret);
-			return ret;
+			goto out;
 		}
 
 		switch (reply[0] & AUX_NATIVE_REPLY_MASK) {
@@ -676,7 +677,8 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
 			break;
 		case AUX_NATIVE_REPLY_NACK:
 			DRM_DEBUG_KMS("aux_ch native nack\n");
-			return -EREMOTEIO;
+			ret = -EREMOTEIO;
+			goto out;
 		case AUX_NATIVE_REPLY_DEFER:
 			/*
 			 * For now, just give more slack to branch devices. We
@@ -694,7 +696,8 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
 		default:
 			DRM_ERROR("aux_ch invalid native reply 0x%02x\n",
 				  reply[0]);
-			return -EREMOTEIO;
+			ret = -EREMOTEIO;
+			goto out;
 		}
 
 		switch (reply[0] & AUX_I2C_REPLY_MASK) {
@@ -702,22 +705,29 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
 			if (mode == MODE_I2C_READ) {
 				*read_byte = reply[1];
 			}
-			return reply_bytes - 1;
+			ret = reply_bytes - 1;
+			goto out;
 		case AUX_I2C_REPLY_NACK:
 			DRM_DEBUG_KMS("aux_i2c nack\n");
-			return -EREMOTEIO;
+			ret = -EREMOTEIO;
+			goto out;
 		case AUX_I2C_REPLY_DEFER:
 			DRM_DEBUG_KMS("aux_i2c defer\n");
 			udelay(100);
 			break;
 		default:
 			DRM_ERROR("aux_i2c invalid reply 0x%02x\n", reply[0]);
-			return -EREMOTEIO;
+			ret = -EREMOTEIO;
+			goto out;
 		}
 	}
 
 	DRM_ERROR("too many retries, giving up\n");
-	return -EREMOTEIO;
+	ret = -EREMOTEIO;
+
+out:
+	ironlake_edp_panel_vdd_off(intel_dp, false);
+	return ret;
 }
 
 static int
@@ -739,9 +749,7 @@ intel_dp_i2c_init(struct intel_dp *intel_dp,
 	intel_dp->adapter.algo_data = &intel_dp->algo;
 	intel_dp->adapter.dev.parent = intel_connector->base.kdev;
 
-	ironlake_edp_panel_vdd_on(intel_dp);
 	ret = i2c_dp_aux_add_bus(&intel_dp->adapter);
-	ironlake_edp_panel_vdd_off(intel_dp, false);
 	return ret;
 }
 
@@ -3498,7 +3506,6 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 	intel_dp_init_panel_power_sequencer_registers(dev, intel_dp,
 						      &power_seq);
 
-	ironlake_edp_panel_vdd_on(intel_dp);
 	edid = drm_get_edid(connector, &intel_dp->adapter);
 	if (edid) {
 		if (drm_add_edid_modes(connector, edid)) {
@@ -3530,8 +3537,6 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 			fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
 	}
 
-	ironlake_edp_panel_vdd_off(intel_dp, false);
-
 	intel_panel_init(&intel_connector->panel, fixed_mode);
 	intel_panel_setup_backlight(connector);
 
-- 
1.8.3.1

[PATCH 2/3] drm/i915: reduce eDP VDD message verbose

[Paulo Zanoni]

From: Paulo Zanoni <paulo.r.zanoni@intel.com>

Now we only print messages when we actually enable VDD and when we
actually disable VDD.

The changes in the last commit triggered a big number of messages
while the driver was being initialized, and I thought we were toggling
things on/off too many times, but that was not really true: we were
just being too verbose.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 05d0424..8db1fda 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1077,17 +1077,16 @@ void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp)
 
 	if (!is_edp(intel_dp))
 		return;
-	DRM_DEBUG_KMS("Turn eDP VDD on\n");
 
 	WARN(intel_dp->want_panel_vdd,
 	     "eDP VDD already requested on\n");
 
 	intel_dp->want_panel_vdd = true;
 
-	if (ironlake_edp_have_panel_vdd(intel_dp)) {
-		DRM_DEBUG_KMS("eDP VDD already on\n");
+	if (ironlake_edp_have_panel_vdd(intel_dp))
 		return;
-	}
+
+	DRM_DEBUG_KMS("Turning eDP VDD on\n");
 
 	if (!ironlake_edp_have_panel_power(intel_dp))
 		ironlake_wait_panel_power_cycle(intel_dp);
@@ -1121,6 +1120,8 @@ static void ironlake_panel_vdd_off_sync(struct intel_dp *intel_dp)
 	WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
 
 	if (!intel_dp->want_panel_vdd && ironlake_edp_have_panel_vdd(intel_dp)) {
+		DRM_DEBUG_KMS("Turning eDP VDD off\n");
+
 		pp = ironlake_get_pp_control(intel_dp);
 		pp &= ~EDP_FORCE_VDD;
 
@@ -1153,7 +1154,6 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
 	if (!is_edp(intel_dp))
 		return;
 
-	DRM_DEBUG_KMS("Turn eDP VDD off %d\n", intel_dp->want_panel_vdd);
 	WARN(!intel_dp->want_panel_vdd, "eDP VDD not forced on");
 
 	intel_dp->want_panel_vdd = false;
-- 
1.8.3.1

[PATCH 3/3] drm/i915: cancel the panel VDD work when we do it manually

[Paulo Zanoni]

From: Paulo Zanoni <paulo.r.zanoni@intel.com>

After I reorganized the panel VDD debug messages I was able to spot we
were disabling it one extra time. The problem is that we're missing
the call to cancel the delayed work in one of the instances where we
manually call ironlake_panel_vdd_off_sync().

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8db1fda..f2280b4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1159,6 +1159,7 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
 	intel_dp->want_panel_vdd = false;
 
 	if (sync) {
+		cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
 		ironlake_panel_vdd_off_sync(intel_dp);
 	} else {
 		/*
-- 
1.8.3.1

Re: [PATCH 3/3] drm/i915: cancel the panel VDD work when we do it manually

[Daniel Vetter]

On Wed, Oct 30, 2013 at 07:50:28PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> After I reorganized the panel VDD debug messages I was able to spot we
> were disabling it one extra time. The problem is that we're missing
> the call to cancel the delayed work in one of the instances where we
> manually call ironlake_panel_vdd_off_sync().
> 
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8db1fda..f2280b4 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1159,6 +1159,7 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
>  	intel_dp->want_panel_vdd = false;
>  
>  	if (sync) {
> +		cancel_delayed_work_sync(&intel_dp->panel_vdd_work);

This will deadlock since we hold the mode_config.mutex here, and the
panel_vdd_work also needs that. I've merged the other two patches.
-Daniel

>  		ironlake_panel_vdd_off_sync(intel_dp);
>  	} else {
>  		/*
> -- 
> 1.8.3.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 3/3] drm/i915: cancel the panel VDD work when we do it manually

[Jani Nikula]

On Thu, 31 Oct 2013, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Oct 30, 2013 at 07:50:28PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>> 
>> After I reorganized the panel VDD debug messages I was able to spot we
>> were disabling it one extra time. The problem is that we're missing
>> the call to cancel the delayed work in one of the instances where we
>> manually call ironlake_panel_vdd_off_sync().
>> 
>> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 8db1fda..f2280b4 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1159,6 +1159,7 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
>>  	intel_dp->want_panel_vdd = false;
>>  
>>  	if (sync) {
>> +		cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
>
> This will deadlock since we hold the mode_config.mutex here, and the
> panel_vdd_work also needs that. I've merged the other two patches.

Ooof, reviewer facepalm.

So we are calling ironlake_panel_vdd_off_sync() twice in this path, but
that shouldn't matter, as we have

if (!intel_dp->want_panel_vdd && ironlake_edp_have_panel_vdd(intel_dp))

in there, right? Paulo, is that what you're seeing, or something else?


BR,
Jani.



> -Daniel
>
>>  		ironlake_panel_vdd_off_sync(intel_dp);
>>  	} else {
>>  		/*
>> -- 
>> 1.8.3.1
>> 
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/3] drm/i915: cancel the panel VDD work when we do it manually

[Paulo Zanoni]

2013/10/31 Jani Nikula <jani.nikula@linux.intel.com>:
> On Thu, 31 Oct 2013, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Oct 30, 2013 at 07:50:28PM -0200, Paulo Zanoni wrote:
>>> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>>
>>> After I reorganized the panel VDD debug messages I was able to spot we
>>> were disabling it one extra time. The problem is that we're missing
>>> the call to cancel the delayed work in one of the instances where we
>>> manually call ironlake_panel_vdd_off_sync().
>>>
>>> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>> ---
>>>  drivers/gpu/drm/i915/intel_dp.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>>> index 8db1fda..f2280b4 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -1159,6 +1159,7 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
>>>      intel_dp->want_panel_vdd = false;
>>>
>>>      if (sync) {
>>> +            cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
>>
>> This will deadlock since we hold the mode_config.mutex here, and the
>> panel_vdd_work also needs that. I've merged the other two patches.
>
> Ooof, reviewer facepalm.

Actually it was a "developer facepalm" for messing with locks without
lockdep enabled... I thought I had it enabled, but it seems I didn't
have. Lockdep screams almost 100 lines complaining about my code. My
bad.


>
> So we are calling ironlake_panel_vdd_off_sync() twice in this path, but
> that shouldn't matter, as we have
>
> if (!intel_dp->want_panel_vdd && ironlake_edp_have_panel_vdd(intel_dp))
>
> in there, right? Paulo, is that what you're seeing, or something else?

Yeah, I kept investigating the code and reached the same conclusion,
except for the fact that we were still printing "Turning eDP VDD off"
twice without a "Turn eDP VDD on" in the middle. So I kept
investigating and found we were using the wrong register (as I
reported on IRC). I'll submit another patch soon.

>
>
> BR,
> Jani.
>
>
>
>> -Daniel
>>
>>>              ironlake_panel_vdd_off_sync(intel_dp);
>>>      } else {
>>>              /*
>>> --
>>> 1.8.3.1
>>>
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Paulo Zanoni

Re: [PATCH 3/3] drm/i915: cancel the panel VDD work when we do it manually

[Daniel Vetter]

On Thu, Oct 31, 2013 at 1:46 PM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
> On Thu, 31 Oct 2013, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Oct 30, 2013 at 07:50:28PM -0200, Paulo Zanoni wrote:
>>> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>>
>>> After I reorganized the panel VDD debug messages I was able to spot we
>>> were disabling it one extra time. The problem is that we're missing
>>> the call to cancel the delayed work in one of the instances where we
>>> manually call ironlake_panel_vdd_off_sync().
>>>
>>> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>> ---
>>>  drivers/gpu/drm/i915/intel_dp.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>>> index 8db1fda..f2280b4 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -1159,6 +1159,7 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
>>>      intel_dp->want_panel_vdd = false;
>>>
>>>      if (sync) {
>>> +            cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
>>
>> This will deadlock since we hold the mode_config.mutex here, and the
>> panel_vdd_work also needs that. I've merged the other two patches.
>
> Ooof, reviewer facepalm.
>
> So we are calling ironlake_panel_vdd_off_sync() twice in this path, but
> that shouldn't matter, as we have
>
> if (!intel_dp->want_panel_vdd && ironlake_edp_have_panel_vdd(intel_dp))
>
> in there, right? Paulo, is that what you're seeing, or something else?

The work item should have a check for the actual vdd overwrite state
and if it's off already silently do nothing. At least that should have
been there once before ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 1/3] drm/i915: turn the eDP VDD on for any i2c transactions

[Jani Nikula]

On the series,
Reviewed-by: Jani Nikula <jani.nikula@intel.com>


On Wed, 30 Oct 2013, Paulo Zanoni <przanoni@gmail.com> wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> If the eDP output is disabled, then we try to use /dev/i2c-X file to
> do i2c transations, we get a WARN from intel_dp_check_edp() saying
> we're trying to do AUX communication with the panel off. So this
> commit reorganizes the code so we enable the VDD at
> intel_dp_i2c_aux_ch() instead of just the callers inside i915.ko.
>
> This fixes the i2c subtest from the pc8 test of intel-gpu-tools on
> machines that have eDP panels.
>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 29 +++++++++++++++++------------
>  1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b3cc333..05d0424 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -623,6 +623,7 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
>  	int reply_bytes;
>  	int ret;
>  
> +	ironlake_edp_panel_vdd_on(intel_dp);
>  	intel_dp_check_edp(intel_dp);
>  	/* Set up the command byte */
>  	if (mode & MODE_I2C_READ)
> @@ -665,7 +666,7 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
>  				      reply, reply_bytes);
>  		if (ret < 0) {
>  			DRM_DEBUG_KMS("aux_ch failed %d\n", ret);
> -			return ret;
> +			goto out;
>  		}
>  
>  		switch (reply[0] & AUX_NATIVE_REPLY_MASK) {
> @@ -676,7 +677,8 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
>  			break;
>  		case AUX_NATIVE_REPLY_NACK:
>  			DRM_DEBUG_KMS("aux_ch native nack\n");
> -			return -EREMOTEIO;
> +			ret = -EREMOTEIO;
> +			goto out;
>  		case AUX_NATIVE_REPLY_DEFER:
>  			/*
>  			 * For now, just give more slack to branch devices. We
> @@ -694,7 +696,8 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
>  		default:
>  			DRM_ERROR("aux_ch invalid native reply 0x%02x\n",
>  				  reply[0]);
> -			return -EREMOTEIO;
> +			ret = -EREMOTEIO;
> +			goto out;
>  		}
>  
>  		switch (reply[0] & AUX_I2C_REPLY_MASK) {
> @@ -702,22 +705,29 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
>  			if (mode == MODE_I2C_READ) {
>  				*read_byte = reply[1];
>  			}
> -			return reply_bytes - 1;
> +			ret = reply_bytes - 1;
> +			goto out;
>  		case AUX_I2C_REPLY_NACK:
>  			DRM_DEBUG_KMS("aux_i2c nack\n");
> -			return -EREMOTEIO;
> +			ret = -EREMOTEIO;
> +			goto out;
>  		case AUX_I2C_REPLY_DEFER:
>  			DRM_DEBUG_KMS("aux_i2c defer\n");
>  			udelay(100);
>  			break;
>  		default:
>  			DRM_ERROR("aux_i2c invalid reply 0x%02x\n", reply[0]);
> -			return -EREMOTEIO;
> +			ret = -EREMOTEIO;
> +			goto out;
>  		}
>  	}
>  
>  	DRM_ERROR("too many retries, giving up\n");
> -	return -EREMOTEIO;
> +	ret = -EREMOTEIO;
> +
> +out:
> +	ironlake_edp_panel_vdd_off(intel_dp, false);
> +	return ret;
>  }
>  
>  static int
> @@ -739,9 +749,7 @@ intel_dp_i2c_init(struct intel_dp *intel_dp,
>  	intel_dp->adapter.algo_data = &intel_dp->algo;
>  	intel_dp->adapter.dev.parent = intel_connector->base.kdev;
>  
> -	ironlake_edp_panel_vdd_on(intel_dp);
>  	ret = i2c_dp_aux_add_bus(&intel_dp->adapter);
> -	ironlake_edp_panel_vdd_off(intel_dp, false);
>  	return ret;
>  }
>  
> @@ -3498,7 +3506,6 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>  	intel_dp_init_panel_power_sequencer_registers(dev, intel_dp,
>  						      &power_seq);
>  
> -	ironlake_edp_panel_vdd_on(intel_dp);
>  	edid = drm_get_edid(connector, &intel_dp->adapter);
>  	if (edid) {
>  		if (drm_add_edid_modes(connector, edid)) {
> @@ -3530,8 +3537,6 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>  			fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
>  	}
>  
> -	ironlake_edp_panel_vdd_off(intel_dp, false);
> -
>  	intel_panel_init(&intel_connector->panel, fixed_mode);
>  	intel_panel_setup_backlight(connector);
>  
> -- 
> 1.8.3.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center