* Re: [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-02 21:52 [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count Manasi Navare
@ 2019-04-02 21:08 ` Clinton Taylor
2019-04-02 21:52 ` [PATCH 2/2] drm/i915/edp: Use max link rate and lane count if eDP EDID quirk Manasi Navare
` (3 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Clinton Taylor @ 2019-04-02 21:08 UTC (permalink / raw)
To: Manasi Navare, intel-gfx, dri-devel
On 4/2/19 2:52 PM, Manasi Navare wrote:
> For certain eDP 1.4 panels, we need to use max lane count for the
> link training to succeed.
>
> This patch adds a EDID quirk for such eDP panels using
> their vendor ID and product ID to force using max lane count in the driver.
>
> Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Tested-by: Albert Astals Cid <aacid@kde.org>
> Tested-by: Emanuele Panigati <ilpanich@gmail.com>
> Tested-by: Ralgor <ralgorfdb@compuspex.org>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
> drivers/gpu/drm/drm_edid.c | 10 ++++++++++
> include/drm/drm_connector.h | 5 +++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2c22ea446075..fbc661806484 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -82,6 +82,8 @@
> #define EDID_QUIRK_FORCE_10BPC (1 << 11)
> /* Non desktop display (i.e. HMD) */
> #define EDID_QUIRK_NON_DESKTOP (1 << 12)
> +/* Force max lane count */
Nit. Would like a little more descriptive comment about this quirk.
Maybe even /* Force use of max lane count for link training */
> +#define EDID_QUIRK_FORCE_MAX_LANE_COUNT (1 << 13)
>
> struct detailed_mode_closure {
> struct drm_connector *connector;
> @@ -189,6 +191,10 @@ static const struct edid_quirk {
>
> /* OSVR HDK and HDK2 VR Headsets */
> { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
> +
> + /* SHP eDP 1.4 panel only works with max lane count */
> + { "SHP", 0x149a, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
> + { "SHP", 0x148e, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
> };
>
> /*
> @@ -4463,6 +4469,7 @@ drm_reset_display_info(struct drm_connector *connector)
> memset(&info->hdmi, 0, sizeof(info->hdmi));
>
> info->non_desktop = 0;
> + info->force_max_lane_count = 0;
> }
>
> u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)
> @@ -4744,6 +4751,9 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> if (quirks & EDID_QUIRK_FORCE_12BPC)
> connector->display_info.bpc = 12;
>
> + if (quirks & EDID_QUIRK_FORCE_MAX_LANE_COUNT)
> + connector->display_info.force_max_lane_count = true;
> +
> return num_modes;
> }
> EXPORT_SYMBOL(drm_add_edid_modes);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 02a131202add..45436d40ffe3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -457,6 +457,11 @@ struct drm_display_info {
> * @non_desktop: Non desktop display (HMD).
> */
> bool non_desktop;
> +
> + /**
> + * @force_max_lane_count: Link training requires max lane count to pass
> + */
> + bool force_max_lane_count;
> };
>
> int drm_display_info_set_bus_formats(struct drm_display_info *info,
Rest of the patch appears sane for a quirk.
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
-Clint
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH 2/2] drm/i915/edp: Use max link rate and lane count if eDP EDID quirk
2019-04-02 21:52 [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count Manasi Navare
2019-04-02 21:08 ` Clinton Taylor
@ 2019-04-02 21:52 ` Manasi Navare
2019-04-02 21:11 ` Clinton Taylor
2019-04-02 22:50 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count Patchwork
` (2 subsequent siblings)
4 siblings, 1 reply; 13+ messages in thread
From: Manasi Navare @ 2019-04-02 21:52 UTC (permalink / raw)
To: intel-gfx, dri-devel
Some eDP 1.4 panels cannot use the optimized fast and narrow pipe
config approach, but they need to use th maximum supported lane count
for the link training to succeed.
There is a DRM EDID quirk for such panels that gets set after reading
their corresponding EDID.
So if it is set, this patch forces the max lane count in compute_config()
hook to use max lane count for link training.
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Albert Astals Cid <aacid@kde.org>
Tested-by: Emanuele Panigati <ilpanich@gmail.com>
Tested-by: Ralgor <ralgorfdb@compuspex.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 5 ++++-
drivers/gpu/drm/i915/intel_drv.h | 3 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 72c49070ed14..421db00f5792 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2028,7 +2028,8 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
limits.min_bpp = 6 * 3;
limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
- if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
+ if (intel_dp->edp_force_max_lane_count || (intel_dp_is_edp(intel_dp) &&
+ intel_dp->edp_dpcd[0] < DP_EDP_14)) {
/*
* Use the maximum clock and number of lanes the eDP panel
* advertizes being capable of. The eDP 1.3 and earlier panels
@@ -7101,6 +7102,8 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
edid = drm_get_edid(connector, &intel_dp->aux.ddc);
if (edid) {
if (drm_add_edid_modes(connector, edid)) {
+ if (connector->display_info.force_max_lane_count)
+ intel_dp->edp_force_max_lane_count = true;
drm_connector_update_edid_property(connector,
edid);
} else {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f8c7b291fdc3..c67c3c518714 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1327,6 +1327,9 @@ struct intel_dp {
/* Display stream compression testing */
bool force_dsc_en;
+
+ /* eDP 1.4 EDID quirk to use max lane count */
+ bool edp_force_max_lane_count;
};
enum lspcon_vendor {
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 2/2] drm/i915/edp: Use max link rate and lane count if eDP EDID quirk
2019-04-02 21:52 ` [PATCH 2/2] drm/i915/edp: Use max link rate and lane count if eDP EDID quirk Manasi Navare
@ 2019-04-02 21:11 ` Clinton Taylor
0 siblings, 0 replies; 13+ messages in thread
From: Clinton Taylor @ 2019-04-02 21:11 UTC (permalink / raw)
To: Manasi Navare, intel-gfx, dri-devel
On 4/2/19 2:52 PM, Manasi Navare wrote:
> Some eDP 1.4 panels cannot use the optimized fast and narrow pipe
> config approach, but they need to use th maximum supported lane count
> for the link training to succeed.
> There is a DRM EDID quirk for such panels that gets set after reading
> their corresponding EDID.
> So if it is set, this patch forces the max lane count in compute_config()
> hook to use max lane count for link training.
>
> Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Tested-by: Albert Astals Cid <aacid@kde.org>
> Tested-by: Emanuele Panigati <ilpanich@gmail.com>
> Tested-by: Ralgor <ralgorfdb@compuspex.org>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 5 ++++-
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 72c49070ed14..421db00f5792 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2028,7 +2028,8 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
> limits.min_bpp = 6 * 3;
> limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>
> - if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> + if (intel_dp->edp_force_max_lane_count || (intel_dp_is_edp(intel_dp) &&
> + intel_dp->edp_dpcd[0] < DP_EDP_14)) {
> /*
> * Use the maximum clock and number of lanes the eDP panel
> * advertizes being capable of. The eDP 1.3 and earlier panels
> @@ -7101,6 +7102,8 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
> edid = drm_get_edid(connector, &intel_dp->aux.ddc);
> if (edid) {
> if (drm_add_edid_modes(connector, edid)) {
> + if (connector->display_info.force_max_lane_count)
> + intel_dp->edp_force_max_lane_count = true;
> drm_connector_update_edid_property(connector,
> edid);
> } else {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index f8c7b291fdc3..c67c3c518714 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1327,6 +1327,9 @@ struct intel_dp {
>
> /* Display stream compression testing */
> bool force_dsc_en;
> +
> + /* eDP 1.4 EDID quirk to use max lane count */
> + bool edp_force_max_lane_count;
> };
>
> enum lspcon_vendor {
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
-Clint
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* ✓ Fi.CI.BAT: success for series starting with [1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-02 21:52 [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count Manasi Navare
2019-04-02 21:08 ` Clinton Taylor
2019-04-02 21:52 ` [PATCH 2/2] drm/i915/edp: Use max link rate and lane count if eDP EDID quirk Manasi Navare
@ 2019-04-02 22:50 ` Patchwork
2019-04-03 11:56 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-04-03 12:14 ` [PATCH 1/2] " Ville Syrjälä
4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2019-04-02 22:50 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
URL : https://patchwork.freedesktop.org/series/58893/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5857 -> Patchwork_12661
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/58893/revisions/1/mbox/
Known issues
------------
Here are the changes found in Patchwork_12661 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: PASS -> DMESG-FAIL [fdo#110235 ]
* igt@i915_selftest@live_hangcheck:
- fi-icl-u3: PASS -> INCOMPLETE [fdo#108569]
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: PASS -> FAIL [fdo#103167]
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s3:
- fi-icl-u2: FAIL [fdo#103375] -> PASS
* igt@i915_selftest@live_uncore:
- fi-ivb-3770: DMESG-FAIL [fdo#110210] -> PASS
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#110210]: https://bugs.freedesktop.org/show_bug.cgi?id=110210
[fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (48 -> 41)
------------------------------
Missing (7): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-apl-guc fi-ctg-p8600 fi-icl-y fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_5857 -> Patchwork_12661
CI_DRM_5857: 650af99ea37e684646d7ed0804e10ea1c7d73228 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4922: e941e4a29438c7130554492e4daf52afbc99ffdf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12661: 974452789bf85d2beaa75835042e2914c6a175ac @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
974452789bf8 drm/i915/edp: Use max link rate and lane count if eDP EDID quirk
9923f6baada1 drm/edid: Add a EDID edp panel quirk for forcing max lane count
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12661/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread* ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-02 21:52 [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count Manasi Navare
` (2 preceding siblings ...)
2019-04-02 22:50 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count Patchwork
@ 2019-04-03 11:56 ` Patchwork
2019-04-03 12:14 ` [PATCH 1/2] " Ville Syrjälä
4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2019-04-03 11:56 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
URL : https://patchwork.freedesktop.org/series/58893/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5857_full -> Patchwork_12661_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_12661_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12661_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_12661_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_tiled_pread_pwrite:
- shard-iclb: PASS -> DMESG-WARN
* igt@runner@aborted:
- shard-iclb: NOTRUN -> FAIL
Known issues
------------
Here are the changes found in Patchwork_12661_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s4-devices:
- shard-iclb: PASS -> DMESG-WARN [fdo#109638]
* igt@gem_mmap_gtt@hang:
- shard-iclb: PASS -> FAIL [fdo#109677]
* igt@gem_pwrite@big-gtt-fbr:
- shard-iclb: PASS -> TIMEOUT [fdo#109673]
* igt@i915_pm_rpm@legacy-planes-dpms:
- shard-iclb: PASS -> INCOMPLETE [fdo#108840] / [fdo#109369]
* igt@i915_pm_rpm@system-suspend-modeset:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107807]
* igt@i915_pm_rps@reset:
- shard-iclb: NOTRUN -> FAIL [fdo#108059]
* igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +13
* igt@kms_busy@extended-pageflip-hang-newfb-render-d:
- shard-iclb: NOTRUN -> SKIP [fdo#109278]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#110222]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-glk: NOTRUN -> DMESG-WARN [fdo#110222]
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-glk: NOTRUN -> FAIL [fdo#103232] +1
* igt@kms_cursor_legacy@2x-flip-vs-cursor-legacy:
- shard-glk: PASS -> FAIL [fdo#104873]
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109274]
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: NOTRUN -> FAIL [fdo#105363]
* igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-apl: PASS -> FAIL [fdo#103060]
* igt@kms_flip_tiling@flip-y-tiled:
- shard-iclb: PASS -> FAIL [fdo#108303]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +9
* igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-iclb: NOTRUN -> FAIL [fdo#103167] / [fdo#105682]
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render:
- shard-apl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +7
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-pwrite:
- shard-iclb: NOTRUN -> SKIP [fdo#109280]
* igt@kms_frontbuffer_tracking@fbcpsr-tilingchange:
- shard-iclb: PASS -> FAIL [fdo#109247] +4
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render:
- shard-skl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: NOTRUN -> SKIP [fdo#109271] +57
* igt@kms_frontbuffer_tracking@psr-farfromfence:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] +4
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-e:
- shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-skl: PASS -> INCOMPLETE [fdo#104108]
* igt@kms_plane_alpha_blend@pipe-b-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815]
* igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping:
- shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_psr@cursor_plane_onoff:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215]
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: PASS -> SKIP [fdo#109441] +1
* igt@kms_psr@psr2_primary_render:
- shard-apl: NOTRUN -> SKIP [fdo#109271] +2
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
* igt@kms_sysfs_edid_timing:
- shard-skl: NOTRUN -> FAIL [fdo#100047]
* igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-kbl: NOTRUN -> INCOMPLETE [fdo#103665]
* igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-apl: PASS -> FAIL [fdo#104894] +2
* igt@kms_vrr@flip-suspend:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +147
* igt@v3d_get_param@get-bad-flags:
- shard-iclb: NOTRUN -> SKIP [fdo#109315]
#### Possible fixes ####
* igt@gem_ctx_isolation@vecs0-s3:
- shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS
* igt@i915_selftest@live_workarounds:
- shard-iclb: DMESG-FAIL [fdo#108954] -> PASS
* igt@kms_atomic@plane_invalid_params:
- shard-snb: SKIP [fdo#109271] -> PASS +2
* igt@kms_atomic_transition@plane-all-modeset-transition-fencing:
- shard-glk: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_chv_cursor_fail@pipe-b-128x128-left-edge:
- shard-snb: SKIP [fdo#109271] / [fdo#109278] -> PASS +1
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: FAIL [fdo#104873] -> PASS
* igt@kms_cursor_legacy@cursor-vs-flip-legacy:
- shard-iclb: FAIL [fdo#103355] -> PASS
* igt@kms_flip@2x-modeset-vs-vblank-race-interruptible:
- shard-glk: FAIL [fdo#103060] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: FAIL [fdo#105682] / [fdo#108040] -> PASS
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt:
- shard-iclb: FAIL [fdo#109247] -> PASS +11
* igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-gtt:
- shard-iclb: FAIL [fdo#105682] / [fdo#109247] -> PASS +2
* igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk: SKIP [fdo#109271] -> PASS
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: FAIL [fdo#107815] -> PASS
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: FAIL [fdo#108145] -> PASS
* igt@kms_plane_scaling@pipe-c-scaler-with-rotation:
- shard-glk: SKIP [fdo#109271] / [fdo#109278] -> PASS
* igt@kms_psr@no_drrs:
- shard-iclb: FAIL [fdo#108341] -> PASS
* igt@kms_psr@psr2_primary_mmap_gtt:
- shard-iclb: SKIP [fdo#109441] -> PASS +1
* igt@kms_psr@sprite_blt:
- shard-iclb: FAIL [fdo#107383] / [fdo#110215] -> PASS +2
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: FAIL [fdo#109016] -> PASS
#### Warnings ####
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: FAIL [fdo#110270] -> SKIP [fdo#109349]
[fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#104894]: https://bugs.freedesktop.org/show_bug.cgi?id=104894
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105456]: https://bugs.freedesktop.org/show_bug.cgi?id=105456
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#105682]: https://bugs.freedesktop.org/show_bug.cgi?id=105682
[fdo#107383]: https://bugs.freedesktop.org/show_bug.cgi?id=107383
[fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#107815]: https://bugs.freedesktop.org/show_bug.cgi?id=107815
[fdo#108040]: https://bugs.freedesktop.org/show_bug.cgi?id=108040
[fdo#108059]: https://bugs.freedesktop.org/show_bug.cgi?id=108059
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108303]: https://bugs.freedesktop.org/show_bug.cgi?id=108303
[fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341
[fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
[fdo#108954]: https://bugs.freedesktop.org/show_bug.cgi?id=108954
[fdo#109016]: https://bugs.freedesktop.org/show_bug.cgi?id=109016
[fdo#109247]: https://bugs.freedesktop.org/show_bug.cgi?id=109247
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
[fdo#109369]: https://bugs.freedesktop.org/show_bug.cgi?id=109369
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109638]: https://bugs.freedesktop.org/show_bug.cgi?id=109638
[fdo#109673]: https://bugs.freedesktop.org/show_bug.cgi?id=109673
[fdo#109677]: https://bugs.freedesktop.org/show_bug.cgi?id=109677
[fdo#110215]: https://bugs.freedesktop.org/show_bug.cgi?id=110215
[fdo#110222]: https://bugs.freedesktop.org/show_bug.cgi?id=110222
[fdo#110270]: https://bugs.freedesktop.org/show_bug.cgi?id=110270
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (10 -> 9)
------------------------------
Missing (1): shard-hsw
Build changes
-------------
* Linux: CI_DRM_5857 -> Patchwork_12661
CI_DRM_5857: 650af99ea37e684646d7ed0804e10ea1c7d73228 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4922: e941e4a29438c7130554492e4daf52afbc99ffdf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12661: 974452789bf85d2beaa75835042e2914c6a175ac @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12661/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-02 21:52 [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count Manasi Navare
` (3 preceding siblings ...)
2019-04-03 11:56 ` ✗ Fi.CI.IGT: failure " Patchwork
@ 2019-04-03 12:14 ` Ville Syrjälä
2019-04-03 13:19 ` Daniel Vetter
2019-04-03 18:37 ` Manasi Navare
4 siblings, 2 replies; 13+ messages in thread
From: Ville Syrjälä @ 2019-04-03 12:14 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx, dri-devel
On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> For certain eDP 1.4 panels, we need to use max lane count for the
> link training to succeed.
>
> This patch adds a EDID quirk for such eDP panels using
> their vendor ID and product ID to force using max lane count in the driver.
Rather than opening the quirk can of worms I think we should consider
changing the retry loop to do something more sensible than what it's
doing now. The current behaviour of "start at optimal settings (which
can be either min lanes or min rate), and then reduce lanes/rate until
stuff works" overlooks several possible combinations. One possible
approach could be to start the retry loop with max lanes + max rate
after the optimal settings have failed. It probably won't give you
the best power consumption, but at least you get a picture on the
screen if even a single lane count + rate combo works.
>
> Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Tested-by: Albert Astals Cid <aacid@kde.org>
> Tested-by: Emanuele Panigati <ilpanich@gmail.com>
> Tested-by: Ralgor <ralgorfdb@compuspex.org>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
> drivers/gpu/drm/drm_edid.c | 10 ++++++++++
> include/drm/drm_connector.h | 5 +++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2c22ea446075..fbc661806484 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -82,6 +82,8 @@
> #define EDID_QUIRK_FORCE_10BPC (1 << 11)
> /* Non desktop display (i.e. HMD) */
> #define EDID_QUIRK_NON_DESKTOP (1 << 12)
> +/* Force max lane count */
> +#define EDID_QUIRK_FORCE_MAX_LANE_COUNT (1 << 13)
>
> struct detailed_mode_closure {
> struct drm_connector *connector;
> @@ -189,6 +191,10 @@ static const struct edid_quirk {
>
> /* OSVR HDK and HDK2 VR Headsets */
> { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
> +
> + /* SHP eDP 1.4 panel only works with max lane count */
> + { "SHP", 0x149a, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
> + { "SHP", 0x148e, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
> };
>
> /*
> @@ -4463,6 +4469,7 @@ drm_reset_display_info(struct drm_connector *connector)
> memset(&info->hdmi, 0, sizeof(info->hdmi));
>
> info->non_desktop = 0;
> + info->force_max_lane_count = 0;
> }
>
> u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)
> @@ -4744,6 +4751,9 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> if (quirks & EDID_QUIRK_FORCE_12BPC)
> connector->display_info.bpc = 12;
>
> + if (quirks & EDID_QUIRK_FORCE_MAX_LANE_COUNT)
> + connector->display_info.force_max_lane_count = true;
> +
> return num_modes;
> }
> EXPORT_SYMBOL(drm_add_edid_modes);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 02a131202add..45436d40ffe3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -457,6 +457,11 @@ struct drm_display_info {
> * @non_desktop: Non desktop display (HMD).
> */
> bool non_desktop;
> +
> + /**
> + * @force_max_lane_count: Link training requires max lane count to pass
> + */
> + bool force_max_lane_count;
> };
>
> int drm_display_info_set_bus_formats(struct drm_display_info *info,
> --
> 2.19.1
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-03 12:14 ` [PATCH 1/2] " Ville Syrjälä
@ 2019-04-03 13:19 ` Daniel Vetter
2019-04-03 18:37 ` Manasi Navare
1 sibling, 0 replies; 13+ messages in thread
From: Daniel Vetter @ 2019-04-03 13:19 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, dri-devel
On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > For certain eDP 1.4 panels, we need to use max lane count for the
> > link training to succeed.
> >
> > This patch adds a EDID quirk for such eDP panels using
> > their vendor ID and product ID to force using max lane count in the driver.
>
> Rather than opening the quirk can of worms I think we should consider
> changing the retry loop to do something more sensible than what it's
> doing now. The current behaviour of "start at optimal settings (which
> can be either min lanes or min rate), and then reduce lanes/rate until
> stuff works" overlooks several possible combinations. One possible
> approach could be to start the retry loop with max lanes + max rate
> after the optimal settings have failed. It probably won't give you
> the best power consumption, but at least you get a picture on the
> screen if even a single lane count + rate combo works.
Hm yeah I guess this is an approach we haven't tried yet ... I think we've
tried everything else already.
-Daniel
>
> >
> > Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Tested-by: Albert Astals Cid <aacid@kde.org>
> > Tested-by: Emanuele Panigati <ilpanich@gmail.com>
> > Tested-by: Ralgor <ralgorfdb@compuspex.org>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > ---
> > drivers/gpu/drm/drm_edid.c | 10 ++++++++++
> > include/drm/drm_connector.h | 5 +++++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 2c22ea446075..fbc661806484 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -82,6 +82,8 @@
> > #define EDID_QUIRK_FORCE_10BPC (1 << 11)
> > /* Non desktop display (i.e. HMD) */
> > #define EDID_QUIRK_NON_DESKTOP (1 << 12)
> > +/* Force max lane count */
> > +#define EDID_QUIRK_FORCE_MAX_LANE_COUNT (1 << 13)
> >
> > struct detailed_mode_closure {
> > struct drm_connector *connector;
> > @@ -189,6 +191,10 @@ static const struct edid_quirk {
> >
> > /* OSVR HDK and HDK2 VR Headsets */
> > { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
> > +
> > + /* SHP eDP 1.4 panel only works with max lane count */
> > + { "SHP", 0x149a, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
> > + { "SHP", 0x148e, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
> > };
> >
> > /*
> > @@ -4463,6 +4469,7 @@ drm_reset_display_info(struct drm_connector *connector)
> > memset(&info->hdmi, 0, sizeof(info->hdmi));
> >
> > info->non_desktop = 0;
> > + info->force_max_lane_count = 0;
> > }
> >
> > u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)
> > @@ -4744,6 +4751,9 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> > if (quirks & EDID_QUIRK_FORCE_12BPC)
> > connector->display_info.bpc = 12;
> >
> > + if (quirks & EDID_QUIRK_FORCE_MAX_LANE_COUNT)
> > + connector->display_info.force_max_lane_count = true;
> > +
> > return num_modes;
> > }
> > EXPORT_SYMBOL(drm_add_edid_modes);
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 02a131202add..45436d40ffe3 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -457,6 +457,11 @@ struct drm_display_info {
> > * @non_desktop: Non desktop display (HMD).
> > */
> > bool non_desktop;
> > +
> > + /**
> > + * @force_max_lane_count: Link training requires max lane count to pass
> > + */
> > + bool force_max_lane_count;
> > };
> >
> > int drm_display_info_set_bus_formats(struct drm_display_info *info,
> > --
> > 2.19.1
>
> --
> Ville Syrjälä
> Intel
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-03 12:14 ` [PATCH 1/2] " Ville Syrjälä
2019-04-03 13:19 ` Daniel Vetter
@ 2019-04-03 18:37 ` Manasi Navare
2019-04-03 18:55 ` Ville Syrjälä
1 sibling, 1 reply; 13+ messages in thread
From: Manasi Navare @ 2019-04-03 18:37 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, dri-devel
On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > For certain eDP 1.4 panels, we need to use max lane count for the
> > link training to succeed.
> >
> > This patch adds a EDID quirk for such eDP panels using
> > their vendor ID and product ID to force using max lane count in the driver.
>
> Rather than opening the quirk can of worms I think we should consider
> changing the retry loop to do something more sensible than what it's
> doing now. The current behaviour of "start at optimal settings (which
> can be either min lanes or min rate), and then reduce lanes/rate until
> stuff works" overlooks several possible combinations. One possible
> approach could be to start the retry loop with max lanes + max rate
> after the optimal settings have failed. It probably won't give you
> the best power consumption, but at least you get a picture on the
> screen if even a single lane count + rate combo works.
>
So you are saying that for eDP only we should modify the retry function to
retry with max lanes and max rate so what we used to do earlier with < eDP 1.4?
Hmm I could try doing that, the only concern I have there is that certain eDP
panels just need a retry at same parameters to work so for such panels
where the lower values of link rate/lane count work with just an extra retry
we would still be using max link rate /lane count now with this change.
Or are you suggesting doing the retry with same params for edp < 1.4 and for all
edp 1.4 , we retry with , max link rate lane ocunt?
Manasi
> >
> > Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Tested-by: Albert Astals Cid <aacid@kde.org>
> > Tested-by: Emanuele Panigati <ilpanich@gmail.com>
> > Tested-by: Ralgor <ralgorfdb@compuspex.org>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > ---
> > drivers/gpu/drm/drm_edid.c | 10 ++++++++++
> > include/drm/drm_connector.h | 5 +++++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 2c22ea446075..fbc661806484 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -82,6 +82,8 @@
> > #define EDID_QUIRK_FORCE_10BPC (1 << 11)
> > /* Non desktop display (i.e. HMD) */
> > #define EDID_QUIRK_NON_DESKTOP (1 << 12)
> > +/* Force max lane count */
> > +#define EDID_QUIRK_FORCE_MAX_LANE_COUNT (1 << 13)
> >
> > struct detailed_mode_closure {
> > struct drm_connector *connector;
> > @@ -189,6 +191,10 @@ static const struct edid_quirk {
> >
> > /* OSVR HDK and HDK2 VR Headsets */
> > { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
> > +
> > + /* SHP eDP 1.4 panel only works with max lane count */
> > + { "SHP", 0x149a, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
> > + { "SHP", 0x148e, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
> > };
> >
> > /*
> > @@ -4463,6 +4469,7 @@ drm_reset_display_info(struct drm_connector *connector)
> > memset(&info->hdmi, 0, sizeof(info->hdmi));
> >
> > info->non_desktop = 0;
> > + info->force_max_lane_count = 0;
> > }
> >
> > u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)
> > @@ -4744,6 +4751,9 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> > if (quirks & EDID_QUIRK_FORCE_12BPC)
> > connector->display_info.bpc = 12;
> >
> > + if (quirks & EDID_QUIRK_FORCE_MAX_LANE_COUNT)
> > + connector->display_info.force_max_lane_count = true;
> > +
> > return num_modes;
> > }
> > EXPORT_SYMBOL(drm_add_edid_modes);
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 02a131202add..45436d40ffe3 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -457,6 +457,11 @@ struct drm_display_info {
> > * @non_desktop: Non desktop display (HMD).
> > */
> > bool non_desktop;
> > +
> > + /**
> > + * @force_max_lane_count: Link training requires max lane count to pass
> > + */
> > + bool force_max_lane_count;
> > };
> >
> > int drm_display_info_set_bus_formats(struct drm_display_info *info,
> > --
> > 2.19.1
>
> --
> Ville Syrjälä
> Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-03 18:37 ` Manasi Navare
@ 2019-04-03 18:55 ` Ville Syrjälä
2019-04-03 19:07 ` Manasi Navare
0 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2019-04-03 18:55 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx, dri-devel
On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > > For certain eDP 1.4 panels, we need to use max lane count for the
> > > link training to succeed.
> > >
> > > This patch adds a EDID quirk for such eDP panels using
> > > their vendor ID and product ID to force using max lane count in the driver.
> >
> > Rather than opening the quirk can of worms I think we should consider
> > changing the retry loop to do something more sensible than what it's
> > doing now. The current behaviour of "start at optimal settings (which
> > can be either min lanes or min rate), and then reduce lanes/rate until
> > stuff works" overlooks several possible combinations. One possible
> > approach could be to start the retry loop with max lanes + max rate
> > after the optimal settings have failed. It probably won't give you
> > the best power consumption, but at least you get a picture on the
> > screen if even a single lane count + rate combo works.
> >
>
> So you are saying that for eDP only we should modify the retry function to
> retry with max lanes and max rate so what we used to do earlier with < eDP 1.4?
>
> Hmm I could try doing that, the only concern I have there is that certain eDP
> panels just need a retry at same parameters to work so for such panels
> where the lower values of link rate/lane count work with just an extra retry
> we would still be using max link rate /lane count now with this change.
If the panels are borked then I wouln't worry about it as long a picture
appaears on the screen. And if the extra training cycle is because of
some bug in our code then we should figure it out what that bug is.
>
> Or are you suggesting doing the retry with same params for edp < 1.4 and for all
> edp 1.4 , we retry with , max link rate lane ocunt?
retrain_fail()
{
if (!use_max_params) {
use_max_params = true;
rate = max;
lanes = max;
} else {
reduce rate/lanes as usual
}
}
compute_config()
{
if (use_max_params) {
limits.min = limits.max;
}
...
}
or something like that.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-03 18:55 ` Ville Syrjälä
@ 2019-04-03 19:07 ` Manasi Navare
2019-04-03 19:22 ` Ville Syrjälä
0 siblings, 1 reply; 13+ messages in thread
From: Manasi Navare @ 2019-04-03 19:07 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, dri-devel
On Wed, Apr 03, 2019 at 09:55:56PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> > On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > > > For certain eDP 1.4 panels, we need to use max lane count for the
> > > > link training to succeed.
> > > >
> > > > This patch adds a EDID quirk for such eDP panels using
> > > > their vendor ID and product ID to force using max lane count in the driver.
> > >
> > > Rather than opening the quirk can of worms I think we should consider
> > > changing the retry loop to do something more sensible than what it's
> > > doing now. The current behaviour of "start at optimal settings (which
> > > can be either min lanes or min rate), and then reduce lanes/rate until
> > > stuff works" overlooks several possible combinations. One possible
> > > approach could be to start the retry loop with max lanes + max rate
> > > after the optimal settings have failed. It probably won't give you
> > > the best power consumption, but at least you get a picture on the
> > > screen if even a single lane count + rate combo works.
> > >
> >
> > So you are saying that for eDP only we should modify the retry function to
> > retry with max lanes and max rate so what we used to do earlier with < eDP 1.4?
> >
> > Hmm I could try doing that, the only concern I have there is that certain eDP
> > panels just need a retry at same parameters to work so for such panels
> > where the lower values of link rate/lane count work with just an extra retry
> > we would still be using max link rate /lane count now with this change.
>
> If the panels are borked then I wouln't worry about it as long a picture
> appaears on the screen. And if the extra training cycle is because of
> some bug in our code then we should figure it out what that bug is.
>
But we should do this retrain() in our existing modeset_retry() and intel_dp_get_fallback_values()
and only do it for eDP right?
Because DP we have the retrain loops as per the compliance, if we change that that will
affect all the compliance tests.
Manasi
> >
> > Or are you suggesting doing the retry with same params for edp < 1.4 and for all
> > edp 1.4 , we retry with , max link rate lane ocunt?
>
> retrain_fail()
> {
> if (!use_max_params) {
> use_max_params = true;
> rate = max;
> lanes = max;
> } else {
> reduce rate/lanes as usual
> }
> }
>
> compute_config()
> {
> if (use_max_params) {
> limits.min = limits.max;
> }
> ...
> }
>
> or something like that.
>
> --
> Ville Syrjälä
> Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-03 19:07 ` Manasi Navare
@ 2019-04-03 19:22 ` Ville Syrjälä
2019-04-03 19:52 ` Manasi Navare
0 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2019-04-03 19:22 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx, dri-devel
On Wed, Apr 03, 2019 at 12:07:35PM -0700, Manasi Navare wrote:
> On Wed, Apr 03, 2019 at 09:55:56PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> > > On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > > > > For certain eDP 1.4 panels, we need to use max lane count for the
> > > > > link training to succeed.
> > > > >
> > > > > This patch adds a EDID quirk for such eDP panels using
> > > > > their vendor ID and product ID to force using max lane count in the driver.
> > > >
> > > > Rather than opening the quirk can of worms I think we should consider
> > > > changing the retry loop to do something more sensible than what it's
> > > > doing now. The current behaviour of "start at optimal settings (which
> > > > can be either min lanes or min rate), and then reduce lanes/rate until
> > > > stuff works" overlooks several possible combinations. One possible
> > > > approach could be to start the retry loop with max lanes + max rate
> > > > after the optimal settings have failed. It probably won't give you
> > > > the best power consumption, but at least you get a picture on the
> > > > screen if even a single lane count + rate combo works.
> > > >
> > >
> > > So you are saying that for eDP only we should modify the retry function to
> > > retry with max lanes and max rate so what we used to do earlier with < eDP 1.4?
> > >
> > > Hmm I could try doing that, the only concern I have there is that certain eDP
> > > panels just need a retry at same parameters to work so for such panels
> > > where the lower values of link rate/lane count work with just an extra retry
> > > we would still be using max link rate /lane count now with this change.
> >
> > If the panels are borked then I wouln't worry about it as long a picture
> > appaears on the screen. And if the extra training cycle is because of
> > some bug in our code then we should figure it out what that bug is.
> >
>
> But we should do this retrain() in our existing modeset_retry() and intel_dp_get_fallback_values()
> and only do it for eDP right?
> Because DP we have the retrain loops as per the compliance, if we change that that will
> affect all the compliance tests.
I have a rather low opinion on the compliance tests. If they are
preventing sensible real world things then what good are they?
Someone should probably figure out what it would take to make
them more useful...
But anyways, I guess we can start with eDP. If it looks like
DP could benefit as well we might have to consider it.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count
2019-04-03 19:22 ` Ville Syrjälä
@ 2019-04-03 19:52 ` Manasi Navare
0 siblings, 0 replies; 13+ messages in thread
From: Manasi Navare @ 2019-04-03 19:52 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, dri-devel
On Wed, Apr 03, 2019 at 10:22:16PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 03, 2019 at 12:07:35PM -0700, Manasi Navare wrote:
> > On Wed, Apr 03, 2019 at 09:55:56PM +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> > > > On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > > > > > For certain eDP 1.4 panels, we need to use max lane count for the
> > > > > > link training to succeed.
> > > > > >
> > > > > > This patch adds a EDID quirk for such eDP panels using
> > > > > > their vendor ID and product ID to force using max lane count in the driver.
> > > > >
> > > > > Rather than opening the quirk can of worms I think we should consider
> > > > > changing the retry loop to do something more sensible than what it's
> > > > > doing now. The current behaviour of "start at optimal settings (which
> > > > > can be either min lanes or min rate), and then reduce lanes/rate until
> > > > > stuff works" overlooks several possible combinations. One possible
> > > > > approach could be to start the retry loop with max lanes + max rate
> > > > > after the optimal settings have failed. It probably won't give you
> > > > > the best power consumption, but at least you get a picture on the
> > > > > screen if even a single lane count + rate combo works.
> > > > >
> > > >
> > > > So you are saying that for eDP only we should modify the retry function to
> > > > retry with max lanes and max rate so what we used to do earlier with < eDP 1.4?
> > > >
> > > > Hmm I could try doing that, the only concern I have there is that certain eDP
> > > > panels just need a retry at same parameters to work so for such panels
> > > > where the lower values of link rate/lane count work with just an extra retry
> > > > we would still be using max link rate /lane count now with this change.
> > >
> > > If the panels are borked then I wouln't worry about it as long a picture
> > > appaears on the screen. And if the extra training cycle is because of
> > > some bug in our code then we should figure it out what that bug is.
> > >
> >
> > But we should do this retrain() in our existing modeset_retry() and intel_dp_get_fallback_values()
> > and only do it for eDP right?
> > Because DP we have the retrain loops as per the compliance, if we change that that will
> > affect all the compliance tests.
>
> I have a rather low opinion on the compliance tests. If they are
> preventing sensible real world things then what good are they?
> Someone should probably figure out what it would take to make
> them more useful...
>
> But anyways, I guess we can start with eDP. If it looks like
> DP could benefit as well we might have to consider it.
>
I agree, i will add a patch for edp first and have the folks test it with the
edp panels that needed the quirk.
DP we really havent had any similar failures where we absolutely need max vales.
Manasi
> --
> Ville Syrjälä
> Intel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread