Quoting Sharma, Shashank (2018-08-16 08:33:36) > Regards > > Shashank > > > On 8/16/2018 12:47 PM, Jani Nikula wrote: > > On Wed, 15 Aug 2018, Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> 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@xxxxxxxxx> > >>> Cc: Imre Deak <imre.deak@xxxxxxxxx> > >>> Cc: Jani Nikula <jani.nikula@xxxxxxxxx> > >>> Cc: <stable@xxxxxxxxxxxxxxx> # 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@xxxxxxxxx> > >>> > >>> 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. wait_for() checks every [10us, 1ms] until the condition is met, or it times out. So, so long as we don't enter this path for !LPSCON where we know that it will timeout, the wait_for() will only take as long as is required for the connector to settle. Can we do other connectors at the same time, or does probing LSPCON block the system? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
