intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: daniel.vetter@intel.com, intel-gfx@lists.freedesktop.org,
	shobhit.kumar@intel.com
Subject: Re: [PATCH] drm/i915: Restrict usage of live status check
Date: Thu, 10 Mar 2016 18:52:14 +0530	[thread overview]
Message-ID: <56E17506.5030205@intel.com> (raw)
In-Reply-To: <20160310130708.GI10446@intel.com>

Regards
Shashank

On 3/10/2016 6:37 PM, Ville Syrjälä wrote:
> On Thu, Mar 10, 2016 at 06:12:32PM +0530, Sharma, Shashank wrote:
>> Thanks Ville,
>>
>> Regards
>> Shashank
>>
>> On 3/10/2016 5:10 PM, Ville Syrjälä wrote:
>>> On Thu, Mar 10, 2016 at 05:05:47PM +0530, Shashank Sharma wrote:
>>>> This patch does the following:
>>>> - Restricts usage of live status check for HDMI detection.
>>>>     While testing certain (monitor + cable) combinations with
>>>>     various intel  platforms, it seems that live status register
>>>>     doesn't work reliably on some older devices. So limit the
>>>>     live_status check for HDMI detection, only for platforms
>>>>     from gen7 onwards.
>>>
>>> Not good enough. We have regressions reported on IVB at least.
>>> Also I'm not convinced more recent platforms are any necessarily
>>> better here.
>> Thanks for pointing out the miss for IVB. I will add skip for that.
>> We have tested VLV, CHT SKL and BXT with this code, so we should be good
>> with those. Anything particular in your mind ?
>
> I'm concerned it's more about the displays/cables than about the source.
> I don't think we had any reports so far where people would have been
> able to test a bad sink/cable with multiple platforms, and found some
> working and some not.
>
I agree, that it did seem to work fine till now. But the reason behind 
that was, we were probing EDID on every instance of detect(with out 
without interrupt), and it was hitting one or other time. So these 
issues were always there, but were hidden behind bugs in our driver.

Also, for newer platforms, live status check is a *must* as per bspec. 
If we dont do this, we will see improper hdmi_detect() replies for 
consecutive connector_probe, just like chrome and android is facing now. 
Passing compliance is again other concern.

IMHO, Now, when our driver is used between commercial/production devices 
and open source community, we have to let a cable/monitor vendor take 
the credit of the bug. Carrying this forward is gonna hit our 
performance and HDMI compliance certification.
>>>
>>>> - Cleans up the retry logic.
>>>>     There is an extra 'if (try)' check, which can be avoided by
>>>>     changing the logic slightly, keeping the delay as same(80ms)
>>>
>>> I wouldn't call a goto loop clean.
>>>
>> I know, its flushing my pipeline, and its not the best thing to do. But
>> makes code more readable, and removes one (if) condition, which was
>> getting executed for every run of the loop. So I guess still some CPU
>> cycles saved in the end :)
>
> Any kind of real loop would be more clear than a goto. Though we did use
> some while/do while thing originally I think, and that was messy in
> other ways. Pn option would of course be to unroll the first iteration
> out from the loop so that the 'if' would disappear from the loop.
Yes, This will add code duplication, as I will be adding the same line 
after and before loop. Typical embedded system dilemma, space vs time :)
>
> In any case, this sort of stuff should be a separate patch.
Agree, I can add another patch for this.
>
>>>>
>>>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/intel_hdmi.c | 23 +++++++++++++++--------
>>>>    1 file changed, 15 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
>>>> index e2dab48..3f6db91 100644
>>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>>>> @@ -1397,24 +1397,31 @@ intel_hdmi_detect(struct drm_connector *connector, bool force)
>>>>    	enum drm_connector_status status;
>>>>    	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 try;
>>>> +	bool live_status = true;
>>>> +	unsigned int try = 9;
>>>>
>>>>    	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>>>    		      connector->base.id, connector->name);
>>>>
>>>>    	intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>>>>
>>>> -	for (try = 0; !live_status && try < 9; try++) {
>>>> -		if (try)
>>>> -			msleep(10);
>>>> +	/*
>>>> +	 * When tested with specific set of monitors + cables,
>>>> +	 * live status behavior is not very consistent for older
>>>> +	 * platforms. So add live status check from GEN7
>>>> +	 * onwards.
>>>> +	 */
>>>> +	if (INTEL_INFO(dev_priv->dev)->gen >= 7) {
>>>> +retry_ls:
>>>>    		live_status = intel_digital_port_connected(dev_priv,
>>>>    				hdmi_to_dig_port(intel_hdmi));
>>>> +		if (!live_status && --try) {
>>>> +			msleep(10);
>>>> +			goto retry_ls;
>>>> +		}
>>>> +		DRM_DEBUG_KMS("Live status %s!\n", live_status ? "up" : "down");
>>>>    	}
>>>>
>>>> -	if (!live_status)
>>>> -		DRM_DEBUG_KMS("Live status not up!");
>>>> -
>>>>    	intel_hdmi_unset_edid(connector);
>>>>
>>>>    	if (intel_hdmi_set_edid(connector, live_status)) {
>>>> --
>>>> 1.9.1
>>>>
>>>> _______________________________________________
>>>> Intel-gfx mailing list
>>>> Intel-gfx@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-03-10 13:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-10 11:35 [PATCH] drm/i915: Restrict usage of live status check Shashank Sharma
2016-03-10 11:40 ` Ville Syrjälä
2016-03-10 12:42   ` Sharma, Shashank
2016-03-10 13:07     ` Ville Syrjälä
2016-03-10 13:22       ` Sharma, Shashank [this message]
2016-03-10 12:27 ` ✗ Fi.CI.BAT: failure for " Patchwork
2016-03-10 14:50 ` Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2016-03-17  7:59 [PATCH] " Shashank Sharma
2016-03-17  9:25 ` Jani Nikula
2016-03-17 10:19   ` Sharma, Shashank
2016-03-17 13:04 ` Ville Syrjälä
2016-03-17 15:45   ` Sharma, Shashank
2016-03-17 15:57     ` Chris Wilson
2016-03-17 16:01     ` Ville Syrjälä
2016-03-17 16:05       ` Sharma, Shashank
2016-03-17 16:21         ` Ville Syrjälä
2016-03-17 16:33           ` Sharma, Shashank
2016-03-17 16:47             ` Ville Syrjälä
2016-03-18  3:21               ` Sharma, Shashank
2016-03-18 12:28                 ` Ville Syrjälä
2016-03-17 17:59             ` Jani Nikula
2016-03-18  3:23               ` Sharma, Shashank

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=56E17506.5030205@intel.com \
    --to=shashank.sharma@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --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;
as well as URLs for NNTP newsgroup(s).