From: "Kumar, Shobhit" <shobhit.kumar@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Shobhit Kumar" <kumar@shobhit.info>
Cc: Shobhit Kumar <shobhit.kumar@intel.com>,
intel-gfx <Intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Wait for PP cycle delay only if panel is in power off sequence
Date: Thu, 10 Dec 2015 15:01:02 +0530 [thread overview]
Message-ID: <56694656.8040607@linux.intel.com> (raw)
In-Reply-To: <20151209160517.GH4437@intel.com>
On 12/09/2015 09:35 PM, Ville Syrjälä wrote:
> On Wed, Dec 09, 2015 at 08:59:26PM +0530, Shobhit Kumar wrote:
>> On Wed, Dec 9, 2015 at 8:34 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>>> On Wed, Dec 09, 2015 at 08:07:10PM +0530, Shobhit Kumar wrote:
>>>> On Wed, Dec 9, 2015 at 7:27 PM, Ville Syrjälä
>>>> <ville.syrjala@linux.intel.com> wrote:
>>>>> On Wed, Dec 09, 2015 at 06:51:48PM +0530, Shobhit Kumar wrote:
>>>>>> During resume, while turning the EDP panel power on, we need not wait
>>>>>> blindly for panel_power_cycle_delay. Check if panel power down sequence
>>>>>> in progress and then only wait. This improves our resume time significantly.
>>>>>>
>>>>>> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
>>>>>> ---
>>>>>> drivers/gpu/drm/i915/intel_dp.c | 17 ++++++++++++++++-
>>>>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>>>>>> index f335c92..10ec669 100644
>>>>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>>>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>>>>> @@ -617,6 +617,20 @@ static bool edp_have_panel_power(struct intel_dp *intel_dp)
>>>>>> return (I915_READ(_pp_stat_reg(intel_dp)) & PP_ON) != 0;
>>>>>> }
>>>>>>
>>>>>> +static bool edp_panel_off_seq(struct intel_dp *intel_dp)
>>>>>> +{
>>>>>> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>>>>>> + struct drm_i915_private *dev_priv = dev->dev_private;
>>>>>> +
>>>>>> + lockdep_assert_held(&dev_priv->pps_mutex);
>>>>>> +
>>>>>> + if (IS_VALLEYVIEW(dev) &&
>>>>>> + intel_dp->pps_pipe == INVALID_PIPE)
>>>>>> + return false;
>>>>>> +
>>>>>> + return (I915_READ(_pp_stat_reg(intel_dp)) & PP_SEQUENCE_POWER_DOWN) != 0;
>>>>>> +}
>>>>>
>>>>> This doens't make sense to me. The power down cycle may have
>>>>> completed just before, and so this would claim we don't have to
>>>>> wait for the power_cycle_delay.
>>>>
>>>> Not sure I understand your concern correctly. You are right, power
>>>> down cycle may have completed just before and if it has then we don't
>>>> need to wait. But in case the power down cycle is in progress as per
>>>> internal state, then we need to wait for it to complete. This will
>>>> happen for example in non-suspend disable path and will be handled
>>>> correctly. In case of actual suspend/resume, this would have
>>>> successfully completed and will skip the wait as it is not needed
>>>> before enabling panel power.
>>>>
>>>>>
>>>>>> +
>>>>>> static bool edp_have_panel_vdd(struct intel_dp *intel_dp)
>>>>>> {
>>>>>> struct drm_device *dev = intel_dp_to_dev(intel_dp);
>>>>>> @@ -2025,7 +2039,8 @@ static void edp_panel_on(struct intel_dp *intel_dp)
>>>>>> port_name(dp_to_dig_port(intel_dp)->port)))
>>>>>> return;
>>>>>>
>>>>>> - wait_panel_power_cycle(intel_dp);
>>>>>> + if (edp_panel_off_seq(intel_dp))
>>>>>> + wait_panel_power_cycle(intel_dp);
>>>
>>> Looking in from the side, I have no idea what this is meant to do. At
>>> the very least you need your explanatory paragraph here which would
>>> include what exactly you are waiting for at the start of edp_panel_on
>>> (and please try and find a better name for edp_panel_off_seq()).
>>
>> I will add a comment. Basically I am not additionally waiting, but
>> converting the wait which was already there to a conditional wait. The
>> edp_panel_off_seq, checks if panel power down sequence is in progress.
>> In that case we need to wait for the panel power cycle delay. If it is
>> not in that sequence, there is no need to wait. I will make an attempt
>> again on the naming in next patch update.
>
> As far I remeber you need to wait for power_cycle_delay between power
> down cycle and power up cycle. You're trying to throw that wait away
> entirely, unless the function happens get called while the power down
Yes you are right and I realize I made a mistake in my patch which is
not checking PP_CYCLE_DELAY_ACTIVE bit.
> cycle is still in progress. We should already optimize away redundant
> waits by tracking the end of the power down cycle with the jiffies
> tracking.
>
> Actually looking at the code the power_cycle_delay gets counted from
> the start of the last power down cycle, so supposedly it's always at
> least as long as the power down cycle, and typically it's quite a bit
> longer that that. But that doesn't change the fact that you can't
> just skip it because the power down cycle delay happened to end
> already.
>
> So what we do now is:
> 1. initiate power down cycle
> 2. last_power_cycle=jiffies
> 3. wait for power down (I suppose this actually waits
> until the power down delay has passed since that's
> programmes into the PPS).
> 4. wait for power_cycle_delay from last_power_cycle
> 5. initiate power up cycle
>
> I think with your patch step 4 would always be skipped since the
> power down cycle has already ended, and then we fail to honor the
> power cycle delay.
Yes, I agree. I missed checking for PP_CYCLE_DELAY_ACTIVE. Adding that
check will take care of this scenario I guess ?
Regards
Shobhit
>
> Actually the power_cycle delay also gets programmed into the PPS so I
> supose it would enforce the wait anyway when you initiate the power
> up cycle (unless the PPS got totally reset due to power wells etc.,
> which does seem like a real concern. The even bigger concern is the
> vdd force bit for which the PPS does no enforcement.
>
> The power_down_delay handling seems a bit wonky. We only wait for it
> when turning off the port. I guess I would need to go re-read the spec
> to figure out what it's meant to protect anyway.
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-12-10 9:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-07 20:28 [PATCH] drm/i915: Suspend resume timing optimization abhay.kumar
2015-12-07 20:52 ` Paulo Zanoni
2015-12-07 22:19 ` Kumar, Abhay
2015-12-09 10:55 ` Kumar, Shobhit
2015-12-09 12:12 ` Ville Syrjälä
2015-12-09 12:40 ` Kumar, Shobhit
2015-12-09 13:21 ` [PATCH] drm/i915: Wait for PP cycle delay only if panel is in power off sequence Shobhit Kumar
2015-12-09 13:29 ` Kumar, Shobhit
2015-12-09 13:57 ` Ville Syrjälä
2015-12-09 14:37 ` Shobhit Kumar
2015-12-09 15:04 ` Chris Wilson
2015-12-09 15:29 ` Shobhit Kumar
2015-12-09 16:05 ` Ville Syrjälä
2015-12-10 9:31 ` Kumar, Shobhit [this message]
2015-12-10 9:50 ` Daniel Vetter
2015-12-10 10:18 ` Kumar, Shobhit
2015-12-10 10:58 ` Thulasimani, Sivakumar
2015-12-10 13:15 ` Ville Syrjälä
2015-12-10 13:38 ` Ville Syrjälä
2015-12-10 14:39 ` Thulasimani, Sivakumar
2015-12-10 15:02 ` Ville Syrjälä
2015-12-11 11:25 ` Thulasimani, Sivakumar
2015-12-11 11:41 ` Kumar, Shobhit
2015-12-11 17:00 ` Daniel Vetter
2015-12-14 3:59 ` Kumar, Shobhit
2015-12-11 6:34 ` Kumar, Shobhit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56694656.8040607@linux.intel.com \
--to=shobhit.kumar@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=kumar@shobhit.info \
--cc=shobhit.kumar@intel.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox