intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: "Jani Nikula" <jani.nikula@intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Fredrik Schön" <fredrikschon@gmail.com>
Cc: intel-gfx@lists.freedesktop.org,
	"Fredrik Schön" <fredrik.schon@gmail.com>
Subject: Re: [PATCH] [drm][i915] Increase LSPCON timeout
Date: Thu, 16 Aug 2018 13:03:36 +0530	[thread overview]
Message-ID: <1e81a6b4-f3b7-0da2-a9d5-5719b5a1f29d@intel.com> (raw)
In-Reply-To: <87tvnu7pb8.fsf@intel.com>

Regards

Shashank


On 8/16/2018 12:47 PM, Jani Nikula wrote:
> On Wed, 15 Aug 2018, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>> On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
>>> On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
>>>
>>> First of all we need to fix the commit subject:
>>>
>>> drm/i915: Increase LSPCON timeout
>>>
>>> (this can be done when merging, no need to resend)
>>>
>>>> 100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
>>>> settle. This causes dropped display modes at driver initialisation.
>>>>
>>>> Increase timeout to 1000 ms.
>>>>
>>>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
>>> Missusage of "Fixes:" tag, please read
>>>
>>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
>>>
>>> But also no need for resending... could be fixed when merging
>>>
>>> The right one would be:
>>>
>>> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
>>> Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to settle")
>>> Cc: Shashank Sharma <shashank.sharma@intel.com>
>>> Cc: Imre Deak <imre.deak@intel.com>
>>> Cc: Jani Nikula <jani.nikula@intel.com>
>>> Cc: <stable@vger.kernel.org> # v4.11+
>>>
>>> Since initial 100 seemed to be empirical and this increase seems to
>>> help other cases I'm in favor of this move so
>>>
>>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>
>>> However I will wait a bit before merging it
>>> so Imre, Shashank, and/or Jani can take a look here...
>> now, really cc'ing them...
> Shashank? Does this slow down non-LSPCON paths?
This will slow down the lspcon probing and resume part, but both of them 
happen only when LSPCON device is found. So to answer your question, 
this will not slow down the non-lspcon path, but will slow down the 
LSPCON connector resume and probe time. but I would recommend, instead 
of increasing it to 1000 ms in a single shot, we might want to gradually 
pick this up, on a wake-and-check way.

- Shashank
>
> BR,
> Jani.
>
>
>>>> Signed-off-by: Fredrik Schön <fredrik.schon@gmail.com>
>>>> ---
>>>>   drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c b/drivers/gpu/drm/i915/intel_lspcon.c
>>>> index 8ae8f42f430a..be1b08f589a4 100644
>>>> --- a/drivers/gpu/drm/i915/intel_lspcon.c
>>>> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
>>>> @@ -74,7 +74,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct intel_lspcon *lspcon,
>>>>   	DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
>>>>   		      lspcon_mode_name(mode));
>>>>   
>>>> -	wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
>>>> +	wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 1000);
>>>>   	if (current_mode != mode)
>>>>   		DRM_ERROR("LSPCON mode hasn't settled\n");
>>>>   
>>>> -- 
>>>> 2.17.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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-08-16  7:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-13 17:51 [PATCH] [drm][i915] Increase LSPCON timeout Fredrik Schön
2018-08-14 13:09 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-08-14 16:08 ` ✓ Fi.CI.IGT: " Patchwork
2018-08-15 22:39 ` [PATCH] [drm][i915] " Rodrigo Vivi
2018-08-15 22:45   ` Rodrigo Vivi
2018-08-16  7:17     ` Jani Nikula
2018-08-16  7:33       ` Sharma, Shashank [this message]
2018-08-16  7:43         ` Chris Wilson
2018-08-16  8:15           ` Sharma, Shashank
2018-08-16  8:36             ` Fredrik Schön
2018-08-16 18:23               ` Rodrigo Vivi
2018-08-16 21:35                 ` fredrikschon
2018-08-16 21:43                   ` Rodrigo Vivi
2018-08-16 21:51                     ` Fredrik Schön
2018-08-16 21:58                       ` Rodrigo Vivi
2018-08-16  9:53       ` Saarinen, Jani

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=1e81a6b4-f3b7-0da2-a9d5-5719b5a1f29d@intel.com \
    --to=shashank.sharma@intel.com \
    --cc=fredrik.schon@gmail.com \
    --cc=fredrikschon@gmail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=rodrigo.vivi@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).