Message ID | 20180920084905.27032-2-ning.a.zhang@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | idea for optimize i915 initial time with eDP | expand |
On Thu, 20 Sep 2018, ning.a.zhang@intel.com wrote: > From: Zhang Ning <ning.a.zhang@intel.com> > > power on an eDP panel requests eDP panal fully powered off. > need to wait t11_t12 after LCDVCC is off. usually t12 is 500ms. > > code, intel_dp.c, func edp_panel_vdd_on, line 2010: > > if (!edp_have_panel_power(intel_dp)) > wait_panel_power_cycle(intel_dp); > > translate to human readable: > if panel is off; then wait. > > the wait time is (t11_t12 - power_off_duration). > > power_off_duration = (now_time - last_off_timestamp) > > when (t10_t12 > power_off_duration), a wait is requested. > otherwise not needed. > > for coldboot, panel is powered off, not powered on. > so last_off_timestamp for coldboot should be 0. > > but in code, this value is set to i915 module initial timestamp, > by: > > static void intel_dp_init_panel_power_timestamps(struct intel_dp > *intel_dp) > { > intel_dp->panel_power_off_time = ktime_get_boottime(); > intel_dp->last_power_on = jiffies; > intel_dp->last_backlight_off = jiffies; > } > > this is not real last_off_timestamp, and make i915 driver wait unnecessarily. > > to make i915 initial faster, set panel_power_off_time to (ktime_t){.tv64 > = 0} > > actully saves 200ms for coldboot. > > Signed-off-by: Zhang Ning <ning.a.zhang@intel.com> > Reviewed-off-by: Zhang, Baoli <baoli.zhang@intel.com> I can think of two scenarios where the proposed change could lead to too short a wait: 1) GOP enables *and* disables eDP. Seems very unlikely to me. 2) i915 module unload and reload. Also unlikely in an end user case, but potentially relevant for development and CI. Otherwise, your patch does seem like a good idea. I'm not sure what, if anything, we should do about the above scenarios. The current approach does seem fairly conservative. It's a possibility "get boottime" was misunderstood for time of boot rather than time *since* boot. I'll let Ville chime in as well. BR, Jani. > --- > drivers/gpu/drm/i915/intel_dp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 1193202766a2..9b985768ead6 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -5373,7 +5373,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect > > static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp) > { > - intel_dp->panel_power_off_time = ktime_get_boottime(); > + intel_dp->panel_power_off_time = ktime_set(0, 0); > intel_dp->last_power_on = jiffies; > intel_dp->last_backlight_off = jiffies; > }
On Tue, Sep 25, 2018 at 12:55:04PM +0300, Jani Nikula wrote: > On Thu, 20 Sep 2018, ning.a.zhang@intel.com wrote: > > From: Zhang Ning <ning.a.zhang@intel.com> > > > > power on an eDP panel requests eDP panal fully powered off. > > need to wait t11_t12 after LCDVCC is off. usually t12 is 500ms. > > > > code, intel_dp.c, func edp_panel_vdd_on, line 2010: > > > > if (!edp_have_panel_power(intel_dp)) > > wait_panel_power_cycle(intel_dp); > > > > translate to human readable: > > if panel is off; then wait. > > > > the wait time is (t11_t12 - power_off_duration). > > > > power_off_duration = (now_time - last_off_timestamp) > > > > when (t10_t12 > power_off_duration), a wait is requested. > > otherwise not needed. > > > > for coldboot, panel is powered off, not powered on. > > so last_off_timestamp for coldboot should be 0. > > > > but in code, this value is set to i915 module initial timestamp, > > by: > > > > static void intel_dp_init_panel_power_timestamps(struct intel_dp > > *intel_dp) > > { > > intel_dp->panel_power_off_time = ktime_get_boottime(); > > intel_dp->last_power_on = jiffies; > > intel_dp->last_backlight_off = jiffies; > > } > > > > this is not real last_off_timestamp, and make i915 driver wait unnecessarily. > > > > to make i915 initial faster, set panel_power_off_time to (ktime_t){.tv64 > > = 0} > > > > actully saves 200ms for coldboot. > > > > Signed-off-by: Zhang Ning <ning.a.zhang@intel.com> > > Reviewed-off-by: Zhang, Baoli <baoli.zhang@intel.com> > > I can think of two scenarios where the proposed change could lead to too > short a wait: > > 1) GOP enables *and* disables eDP. Seems very unlikely to me. It sure likes enabling the vdd. But I guess it usually leaves it on even if it decided to light up an external display instead. Not 100% sure though. > > 2) i915 module unload and reload. Also unlikely in an end user case, but > potentially relevant for development and CI. I think currently we may even just leave the panel on when unloading. However... 3) S3. I don't think we wait for the power cycle delay when suspending so if resume happens fast enough we'll violate the power cycle delay. Seems more likely than the other cases. Probably the best solution for all the self inflicted cases would be to wait for the power cycle delay before suspending/unloading/rebooting/whatever. We only do the reboot thing in vlv/chv for some random reason. I tried to add a global reboot notifier here: https://patchwork.freedesktop.org/patch/102739/ but I never managed to finish that work. IIRC it was suggested that we'd probably want a full blown suspend on reboot anwyay. For the GOP turned the vdd on and off again case we have no solution other than to a) trust the GOP not to do that, b) keep doing the pessimistic thing we do now.
Thank you very much for getting involved. 在 2018-09-25二的 17:53 +0300,Ville Syrjälä写道: On Tue, Sep 25, 2018 at 12:55:04PM +0300, Jani Nikula wrote: On Thu, 20 Sep 2018, ning.a.zhang@intel.com<mailto:ning.a.zhang@intel.com> wrote: From: Zhang Ning <ning.a.zhang@intel.com<mailto:ning.a.zhang@intel.com>> power on an eDP panel requests eDP panal fully powered off. need to wait t11_t12 after LCDVCC is off. usually t12 is 500ms. code, intel_dp.c, func edp_panel_vdd_on, line 2010: if (!edp_have_panel_power(intel_dp)) wait_panel_power_cycle(intel_dp); translate to human readable: if panel is off; then wait. the wait time is (t11_t12 - power_off_duration). power_off_duration = (now_time - last_off_timestamp) when (t10_t12 > power_off_duration), a wait is requested. otherwise not needed. for coldboot, panel is powered off, not powered on. so last_off_timestamp for coldboot should be 0. but in code, this value is set to i915 module initial timestamp, by: static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp) { intel_dp->panel_power_off_time = ktime_get_boottime(); intel_dp->last_power_on = jiffies; intel_dp->last_backlight_off = jiffies; } this is not real last_off_timestamp, and make i915 driver wait unnecessarily. to make i915 initial faster, set panel_power_off_time to (ktime_t){.tv64 = 0} actully saves 200ms for coldboot. Signed-off-by: Zhang Ning <ning.a.zhang@intel.com<mailto:ning.a.zhang@intel.com>> Reviewed-off-by: Zhang, Baoli <baoli.zhang@intel.com<mailto:baoli.zhang@intel.com>> I can think of two scenarios where the proposed change could lead to too short a wait: 1) GOP enables *and* disables eDP. Seems very unlikely to me. enable GOP is not possible for Golden peak, due the size of SPI NOR flash. It sure likes enabling the vdd. But I guess it usually leaves it on even if it decided to light up an external display instead. Not 100% sure though. 2) i915 module unload and reload. Also unlikely in an end user case, but potentially relevant for development and CI. I think currently we may even just leave the panel on when unloading. I much care about i915 module first load, or built-in, if i915 unnecessarily wait on eDP panel, that means longer boot time. However... 3) S3. I don't think we wait for the power cycle delay when suspending so if resume happens fast enough we'll violate the power cycle delay. Seems more likely than the other cases. Probably the best solution for all the self inflicted cases would be to wait for the power cycle delay before suspending/unloading/rebooting/whatever. We only do the reboot thing in vlv/chv for some random reason. I tried to add a global reboot notifier here: https://patchwork.freedesktop.org/patch/102739/ but I never managed to finish that work. IIRC it was suggested that we'd probably want a full blown suspend on reboot anwyay. For the GOP turned the vdd on and off again case we have no solution other than to a) trust the GOP not to do that, b) keep doing the pessimistic thing we do now. <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <div>Thank you very much for getting involved.</div> <div><br> </div> <div><br> </div> <div><br> </div> <div><br> </div> <div>在 2018-09-25二的 17:53 +0300,Ville Syrjälä写道:</div> <blockquote type="cite"> <pre>On Tue, Sep 25, 2018 at 12:55:04PM +0300, Jani Nikula wrote: <blockquote type="cite"> On Thu, 20 Sep 2018, <a href="mailto:ning.a.zhang@intel.com">ning.a.zhang@intel.com</a> wrote: <blockquote type="cite"> From: Zhang Ning <<a href="mailto:ning.a.zhang@intel.com">ning.a.zhang@intel.com</a>> power on an eDP panel requests eDP panal fully powered off. need to wait t11_t12 after LCDVCC is off. usually t12 is 500ms. code, intel_dp.c, func edp_panel_vdd_on, line 2010: if (!edp_have_panel_power(intel_dp)) wait_panel_power_cycle(intel_dp); translate to human readable: if panel is off; then wait. the wait time is (t11_t12 - power_off_duration). power_off_duration = (now_time - last_off_timestamp) when (t10_t12 > power_off_duration), a wait is requested. otherwise not needed. for coldboot, panel is powered off, not powered on. so last_off_timestamp for coldboot should be 0. but in code, this value is set to i915 module initial timestamp, by: static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp) { intel_dp->panel_power_off_time = ktime_get_boottime(); intel_dp->last_power_on = jiffies; intel_dp->last_backlight_off = jiffies; } this is not real last_off_timestamp, and make i915 driver wait unnecessarily. to make i915 initial faster, set panel_power_off_time to (ktime_t){.tv64 = 0} actully saves 200ms for coldboot. Signed-off-by: Zhang Ning <<a href="mailto:ning.a.zhang@intel.com">ning.a.zhang@intel.com</a>> Reviewed-off-by: Zhang, Baoli <<a href="mailto:baoli.zhang@intel.com">baoli.zhang@intel.com</a>> </blockquote> I can think of two scenarios where the proposed change could lead to too short a wait: 1) GOP enables *and* disables eDP. Seems very unlikely to me. </blockquote></pre> </blockquote> <div><br> </div> <div>enable GOP is not possible for Golden peak, due the size of SPI NOR flash.</div> <div><br> </div> <blockquote type="cite"> <pre> It sure likes enabling the vdd. But I guess it usually leaves it on even if it decided to light up an external display instead. Not 100% sure though. <blockquote type="cite"> 2) i915 module unload and reload. Also unlikely in an end user case, but potentially relevant for development and CI. </blockquote> I think currently we may even just leave the panel on when unloading. </pre> </blockquote> <div><br> </div> <div>I much care about i915 module first load, or built-in, if i915<object type="application/x-shockwave-flash" data="//ssl.gstatic.com/translate/sound_player2.swf" id="tts" width="18" height="18"> </object></div> <span id="result_box" class="short_text" lang="en">unnecessarily wait on eDP panel, that means longer boot time.</span> <div><br> </div> <blockquote type="cite"> <pre> However... 3) S3. I don't think we wait for the power cycle delay when suspending so if resume happens fast enough we'll violate the power cycle delay. Seems more likely than the other cases. Probably the best solution for all the self inflicted cases would be to wait for the power cycle delay before suspending/unloading/rebooting/whatever. We only do the reboot thing in vlv/chv for some random reason. I tried to add a global reboot notifier here: <a href="https://patchwork.freedesktop.org/patch/102739/">https://patchwork.freedesktop.org/patch/102739/</a> but I never managed to finish that work. IIRC it was suggested that we'd probably want a full blown suspend on reboot anwyay. For the GOP turned the vdd on and off again case we have no solution other than to a) trust the GOP not to do that, b) keep doing the pessimistic thing we do now. </pre> </blockquote> </body> </html>
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 1193202766a2..9b985768ead6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5373,7 +5373,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp) { - intel_dp->panel_power_off_time = ktime_get_boottime(); + intel_dp->panel_power_off_time = ktime_set(0, 0); intel_dp->last_power_on = jiffies; intel_dp->last_backlight_off = jiffies; }