Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-09-02 Thread Clint Taylor

On 08/27/2014 01:54 PM, Runyan, Arthur J wrote:

:-)   We pulled most of the mobile functions from the bridge chip into the main 
chip, so that same backlight code might well have been there.
 From sandybridge onwards I see that hardware will override the PWM signal to 
inactive (0 if backlight polarity is active high, 1 if active low) when PWM is 
disabled (PWM control bit 31 = 0).  I don't have anything older than 
sandybridge to look at, and of course there could always be some hidden bug 
that prevents the override from kicking in.



Just enabling/disabling the PWM control bit will reproduce the issue on 
VLV. I have not tested on other platforms.


Clint


-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, August 26, 2014 2:52 AM
To: Runyan, Arthur J
Cc: Jani Nikula; Taylor, Clinton A; Ville Syrjälä; 
Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
Enable assert

On Fri, Aug 22, 2014 at 05:12:25PM +, Runyan, Arthur J wrote:

I'll check it out.  I haven't heard any complaint about this before, but
it may be one of those things that started back on i745 and never got
documented.


Only i855 and later started to have native lvds with all the surrounding
stuff, before there's only bridge chips that did all the magic. So won't
be quite _that_ old ;-)

Cheers, Daniel



-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Friday, August 22, 2014 6:07 AM
To: Taylor, Clinton A; Ville Syrjälä; Runyan, Arthur J
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
Enable assert


+Art

On Thu, 21 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:

There is also a need to add this delay when turning off the PWM enable
bit through intel_panel_disable_backlight(). If the PWM enable bit is
turned off while the PWM signal is high then the signal remains high. If
the bit is turned off when the signal is low the PWM will remain low.
Since we don't know the current state of the PWM signal we must set the
duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.


[citation needed]

Really, I want this in the specs if this is true.


Actually it might be better if we never turn off the PWM enable bit in
intel_panel_disable_backlight() and we just use the duty cycle register
to control the PWM.


Art, any feedback on these two?

BR,
Jani.





So I guess your approach is the simplest option here.


_intel_edp_backlight_on(intel_dp);
   }

@@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
assign_final(t11_t12);
   #undef assign_final

+#define PWM_CYCLE_DELAY 5


Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
cycle here is exactly. Just one full period of the signal?



The PWM cycle in this case turns out to be 1 full cycle of the PWM
waveform though it depends on which display core clock (128 or
25Mhz(S0ix) is being used. Since we only care about the minimum elapsed
time to meet the panel specification a value of 5ms will work even
though more or less PWM cycles would take place before the BL_ENABLE is
asserted. I would prefer not to add complexity to switch between panel
timings for normal and S0ix display clock modes. How often does the
backlight get enabled while in S0ix?


Also would be nice to have a comment in the code explaining what this is
and why we need to add it to the delay.


Sure, As you may have noticed in other patches I really like comments.




   #define get_delay(field) (DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
-   intel_dp-backlight_on_delay = get_delay(t8);
+   intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3abc915..ad6fcc1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
+   unsigned long last_backlight_on;
unsigned long last_backlight_off;

struct notifier_block edp_notifier;
--
1.8.3.2

___
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


--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-09-02 Thread Runyan, Arthur J
VLV is a whole different can of worms.  Some parts of display are from before 
sanybridge, and it may have some special muxing on the backlight pins.  I won't 
be able to give any feedback on how hardware behaves there.

-Original Message-
From: Taylor, Clinton A 
Sent: Tuesday, September 02, 2014 5:27 PM
To: Runyan, Arthur J; Daniel Vetter
Cc: Jani Nikula; Ville Syrjälä; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
Enable assert

On 08/27/2014 01:54 PM, Runyan, Arthur J wrote:
 :-)   We pulled most of the mobile functions from the bridge chip into the 
 main chip, so that same backlight code might well have been there.
  From sandybridge onwards I see that hardware will override the PWM signal to 
 inactive (0 if backlight polarity is active high, 1 if active low) when PWM 
 is disabled (PWM control bit 31 = 0).  I don't have anything older than 
 sandybridge to look at, and of course there could always be some hidden bug 
 that prevents the override from kicking in.


Just enabling/disabling the PWM control bit will reproduce the issue on 
VLV. I have not tested on other platforms.

Clint

 -Original Message-
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
 Sent: Tuesday, August 26, 2014 2:52 AM
 To: Runyan, Arthur J
 Cc: Jani Nikula; Taylor, Clinton A; Ville Syrjälä; 
 Intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
 Enable assert

 On Fri, Aug 22, 2014 at 05:12:25PM +, Runyan, Arthur J wrote:
 I'll check it out.  I haven't heard any complaint about this before, but
 it may be one of those things that started back on i745 and never got
 documented.

 Only i855 and later started to have native lvds with all the surrounding
 stuff, before there's only bridge chips that did all the magic. So won't
 be quite _that_ old ;-)

 Cheers, Daniel


 -Original Message-
 From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
 Sent: Friday, August 22, 2014 6:07 AM
 To: Taylor, Clinton A; Ville Syrjälä; Runyan, Arthur J
 Cc: Intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
 Enable assert


 +Art

 On Thu, 21 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
 There is also a need to add this delay when turning off the PWM enable
 bit through intel_panel_disable_backlight(). If the PWM enable bit is
 turned off while the PWM signal is high then the signal remains high. If
 the bit is turned off when the signal is low the PWM will remain low.
 Since we don't know the current state of the PWM signal we must set the
 duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.

 [citation needed]

 Really, I want this in the specs if this is true.

 Actually it might be better if we never turn off the PWM enable bit in
 intel_panel_disable_backlight() and we just use the duty cycle register
 to control the PWM.

 Art, any feedback on these two?

 BR,
 Jani.



 So I guess your approach is the simplest option here.

   _intel_edp_backlight_on(intel_dp);
}

 @@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct 
 drm_device *dev,
   assign_final(t11_t12);
#undef assign_final

 +#define PWM_CYCLE_DELAY 5

 Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
 cycle here is exactly. Just one full period of the signal?


 The PWM cycle in this case turns out to be 1 full cycle of the PWM
 waveform though it depends on which display core clock (128 or
 25Mhz(S0ix) is being used. Since we only care about the minimum elapsed
 time to meet the panel specification a value of 5ms will work even
 though more or less PWM cycles would take place before the BL_ENABLE is
 asserted. I would prefer not to add complexity to switch between panel
 timings for normal and S0ix display clock modes. How often does the
 backlight get enabled while in S0ix?

 Also would be nice to have a comment in the code explaining what this is
 and why we need to add it to the delay.

 Sure, As you may have noticed in other patches I really like comments.


#define get_delay(field)   (DIV_ROUND_UP(final.field, 10))
   intel_dp-panel_power_up_delay = get_delay(t1_t3);
 - intel_dp-backlight_on_delay = get_delay(t8);
 + intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
   intel_dp-backlight_off_delay = get_delay(t9);
   intel_dp-panel_power_down_delay = get_delay(t10);
   intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 3abc915..ad6fcc1 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -556,6 +556,7 @@ struct intel_dp {
   bool want_panel_vdd;
   unsigned long last_power_cycle;
   unsigned long last_power_on;
 + unsigned long

Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-27 Thread Runyan, Arthur J
:-)   We pulled most of the mobile functions from the bridge chip into the main 
chip, so that same backlight code might well have been there.
From sandybridge onwards I see that hardware will override the PWM signal to 
inactive (0 if backlight polarity is active high, 1 if active low) when PWM is 
disabled (PWM control bit 31 = 0).  I don't have anything older than 
sandybridge to look at, and of course there could always be some hidden bug 
that prevents the override from kicking in. 

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, August 26, 2014 2:52 AM
To: Runyan, Arthur J
Cc: Jani Nikula; Taylor, Clinton A; Ville Syrjälä; 
Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
Enable assert

On Fri, Aug 22, 2014 at 05:12:25PM +, Runyan, Arthur J wrote:
 I'll check it out.  I haven't heard any complaint about this before, but
 it may be one of those things that started back on i745 and never got
 documented. 

Only i855 and later started to have native lvds with all the surrounding
stuff, before there's only bridge chips that did all the magic. So won't
be quite _that_ old ;-)

Cheers, Daniel

 
 -Original Message-
 From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
 Sent: Friday, August 22, 2014 6:07 AM
 To: Taylor, Clinton A; Ville Syrjälä; Runyan, Arthur J
 Cc: Intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
 Enable assert
 
 
 +Art
 
 On Thu, 21 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
  There is also a need to add this delay when turning off the PWM enable 
  bit through intel_panel_disable_backlight(). If the PWM enable bit is 
  turned off while the PWM signal is high then the signal remains high. If 
  the bit is turned off when the signal is low the PWM will remain low. 
  Since we don't know the current state of the PWM signal we must set the 
  duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.
 
 [citation needed]
 
 Really, I want this in the specs if this is true.
 
  Actually it might be better if we never turn off the PWM enable bit in 
  intel_panel_disable_backlight() and we just use the duty cycle register 
  to control the PWM.
 
 Art, any feedback on these two?
 
 BR,
 Jani.
 
 
 
  So I guess your approach is the simplest option here.
 
_intel_edp_backlight_on(intel_dp);
}
 
  @@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct 
  drm_device *dev,
assign_final(t11_t12);
#undef assign_final
 
  +#define PWM_CYCLE_DELAY 5
 
  Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
  cycle here is exactly. Just one full period of the signal?
 
 
  The PWM cycle in this case turns out to be 1 full cycle of the PWM 
  waveform though it depends on which display core clock (128 or 
  25Mhz(S0ix) is being used. Since we only care about the minimum elapsed 
  time to meet the panel specification a value of 5ms will work even 
  though more or less PWM cycles would take place before the BL_ENABLE is 
  asserted. I would prefer not to add complexity to switch between panel 
  timings for normal and S0ix display clock modes. How often does the 
  backlight get enabled while in S0ix?
 
  Also would be nice to have a comment in the code explaining what this is
  and why we need to add it to the delay.
 
  Sure, As you may have noticed in other patches I really like comments.
 
 
#define get_delay(field)(DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
  - intel_dp-backlight_on_delay = get_delay(t8);
  + intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index 3abc915..ad6fcc1 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
  + unsigned long last_backlight_on;
unsigned long last_backlight_off;
 
struct notifier_block edp_notifier;
  --
  1.8.3.2
 
  ___
  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
 
 -- 
 Jani Nikula, Intel Open Source Technology Center
 ___
 Intel-gfx mailing list
 Intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-26 Thread Daniel Vetter
On Fri, Aug 22, 2014 at 05:12:25PM +, Runyan, Arthur J wrote:
 I'll check it out.  I haven't heard any complaint about this before, but
 it may be one of those things that started back on i745 and never got
 documented. 

Only i855 and later started to have native lvds with all the surrounding
stuff, before there's only bridge chips that did all the magic. So won't
be quite _that_ old ;-)

Cheers, Daniel

 
 -Original Message-
 From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
 Sent: Friday, August 22, 2014 6:07 AM
 To: Taylor, Clinton A; Ville Syrjälä; Runyan, Arthur J
 Cc: Intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
 Enable assert
 
 
 +Art
 
 On Thu, 21 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
  There is also a need to add this delay when turning off the PWM enable 
  bit through intel_panel_disable_backlight(). If the PWM enable bit is 
  turned off while the PWM signal is high then the signal remains high. If 
  the bit is turned off when the signal is low the PWM will remain low. 
  Since we don't know the current state of the PWM signal we must set the 
  duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.
 
 [citation needed]
 
 Really, I want this in the specs if this is true.
 
  Actually it might be better if we never turn off the PWM enable bit in 
  intel_panel_disable_backlight() and we just use the duty cycle register 
  to control the PWM.
 
 Art, any feedback on these two?
 
 BR,
 Jani.
 
 
 
  So I guess your approach is the simplest option here.
 
_intel_edp_backlight_on(intel_dp);
}
 
  @@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct 
  drm_device *dev,
assign_final(t11_t12);
#undef assign_final
 
  +#define PWM_CYCLE_DELAY 5
 
  Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
  cycle here is exactly. Just one full period of the signal?
 
 
  The PWM cycle in this case turns out to be 1 full cycle of the PWM 
  waveform though it depends on which display core clock (128 or 
  25Mhz(S0ix) is being used. Since we only care about the minimum elapsed 
  time to meet the panel specification a value of 5ms will work even 
  though more or less PWM cycles would take place before the BL_ENABLE is 
  asserted. I would prefer not to add complexity to switch between panel 
  timings for normal and S0ix display clock modes. How often does the 
  backlight get enabled while in S0ix?
 
  Also would be nice to have a comment in the code explaining what this is
  and why we need to add it to the delay.
 
  Sure, As you may have noticed in other patches I really like comments.
 
 
#define get_delay(field)(DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
  - intel_dp-backlight_on_delay = get_delay(t8);
  + intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index 3abc915..ad6fcc1 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
  + unsigned long last_backlight_on;
unsigned long last_backlight_off;
 
struct notifier_block edp_notifier;
  --
  1.8.3.2
 
  ___
  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
 
 -- 
 Jani Nikula, Intel Open Source Technology Center
 ___
 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


Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-22 Thread Ville Syrjälä
On Thu, Aug 21, 2014 at 10:23:43AM -0700, Clint Taylor wrote:
 On 08/20/2014 04:23 AM, Ville Syrjälä wrote:
  On Mon, Aug 18, 2014 at 01:48:35PM -0700, clinton.a.tay...@intel.com wrote:
  From: Clint Taylor clinton.a.tay...@intel.com
 
  Backlight on delay uses PWM enable time to seperate PWM to
  backlight enable assert. Previous time difference used timing
  from VDD enable which occur several seconds before resulting
  in PWM starting 5ms after backlight enable. Changes to backlight
duty cycle take affect at the end of the current PWM cycle.
  Measured time for the PWM cycle is 5ms. 5 additional ms must be
  added to the backlight_on_delay to get correct VBT timing of
  PWM to backlight enable assert.
 
  V2: Rebase to Jani Nikula backlight power patch 1/4
 
  Change-Id: I2982f9785d92e8d64c04ca25c8bd4c5d1dc8067c
  Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
  ---
drivers/gpu/drm/i915/intel_dp.c  | 6 --
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_dp.c 
  b/drivers/gpu/drm/i915/intel_dp.c
  index d8baf60..aed923b 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp 
  *intel_dp)
 
static void wait_backlight_on(struct intel_dp *intel_dp)
{
  -  wait_remaining_ms_from_jiffies(intel_dp-last_power_on,
  +  wait_remaining_ms_from_jiffies(intel_dp-last_backlight_on,
intel_dp-backlight_on_delay);
}
 
  @@ -1418,6 +1418,7 @@ void intel_edp_backlight_on(struct intel_dp 
  *intel_dp)
 DRM_DEBUG_KMS(\n);
 
 intel_panel_enable_backlight(intel_dp-attached_connector);
  +  intel_dp-last_backlight_on = jiffies;
 
  Seems to me we should just have a msleep(PWM_CYCLE_DELAY) here since
  (assuming I understood correctly) only the PWM cycle time is important
  between these two steps, and the t8 (vbt spec says t7 actually) is
  relevant only from end of link training to backlight on.
 
 
 The driver has overloaded both T8 and T9 VBT timing entries. The eDP 
 specification really doesn't have timing data defined for this 
 requirement, but the panel manufacturers have it in their panel 
 specification and they use various names like (Te, t17, etc...) for this 
 delay.
 
  Hmm, no actually your idea might be better since on VLV/CHV we turn the
  pipe on after link training, and I assume t7/t8 should really start
  counting from the pipe on on those platforms. So I guess the most
  appropriate solution might be somehting like
 
{
  intel_dp-last_backlight_on = jiffies;
  intel_panel_enable_backlight(intel_dp-attached_connector);
  msleep(POWER_CYCLE_DELAY);
  _intel_edp_backlight_on(intel_dp);
}
 
  But I'm not sure the distinction makes any difference since
  intel_panel_enable_backlight() shouldn't take a significant amount of
  time, and msleep() is itself rather inaccurate.
 
 
 There is also a need to add this delay when turning off the PWM enable 
 bit through intel_panel_disable_backlight(). If the PWM enable bit is 
 turned off while the PWM signal is high then the signal remains high. If 
 the bit is turned off when the signal is low the PWM will remain low. 
 Since we don't know the current state of the PWM signal we must set the 
 duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.
 
 Actually it might be better if we never turn off the PWM enable bit in 
 intel_panel_disable_backlight() and we just use the duty cycle register 
 to control the PWM.
 
  So I guess your approach is the simplest option here.
 
 _intel_edp_backlight_on(intel_dp);
}
 
  @@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct 
  drm_device *dev,
 assign_final(t11_t12);
#undef assign_final
 
  +#define PWM_CYCLE_DELAY 5
 
  Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
  cycle here is exactly. Just one full period of the signal?
 
 
 The PWM cycle in this case turns out to be 1 full cycle of the PWM 
 waveform though it depends on which display core clock (128 or 
 25Mhz(S0ix) is being used. Since we only care about the minimum elapsed 
 time to meet the panel specification a value of 5ms will work even 
 though more or less PWM cycles would take place before the BL_ENABLE is 
 asserted. I would prefer not to add complexity to switch between panel 
 timings for normal and S0ix display clock modes. How often does the 
 backlight get enabled while in S0ix?

I'm not sure how this could even be a problem for s0ix. The driver would
be suspended by the time we enter s0ix.

I'm more worried about other platforms that may have different pwm
cycle. So it seems to me that we should calculate the pwm cycle as
DIV_ROUND_UP(1000, intel_hrawclk()), assuming it's hrawclk instead of
cdclk that's used (which is the impression I get from the docs).

 
  Also would be nice to have a 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-22 Thread Jani Nikula

+Art

On Thu, 21 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
 There is also a need to add this delay when turning off the PWM enable 
 bit through intel_panel_disable_backlight(). If the PWM enable bit is 
 turned off while the PWM signal is high then the signal remains high. If 
 the bit is turned off when the signal is low the PWM will remain low. 
 Since we don't know the current state of the PWM signal we must set the 
 duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.

[citation needed]

Really, I want this in the specs if this is true.

 Actually it might be better if we never turn off the PWM enable bit in 
 intel_panel_disable_backlight() and we just use the duty cycle register 
 to control the PWM.

Art, any feedback on these two?

BR,
Jani.



 So I guess your approach is the simplest option here.

 _intel_edp_backlight_on(intel_dp);
   }

 @@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct 
 drm_device *dev,
 assign_final(t11_t12);
   #undef assign_final

 +#define PWM_CYCLE_DELAY 5

 Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
 cycle here is exactly. Just one full period of the signal?


 The PWM cycle in this case turns out to be 1 full cycle of the PWM 
 waveform though it depends on which display core clock (128 or 
 25Mhz(S0ix) is being used. Since we only care about the minimum elapsed 
 time to meet the panel specification a value of 5ms will work even 
 though more or less PWM cycles would take place before the BL_ENABLE is 
 asserted. I would prefer not to add complexity to switch between panel 
 timings for normal and S0ix display clock modes. How often does the 
 backlight get enabled while in S0ix?

 Also would be nice to have a comment in the code explaining what this is
 and why we need to add it to the delay.

 Sure, As you may have noticed in other patches I really like comments.


   #define get_delay(field)  (DIV_ROUND_UP(final.field, 10))
 intel_dp-panel_power_up_delay = get_delay(t1_t3);
 -   intel_dp-backlight_on_delay = get_delay(t8);
 +   intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
 intel_dp-backlight_off_delay = get_delay(t9);
 intel_dp-panel_power_down_delay = get_delay(t10);
 intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 3abc915..ad6fcc1 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -556,6 +556,7 @@ struct intel_dp {
 bool want_panel_vdd;
 unsigned long last_power_cycle;
 unsigned long last_power_on;
 +   unsigned long last_backlight_on;
 unsigned long last_backlight_off;

 struct notifier_block edp_notifier;
 --
 1.8.3.2

 ___
 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

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-22 Thread Runyan, Arthur J
I'll check it out.  I haven't heard any complaint about this before, but it may 
be one of those things that started back on i745 and never got documented. 

-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
Sent: Friday, August 22, 2014 6:07 AM
To: Taylor, Clinton A; Ville Syrjälä; Runyan, Arthur J
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL 
Enable assert


+Art

On Thu, 21 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
 There is also a need to add this delay when turning off the PWM enable 
 bit through intel_panel_disable_backlight(). If the PWM enable bit is 
 turned off while the PWM signal is high then the signal remains high. If 
 the bit is turned off when the signal is low the PWM will remain low. 
 Since we don't know the current state of the PWM signal we must set the 
 duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.

[citation needed]

Really, I want this in the specs if this is true.

 Actually it might be better if we never turn off the PWM enable bit in 
 intel_panel_disable_backlight() and we just use the duty cycle register 
 to control the PWM.

Art, any feedback on these two?

BR,
Jani.



 So I guess your approach is the simplest option here.

 _intel_edp_backlight_on(intel_dp);
   }

 @@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct 
 drm_device *dev,
 assign_final(t11_t12);
   #undef assign_final

 +#define PWM_CYCLE_DELAY 5

 Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
 cycle here is exactly. Just one full period of the signal?


 The PWM cycle in this case turns out to be 1 full cycle of the PWM 
 waveform though it depends on which display core clock (128 or 
 25Mhz(S0ix) is being used. Since we only care about the minimum elapsed 
 time to meet the panel specification a value of 5ms will work even 
 though more or less PWM cycles would take place before the BL_ENABLE is 
 asserted. I would prefer not to add complexity to switch between panel 
 timings for normal and S0ix display clock modes. How often does the 
 backlight get enabled while in S0ix?

 Also would be nice to have a comment in the code explaining what this is
 and why we need to add it to the delay.

 Sure, As you may have noticed in other patches I really like comments.


   #define get_delay(field)  (DIV_ROUND_UP(final.field, 10))
 intel_dp-panel_power_up_delay = get_delay(t1_t3);
 -   intel_dp-backlight_on_delay = get_delay(t8);
 +   intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
 intel_dp-backlight_off_delay = get_delay(t9);
 intel_dp-panel_power_down_delay = get_delay(t10);
 intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 3abc915..ad6fcc1 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -556,6 +556,7 @@ struct intel_dp {
 bool want_panel_vdd;
 unsigned long last_power_cycle;
 unsigned long last_power_on;
 +   unsigned long last_backlight_on;
 unsigned long last_backlight_off;

 struct notifier_block edp_notifier;
 --
 1.8.3.2

 ___
 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

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-21 Thread Clint Taylor

On 08/20/2014 04:23 AM, Ville Syrjälä wrote:

On Mon, Aug 18, 2014 at 01:48:35PM -0700, clinton.a.tay...@intel.com wrote:

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

Backlight on delay uses PWM enable time to seperate PWM to
backlight enable assert. Previous time difference used timing
from VDD enable which occur several seconds before resulting
in PWM starting 5ms after backlight enable. Changes to backlight
  duty cycle take affect at the end of the current PWM cycle.
Measured time for the PWM cycle is 5ms. 5 additional ms must be
added to the backlight_on_delay to get correct VBT timing of
PWM to backlight enable assert.

V2: Rebase to Jani Nikula backlight power patch 1/4

Change-Id: I2982f9785d92e8d64c04ca25c8bd4c5d1dc8067c
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c  | 6 --
  drivers/gpu/drm/i915/intel_drv.h | 1 +
  2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d8baf60..aed923b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp 
*intel_dp)

  static void wait_backlight_on(struct intel_dp *intel_dp)
  {
-   wait_remaining_ms_from_jiffies(intel_dp-last_power_on,
+   wait_remaining_ms_from_jiffies(intel_dp-last_backlight_on,
   intel_dp-backlight_on_delay);
  }

@@ -1418,6 +1418,7 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
DRM_DEBUG_KMS(\n);

intel_panel_enable_backlight(intel_dp-attached_connector);
+   intel_dp-last_backlight_on = jiffies;


Seems to me we should just have a msleep(PWM_CYCLE_DELAY) here since
(assuming I understood correctly) only the PWM cycle time is important
between these two steps, and the t8 (vbt spec says t7 actually) is
relevant only from end of link training to backlight on.



The driver has overloaded both T8 and T9 VBT timing entries. The eDP 
specification really doesn't have timing data defined for this 
requirement, but the panel manufacturers have it in their panel 
specification and they use various names like (Te, t17, etc...) for this 
delay.



Hmm, no actually your idea might be better since on VLV/CHV we turn the
pipe on after link training, and I assume t7/t8 should really start
counting from the pipe on on those platforms. So I guess the most
appropriate solution might be somehting like

  {
intel_dp-last_backlight_on = jiffies;
intel_panel_enable_backlight(intel_dp-attached_connector);
msleep(POWER_CYCLE_DELAY);
_intel_edp_backlight_on(intel_dp);
  }

But I'm not sure the distinction makes any difference since
intel_panel_enable_backlight() shouldn't take a significant amount of
time, and msleep() is itself rather inaccurate.



There is also a need to add this delay when turning off the PWM enable 
bit through intel_panel_disable_backlight(). If the PWM enable bit is 
turned off while the PWM signal is high then the signal remains high. If 
the bit is turned off when the signal is low the PWM will remain low. 
Since we don't know the current state of the PWM signal we must set the 
duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.


Actually it might be better if we never turn off the PWM enable bit in 
intel_panel_disable_backlight() and we just use the duty cycle register 
to control the PWM.



So I guess your approach is the simplest option here.


_intel_edp_backlight_on(intel_dp);
  }

@@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
assign_final(t11_t12);
  #undef assign_final

+#define PWM_CYCLE_DELAY 5


Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
cycle here is exactly. Just one full period of the signal?



The PWM cycle in this case turns out to be 1 full cycle of the PWM 
waveform though it depends on which display core clock (128 or 
25Mhz(S0ix) is being used. Since we only care about the minimum elapsed 
time to meet the panel specification a value of 5ms will work even 
though more or less PWM cycles would take place before the BL_ENABLE is 
asserted. I would prefer not to add complexity to switch between panel 
timings for normal and S0ix display clock modes. How often does the 
backlight get enabled while in S0ix?



Also would be nice to have a comment in the code explaining what this is
and why we need to add it to the delay.


Sure, As you may have noticed in other patches I really like comments.




  #define get_delay(field)  (DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
-   intel_dp-backlight_on_delay = get_delay(t8);
+   intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-20 Thread Ville Syrjälä
On Mon, Aug 18, 2014 at 01:48:35PM -0700, clinton.a.tay...@intel.com wrote:
 From: Clint Taylor clinton.a.tay...@intel.com
 
 Backlight on delay uses PWM enable time to seperate PWM to
 backlight enable assert. Previous time difference used timing
 from VDD enable which occur several seconds before resulting
 in PWM starting 5ms after backlight enable. Changes to backlight
  duty cycle take affect at the end of the current PWM cycle.
 Measured time for the PWM cycle is 5ms. 5 additional ms must be
 added to the backlight_on_delay to get correct VBT timing of
 PWM to backlight enable assert.
 
 V2: Rebase to Jani Nikula backlight power patch 1/4
 
 Change-Id: I2982f9785d92e8d64c04ca25c8bd4c5d1dc8067c
 Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
 ---
  drivers/gpu/drm/i915/intel_dp.c  | 6 --
  drivers/gpu/drm/i915/intel_drv.h | 1 +
  2 files changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index d8baf60..aed923b 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp 
 *intel_dp)
  
  static void wait_backlight_on(struct intel_dp *intel_dp)
  {
 - wait_remaining_ms_from_jiffies(intel_dp-last_power_on,
 + wait_remaining_ms_from_jiffies(intel_dp-last_backlight_on,
  intel_dp-backlight_on_delay);
  }
  
 @@ -1418,6 +1418,7 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
   DRM_DEBUG_KMS(\n);
  
   intel_panel_enable_backlight(intel_dp-attached_connector);
 + intel_dp-last_backlight_on = jiffies;

Seems to me we should just have a msleep(PWM_CYCLE_DELAY) here since
(assuming I understood correctly) only the PWM cycle time is important
between these two steps, and the t8 (vbt spec says t7 actually) is
relevant only from end of link training to backlight on.

Hmm, no actually your idea might be better since on VLV/CHV we turn the
pipe on after link training, and I assume t7/t8 should really start
counting from the pipe on on those platforms. So I guess the most
appropriate solution might be somehting like

 {
   intel_dp-last_backlight_on = jiffies;
   intel_panel_enable_backlight(intel_dp-attached_connector);
   msleep(POWER_CYCLE_DELAY);
   _intel_edp_backlight_on(intel_dp);
 }

But I'm not sure the distinction makes any difference since
intel_panel_enable_backlight() shouldn't take a significant amount of
time, and msleep() is itself rather inaccurate.

So I guess your approach is the simplest option here.

   _intel_edp_backlight_on(intel_dp);
  }
  
 @@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
 *dev,
   assign_final(t11_t12);
  #undef assign_final
  
 +#define PWM_CYCLE_DELAY 5

Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
cycle here is exactly. Just one full period of the signal?

Also would be nice to have a comment in the code explaining what this is
and why we need to add it to the delay.

  #define get_delay(field) (DIV_ROUND_UP(final.field, 10))
   intel_dp-panel_power_up_delay = get_delay(t1_t3);
 - intel_dp-backlight_on_delay = get_delay(t8);
 + intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
   intel_dp-backlight_off_delay = get_delay(t9);
   intel_dp-panel_power_down_delay = get_delay(t10);
   intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 3abc915..ad6fcc1 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -556,6 +556,7 @@ struct intel_dp {
   bool want_panel_vdd;
   unsigned long last_power_cycle;
   unsigned long last_power_on;
 + unsigned long last_backlight_on;
   unsigned long last_backlight_off;
  
   struct notifier_block edp_notifier;
 -- 
 1.8.3.2
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-18 Thread clinton . a . taylor
From: Clint Taylor clinton.a.tay...@intel.com

Backlight on delay uses PWM enable time to seperate PWM to
backlight enable assert. Previous time difference used timing
from VDD enable which occur several seconds before resulting
in PWM starting 5ms after backlight enable. Changes to backlight
 duty cycle take affect at the end of the current PWM cycle.
Measured time for the PWM cycle is 5ms. 5 additional ms must be
added to the backlight_on_delay to get correct VBT timing of
PWM to backlight enable assert.

V2: Rebase to Jani Nikula backlight power patch 1/4

Change-Id: I2982f9785d92e8d64c04ca25c8bd4c5d1dc8067c
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c  | 6 --
 drivers/gpu/drm/i915/intel_drv.h | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d8baf60..aed923b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp 
*intel_dp)
 
 static void wait_backlight_on(struct intel_dp *intel_dp)
 {
-   wait_remaining_ms_from_jiffies(intel_dp-last_power_on,
+   wait_remaining_ms_from_jiffies(intel_dp-last_backlight_on,
   intel_dp-backlight_on_delay);
 }
 
@@ -1418,6 +1418,7 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
DRM_DEBUG_KMS(\n);
 
intel_panel_enable_backlight(intel_dp-attached_connector);
+   intel_dp-last_backlight_on = jiffies;
_intel_edp_backlight_on(intel_dp);
 }
 
@@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
assign_final(t11_t12);
 #undef assign_final
 
+#define PWM_CYCLE_DELAY 5
 #define get_delay(field)   (DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
-   intel_dp-backlight_on_delay = get_delay(t8);
+   intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3abc915..ad6fcc1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
+   unsigned long last_backlight_on;
unsigned long last_backlight_off;
 
struct notifier_block edp_notifier;
-- 
1.8.3.2

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


Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-15 Thread Jani Nikula
On Fri, 15 Aug 2014, clinton.a.tay...@intel.com wrote:
 From: Clint Taylor clinton.a.tay...@intel.com

 Backlight on delay uses PWM enable time to seperate PWM to
 backlight enable assert. Previous time difference used timing
 from VDD enable which occur several seconds before resulting
 in PWM starting 5ms after backlight enable. Changes to backlight
  duty cycle take affect at the end of the current PWM cycle.
 Measured time for the PWM cycle is 5ms. 5 additional ms must be
 added to the backlight_on_delay to get correct VBT timing of
 PWM to backlight enable assert.

The patch seems sane, but I'd like you to rebase this on top of patch
1/4 of my backlight series [1] so I can queue them both to
drm-intel-fixes. Then we'll have fewer conflicts with the rest of the
backlight series going forward.

Hint hint, I'd also appreciate review of my backlight series. ;)

BR,
Jani.


[1] 
http://mid.gmane.org/e7a47b50ed0f25cafdc26711fc09561ea8af3b81.1407849872.git.jani.nik...@intel.com



 Change-Id: I484999a597fd84dacf4cf99a168ec9ba4bb6ff11
 Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
 ---
  drivers/gpu/drm/i915/intel_dp.c  | 6 --
  drivers/gpu/drm/i915/intel_drv.h | 1 +
  2 files changed, 5 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index e5ada4f..c59ccdb 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp 
 *intel_dp)
  
  static void wait_backlight_on(struct intel_dp *intel_dp)
  {
 - wait_remaining_ms_from_jiffies(intel_dp-last_power_on,
 + wait_remaining_ms_from_jiffies(intel_dp-last_backlight_on,
  intel_dp-backlight_on_delay);
  }
  
 @@ -1398,6 +1398,7 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
   DRM_DEBUG_KMS(\n);
  
   intel_panel_enable_backlight(intel_dp-attached_connector);
 + intel_dp-last_backlight_on = jiffies;
  
   /*
* If we enable the backlight right away following a panel power
 @@ -4243,9 +4244,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
 *dev,
   assign_final(t11_t12);
  #undef assign_final
  
 +#define PWM_CYCLE_DELAY 5
  #define get_delay(field) (DIV_ROUND_UP(final.field, 10))
   intel_dp-panel_power_up_delay = get_delay(t1_t3);
 - intel_dp-backlight_on_delay = get_delay(t8);
 + intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
   intel_dp-backlight_off_delay = get_delay(t9);
   intel_dp-panel_power_down_delay = get_delay(t10);
   intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 3abc915..ad6fcc1 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -556,6 +556,7 @@ struct intel_dp {
   bool want_panel_vdd;
   unsigned long last_power_cycle;
   unsigned long last_power_on;
 + unsigned long last_backlight_on;
   unsigned long last_backlight_off;
  
   struct notifier_block edp_notifier;
 -- 
 1.8.3.2

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

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

2014-08-14 Thread clinton . a . taylor
From: Clint Taylor clinton.a.tay...@intel.com

Backlight on delay uses PWM enable time to seperate PWM to
backlight enable assert. Previous time difference used timing
from VDD enable which occur several seconds before resulting
in PWM starting 5ms after backlight enable. Changes to backlight
 duty cycle take affect at the end of the current PWM cycle.
Measured time for the PWM cycle is 5ms. 5 additional ms must be
added to the backlight_on_delay to get correct VBT timing of
PWM to backlight enable assert.

Change-Id: I484999a597fd84dacf4cf99a168ec9ba4bb6ff11
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c  | 6 --
 drivers/gpu/drm/i915/intel_drv.h | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e5ada4f..c59ccdb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp 
*intel_dp)
 
 static void wait_backlight_on(struct intel_dp *intel_dp)
 {
-   wait_remaining_ms_from_jiffies(intel_dp-last_power_on,
+   wait_remaining_ms_from_jiffies(intel_dp-last_backlight_on,
   intel_dp-backlight_on_delay);
 }
 
@@ -1398,6 +1398,7 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
DRM_DEBUG_KMS(\n);
 
intel_panel_enable_backlight(intel_dp-attached_connector);
+   intel_dp-last_backlight_on = jiffies;
 
/*
 * If we enable the backlight right away following a panel power
@@ -4243,9 +4244,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
assign_final(t11_t12);
 #undef assign_final
 
+#define PWM_CYCLE_DELAY 5
 #define get_delay(field)   (DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
-   intel_dp-backlight_on_delay = get_delay(t8);
+   intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3abc915..ad6fcc1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
+   unsigned long last_backlight_on;
unsigned long last_backlight_off;
 
struct notifier_block edp_notifier;
-- 
1.8.3.2

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