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
Subject: Re: [PATCH] drm/i915: Restrict usage of live status check
Date: Fri, 18 Mar 2016 08:51:29 +0530	[thread overview]
Message-ID: <56EB7439.1050208@intel.com> (raw)
In-Reply-To: <20160317164706.GD4329@intel.com>

Regards
Shashank

On 3/17/2016 10:17 PM, Ville Syrjälä wrote:
> On Thu, Mar 17, 2016 at 10:03:04PM +0530, Sharma, Shashank wrote:
>> Hey Chris,
>> I added comments for both Ville and you, please help me to understand this.
>>
>> Regards
>> Shashank
>>
>> On 3/17/2016 9:51 PM, Ville Syrjälä wrote:
>>> On Thu, Mar 17, 2016 at 09:35:30PM +0530, Sharma, Shashank wrote:
>>>> Regards
>>>> Shashank
>>>>
>>>> On 3/17/2016 9:31 PM, Ville Syrjälä wrote:
>>>>> On Thu, Mar 17, 2016 at 09:15:39PM +0530, Sharma, Shashank wrote:
>>>>>> Regards
>>>>>> Shashank
>>>>>>
>>>>>> On 3/17/2016 6:34 PM, Ville Syrjälä wrote:
>>>>>>> On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:
>>>>>>>> This patch 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 is not reliable
>>>>>>>> on some older devices. So limit the live_status check from VLV onwards.
>>>>>>>>
>>>>>>>> This fixes a regression introduced in:
>>>>>>>> 	commit: 237ed86 "drm/i915: Check live status"
>>>>>>>> 	Author: Sonika Jindal <sonika.jindal@intel.com>
>>>>>>>> 	Date:   Tue Sep 15 09:44:20 2015 +0530
>>>>>>>>
>>>>>>>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>>>>>>>> ---
>>>>>>>>      drivers/gpu/drm/i915/intel_hdmi.c | 22 ++++++++++++++--------
>>>>>>>>      1 file changed, 14 insertions(+), 8 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
>>>>>>>> index e2dab48..d24d18a 100644
>>>>>>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>>>>>>>> @@ -1397,7 +1397,8 @@ 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;
>>>>>>>> +	struct drm_device *dev = connector->dev;
>>>>>>>> +	bool live_status = true;
>>>>>>>>      	unsigned int try;
>>>>>>>>
>>>>>>>>      	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>>>>>>> @@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector, bool force)
>>>>>>>>
>>>>>>>>      	intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>>>>>>>>
>>>>>>>> -	for (try = 0; !live_status && try < 9; try++) {
>>>>>>>> -		if (try)
>>>>>>>> -			msleep(10);
>>>>>>>> -		live_status = intel_digital_port_connected(dev_priv,
>>>>>>>> +	/*
>>>>>>>> +	* Live status check for HDMI detection is not very
>>>>>>>> +	* reliable on older platforms. So insist the live
>>>>>>>> +	* status check for EDID read from VLV onwards.
>>>>>>>> +	*/
>>>>>>>> +	if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
>>>>>>>> +		for (try = 0; !live_status && try < 9; try++) {
>>>>>>>> +			if (try)
>>>>>>>> +				msleep(10);
>>>>>>>> +			live_status = intel_digital_port_connected(dev_priv,
>>>>>>>>      				hdmi_to_dig_port(intel_hdmi));
>>>>>>>> +		}
>>>>>>>> +		DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
>>>>>>>>      	}
>>>>>>>>
>>>>>>>> -	if (!live_status)
>>>>>>>> -		DRM_DEBUG_KMS("Live status not up!");
>>>>>>>> -
>>>>>>>
>>>>>>> As I said before, I think this whole thing could be solved with a simple
>>>>>>> two-liner here:
>>>>>>>
>>>>>>> +	if (...)
>>>>>>> +		live_status = true;
>>>>>>>
>>>>>> Yes I remember, and I replied on that already that why we would like to
>>>>>> keep the live status check. In fact I would be ok to remove this check
>>>>>> if you can suggest some other way of making this work for other
>>>>>> operating systems/sw platforms.
>>>>>
>>>>> My two liner would keep the check.
>>>>>
>>>> Sorry, I might have not understood you properly.
>>>> Do you mean:
>>>> 	if (INTEL_INFO(dev)->gen < 7 && IS_IVYBRIDGE(dev)) {
>>>> 		live_status = true;
>>>> 	} else {
>>>> 		do the same looping for retry;
>>>> 	}
>>>
>>> No, I mean
>>>
>>> {
>>> 	...
>>> 	do loop;
>>>
>>> 	if (!live_status)
>>> 		DRM_DEBUG_KMS("Live status not up!");
>>>
>>> +	if (don't trust live status)
>>> +		live_status = true;
>>> 	
>>> 	intel_hdmi_unset_edid();
>>> 	
>>> 	if (intel_hdmi_set_edid(live_status)) {
>>> 	...
>>> }
>>>
>>>
>> In fact, this is what I have done.
>> If you see the change in this patch,
>> 	/* Lets make live status true for < VLV platforms */
>> 	bool live_status = true;
>>
>> 	blah....
>> 	blah....
>>
>> 	/* Check live status only for newer platforms */
>> 	if (this is VLV or later platforms) {
>> 		live_status = read_real_live_status();
>> 	}
>> 	intel_hdmi_unset_edid();
>> 	intel_hdmi_set_edid(live_status);
>>
>> Now, my question is, do you want to remove live_status check for VLV and
>> other platforms too ? or this is good enough ?
>
> No, I'm objecting to changing the entire code when you could just add
> two lines. Also my way has the extra benefit that we keep the live
> status check mostly working on these presumed "broken" platforms.
>
> So the only difference to the current situation is that we would still
> attempt the EDID read even if live_status came out as false, but thanks
> to the extra delay from the live status polling we would hopefully
> avoid spurious detection results since the EDID read gets delayed a bit.
>
Ok, thanks for this suggestion. I will do the change.
I was thinking of adding a warning, if we are going to read the EDID 
without live status being set, sounds ok ?

>> 	
>>>>
>>>>>>>>      	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

  reply	other threads:[~2016-03-18  3:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-17  7:59 [PATCH] drm/i915: Restrict usage of live status check Shashank Sharma
2016-03-17  9:25 ` Jani Nikula
2016-03-17 10:19   ` Sharma, Shashank
2016-04-20 12:12   ` [PATCH v2] " Shashank Sharma
2016-04-20 14:48     ` Ville Syrjälä
2016-04-21  3:55       ` Sharma, Shashank
2016-04-21  4:45         ` Sharma, Shashank
2016-03-17 13:04 ` [PATCH] " 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 [this message]
2016-03-18 12:28                 ` Ville Syrjälä
2016-03-17 17:59             ` Jani Nikula
2016-03-18  3:23               ` Sharma, Shashank
2016-03-17 14:02 ` ✗ Fi.CI.BAT: failure for drm/i915: Restrict usage of live status check (rev3) Patchwork
2016-04-20 17:24 ` ✓ Fi.CI.BAT: success for drm/i915: Restrict usage of live status check (rev4) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
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

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=56EB7439.1050208@intel.com \
    --to=shashank.sharma@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --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).