* [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
@ 2016-10-19 21:29 Matthew Auld
2016-10-19 21:47 ` ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2) Patchwork
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Matthew Auld @ 2016-10-19 21:29 UTC (permalink / raw)
To: intel-gfx
Currently it's entirely possible to go through the link training step
without first determining the lane_count, which is silly since we end up
doing a bunch of aux transfers of size = 0, as highlighted by
WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
'failed to update link training' message. This can be observed during
intel_dp_long_pulse where we can do the link training step, but before
we have had a chance to set the link params. To avoid this we add an
extra check for the lane_count in intel_dp_check_link_status, which
should prevent us from doing the link training step prematurely.
v2: add WARN_ON_ONCE and FIXME comment (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 88f3b74..fb760ad 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (!to_intel_crtc(intel_encoder->base.crtc)->active)
return;
+ /* FIXME: we need to synchronize this sort of stuff with hardware
+ * readout */
+ if (WARN_ON_ONCE(!intel_dp->lane_count))
+ return;
+
/* if link training is requested we should perform it always */
if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
(!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
2016-10-19 21:29 [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status Matthew Auld
@ 2016-10-19 21:47 ` Patchwork
2016-10-20 9:39 ` Matthew Auld
2016-10-20 8:37 ` [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status Ville Syrjälä
2016-10-24 14:21 ` Jani Nikula
2 siblings, 1 reply; 10+ messages in thread
From: Patchwork @ 2016-10-19 21:47 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
URL : https://patchwork.freedesktop.org/series/11667/
State : warning
== Summary ==
Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status
https://patchwork.freedesktop.org/api/1.0/series/11667/revisions/2/mbox/
Test drv_module_reload_basic:
pass -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass -> DMESG-WARN (fi-ivb-3770)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS (fi-skl-6700hq)
dmesg-warn -> PASS (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS (fi-skl-6700hq)
fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:0 skip:15
fi-bsw-n3050 total:246 pass:204 dwarn:0 dfail:0 fail:0 skip:42
fi-bxt-t5700 total:246 pass:216 dwarn:0 dfail:0 fail:0 skip:30
fi-byt-j1900 total:246 pass:214 dwarn:0 dfail:0 fail:1 skip:31
fi-byt-n2820 total:246 pass:210 dwarn:0 dfail:0 fail:1 skip:35
fi-hsw-4770 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22
fi-hsw-4770r total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22
fi-ilk-650 total:246 pass:184 dwarn:0 dfail:0 fail:2 skip:60
fi-ivb-3520m total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25
fi-ivb-3770 total:246 pass:220 dwarn:1 dfail:0 fail:0 skip:25
fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hq total:246 pass:222 dwarn:1 dfail:0 fail:0 skip:23
fi-skl-6700k total:246 pass:221 dwarn:1 dfail:0 fail:0 skip:24
fi-skl-6770hq total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14
fi-snb-2520m total:246 pass:210 dwarn:0 dfail:0 fail:0 skip:36
fi-snb-2600 total:246 pass:209 dwarn:0 dfail:0 fail:0 skip:37
Results at /archive/results/CI_IGT_test/Patchwork_2768/
456ed322a41b7ca9699ad10fe49775803a55656a drm-intel-nightly: 2016y-10m-19d-20h-30m-34s UTC integration manifest
95638cb drm/i915/dp: add lane_count check in intel_dp_check_link_status
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
2016-10-19 21:29 [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status Matthew Auld
2016-10-19 21:47 ` ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2) Patchwork
@ 2016-10-20 8:37 ` Ville Syrjälä
2016-10-24 14:21 ` Jani Nikula
2 siblings, 0 replies; 10+ messages in thread
From: Ville Syrjälä @ 2016-10-20 8:37 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
On Wed, Oct 19, 2016 at 10:29:53PM +0100, Matthew Auld wrote:
> Currently it's entirely possible to go through the link training step
> without first determining the lane_count, which is silly since we end up
> doing a bunch of aux transfers of size = 0, as highlighted by
> WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
> 'failed to update link training' message. This can be observed during
> intel_dp_long_pulse where we can do the link training step, but before
> we have had a chance to set the link params. To avoid this we add an
> extra check for the lane_count in intel_dp_check_link_status, which
> should prevent us from doing the link training step prematurely.
>
> v2: add WARN_ON_ONCE and FIXME comment (Ville)
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 88f3b74..fb760ad 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> return;
>
> + /* FIXME: we need to synchronize this sort of stuff with hardware
> + * readout */
> + if (WARN_ON_ONCE(!intel_dp->lane_count))
> + return;
One warn is better than a constant spew as can be seen eg. in
https://bugs.freedesktop.org/show_bug.cgi?id=98323
Still need to fix the real issue of course, but in the meantime
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> +
> /* if link training is requested we should perform it always */
> if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
> (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> --
> 2.7.4
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
2016-10-19 21:47 ` ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2) Patchwork
@ 2016-10-20 9:39 ` Matthew Auld
2016-10-21 13:18 ` Ville Syrjälä
0 siblings, 1 reply; 10+ messages in thread
From: Matthew Auld @ 2016-10-20 9:39 UTC (permalink / raw)
To: Intel Graphics Development; +Cc: Matthew Auld
On 19 October 2016 at 22:47, Patchwork <patchwork@emeril.freedesktop.org> wrote:
> == Series Details ==
>
> Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
> URL : https://patchwork.freedesktop.org/series/11667/
> State : warning
>
> == Summary ==
>
> Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status
> https://patchwork.freedesktop.org/api/1.0/series/11667/revisions/2/mbox/
>
> Test drv_module_reload_basic:
> pass -> DMESG-WARN (fi-skl-6700hq)
[ 36.849247] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[ 36.849278] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
[ 36.867178] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
[ 38.946464] Setting dangerous option inject_load_failure - tainting kernel
[ 39.093675] Setting dangerous option inject_load_failure - tainting kernel
[ 39.258529] Setting dangerous option inject_load_failure - tainting kernel
[ 39.424800] Setting dangerous option inject_load_failure - tainting kernel
[ 40.497909] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[ 40.498321] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
[ 40.530092] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=98353
> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS (fi-skl-6700hq)
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-a:
> dmesg-warn -> PASS (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-b:
> pass -> DMESG-WARN (fi-ivb-3770)
[ 391.061781] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130
[ 391.062331] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130
https://bugs.freedesktop.org/show_bug.cgi?id=98228
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
2016-10-20 9:39 ` Matthew Auld
@ 2016-10-21 13:18 ` Ville Syrjälä
0 siblings, 0 replies; 10+ messages in thread
From: Ville Syrjälä @ 2016-10-21 13:18 UTC (permalink / raw)
To: Matthew Auld; +Cc: Intel Graphics Development, Matthew Auld
On Thu, Oct 20, 2016 at 10:39:57AM +0100, Matthew Auld wrote:
> On 19 October 2016 at 22:47, Patchwork <patchwork@emeril.freedesktop.org> wrote:
> > == Series Details ==
> >
> > Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
> > URL : https://patchwork.freedesktop.org/series/11667/
> > State : warning
> >
> > == Summary ==
> >
> > Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status
> > https://patchwork.freedesktop.org/api/1.0/series/11667/revisions/2/mbox/
> >
> > Test drv_module_reload_basic:
> > pass -> DMESG-WARN (fi-skl-6700hq)
> [ 36.849247] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [ 36.849278] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
> [ 36.867178] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
> [ 38.946464] Setting dangerous option inject_load_failure - tainting kernel
> [ 39.093675] Setting dangerous option inject_load_failure - tainting kernel
> [ 39.258529] Setting dangerous option inject_load_failure - tainting kernel
> [ 39.424800] Setting dangerous option inject_load_failure - tainting kernel
> [ 40.497909] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [ 40.498321] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
> [ 40.530092] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
>
> Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=98353
>
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > dmesg-warn -> PASS (fi-skl-6700hq)
> > Test kms_pipe_crc_basic:
> > Subgroup nonblocking-crc-pipe-a:
> > dmesg-warn -> PASS (fi-ilk-650)
> > Subgroup nonblocking-crc-pipe-b:
> > pass -> DMESG-WARN (fi-ivb-3770)
> [ 391.061781] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 391.062331] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
>
> https://bugs.freedesktop.org/show_bug.cgi?id=98228
Pushed to dinq. Thanks for the patch.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
2016-10-19 21:29 [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status Matthew Auld
2016-10-19 21:47 ` ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2) Patchwork
2016-10-20 8:37 ` [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status Ville Syrjälä
@ 2016-10-24 14:21 ` Jani Nikula
2 siblings, 0 replies; 10+ messages in thread
From: Jani Nikula @ 2016-10-24 14:21 UTC (permalink / raw)
To: Matthew Auld, intel-gfx
On Thu, 20 Oct 2016, Matthew Auld <matthew.auld@intel.com> wrote:
> Currently it's entirely possible to go through the link training step
> without first determining the lane_count, which is silly since we end up
> doing a bunch of aux transfers of size = 0, as highlighted by
> WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
> 'failed to update link training' message. This can be observed during
> intel_dp_long_pulse where we can do the link training step, but before
> we have had a chance to set the link params. To avoid this we add an
> extra check for the lane_count in intel_dp_check_link_status, which
> should prevent us from doing the link training step prematurely.
Now we'll just have to fix the cases where we try to do this anyway:
https://bugs.freedesktop.org/show_bug.cgi?id=98374
BR,
Jani.
>
> v2: add WARN_ON_ONCE and FIXME comment (Ville)
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 88f3b74..fb760ad 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> return;
>
> + /* FIXME: we need to synchronize this sort of stuff with hardware
> + * readout */
> + if (WARN_ON_ONCE(!intel_dp->lane_count))
> + return;
> +
> /* if link training is requested we should perform it always */
> if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
> (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
2016-09-06 14:43 ` Ville Syrjälä
@ 2016-10-19 17:05 ` Ville Syrjälä
0 siblings, 0 replies; 10+ messages in thread
From: Ville Syrjälä @ 2016-10-19 17:05 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
On Tue, Sep 06, 2016 at 05:43:44PM +0300, Ville Syrjälä wrote:
> On Sat, Aug 27, 2016 at 02:33:25PM +0100, Matthew Auld wrote:
> > Currently it's entirely possible to go through the link training step
> > without first determining the lane_count, which is silly since we end up
> > doing a bunch of aux transfers of size = 0, as highlighted by
> > WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
> > 'failed to update link training' message. This can be observed during
> > intel_dp_long_pulse where we can do the link training step, but before
> > we have had a chance to set the link params. To avoid this we add an
> > extra check for the lane_count in intel_dp_check_link_status, which
> > should prevent us from doing the link training step prematurely.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index a3c7dd8..0dbb672 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> > if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > return;
> >
> > + if (!intel_dp->lane_count)
> > + return;
>
> This pretty much amounts to the same thing that I did with 'active_streams' in
> my series [1]. The problem is that we need to sync up the state on readout to
> make it really work. Daniel wasn't too happy with my .sync_state() hook, so
> maybe we need something fancier.
>
> [1] https://patchwork.freedesktop.org/series/10354/
So, looking at some recent logs I see we may hit this WARN spew a *lot*.
So we probably want this patch as a temporary measure. Maybe with
WARN_ONCE() + a comment, eg.
/*
* FIXME need to synchronize this sort of
* stuff properly with hardware readout.
*/
?
>
> > +
> > /* if link training is requested we should perform it always */
> > if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
> > (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
2016-08-27 13:33 Matthew Auld
2016-08-31 11:20 ` Mika Kahola
@ 2016-09-06 14:43 ` Ville Syrjälä
2016-10-19 17:05 ` Ville Syrjälä
1 sibling, 1 reply; 10+ messages in thread
From: Ville Syrjälä @ 2016-09-06 14:43 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
On Sat, Aug 27, 2016 at 02:33:25PM +0100, Matthew Auld wrote:
> Currently it's entirely possible to go through the link training step
> without first determining the lane_count, which is silly since we end up
> doing a bunch of aux transfers of size = 0, as highlighted by
> WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
> 'failed to update link training' message. This can be observed during
> intel_dp_long_pulse where we can do the link training step, but before
> we have had a chance to set the link params. To avoid this we add an
> extra check for the lane_count in intel_dp_check_link_status, which
> should prevent us from doing the link training step prematurely.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a3c7dd8..0dbb672 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> return;
>
> + if (!intel_dp->lane_count)
> + return;
This pretty much amounts to the same thing that I did with 'active_streams' in
my series [1]. The problem is that we need to sync up the state on readout to
make it really work. Daniel wasn't too happy with my .sync_state() hook, so
maybe we need something fancier.
[1] https://patchwork.freedesktop.org/series/10354/
> +
> /* if link training is requested we should perform it always */
> if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
> (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> --
> 2.7.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
2016-08-27 13:33 Matthew Auld
@ 2016-08-31 11:20 ` Mika Kahola
2016-09-06 14:43 ` Ville Syrjälä
1 sibling, 0 replies; 10+ messages in thread
From: Mika Kahola @ 2016-08-31 11:20 UTC (permalink / raw)
To: Matthew Auld, intel-gfx
On Sat, 2016-08-27 at 14:33 +0100, Matthew Auld wrote:
> Currently it's entirely possible to go through the link training step
> without first determining the lane_count, which is silly since we end
> up
> doing a bunch of aux transfers of size = 0, as highlighted by
> WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
> 'failed to update link training' message. This can be observed during
> intel_dp_long_pulse where we can do the link training step, but
> before
> we have had a chance to set the link params. To avoid this we add an
> extra check for the lane_count in intel_dp_check_link_status, which
> should prevent us from doing the link training step prematurely.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index a3c7dd8..0dbb672 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp
> *intel_dp)
> if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> return;
>
> + if (!intel_dp->lane_count)
> + return;
> +
> /* if link training is requested we should perform it always
> */
> if ((intel_dp->compliance_test_type ==
> DP_TEST_LINK_TRAINING) ||
> (!drm_dp_channel_eq_ok(link_status, intel_dp-
> >lane_count))) {
Should we place this check as part drm_dp_helper()'s
drm_dp_channel_eq_ok() routine as this may happen with other than our
i915 driver as well?
--
Mika Kahola - Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
@ 2016-08-27 13:33 Matthew Auld
2016-08-31 11:20 ` Mika Kahola
2016-09-06 14:43 ` Ville Syrjälä
0 siblings, 2 replies; 10+ messages in thread
From: Matthew Auld @ 2016-08-27 13:33 UTC (permalink / raw)
To: intel-gfx
Currently it's entirely possible to go through the link training step
without first determining the lane_count, which is silly since we end up
doing a bunch of aux transfers of size = 0, as highlighted by
WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
'failed to update link training' message. This can be observed during
intel_dp_long_pulse where we can do the link training step, but before
we have had a chance to set the link params. To avoid this we add an
extra check for the lane_count in intel_dp_check_link_status, which
should prevent us from doing the link training step prematurely.
References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a3c7dd8..0dbb672 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (!to_intel_crtc(intel_encoder->base.crtc)->active)
return;
+ if (!intel_dp->lane_count)
+ return;
+
/* if link training is requested we should perform it always */
if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
(!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-10-24 14:21 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-19 21:29 [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status Matthew Auld
2016-10-19 21:47 ` ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2) Patchwork
2016-10-20 9:39 ` Matthew Auld
2016-10-21 13:18 ` Ville Syrjälä
2016-10-20 8:37 ` [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status Ville Syrjälä
2016-10-24 14:21 ` Jani Nikula
-- strict thread matches above, loose matches on Subject: below --
2016-08-27 13:33 Matthew Auld
2016-08-31 11:20 ` Mika Kahola
2016-09-06 14:43 ` Ville Syrjälä
2016-10-19 17:05 ` Ville Syrjälä
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.