NACK/Cmnt: [PATCH 00/18][SRU][G][HWE-5.8] Fix compatibility issue on some external monitors
Stefan Bader
stefan.bader at canonical.com
Thu Apr 8 06:07:37 UTC 2021
On 08.04.21 07:56, Stefan Bader wrote:
> On 23.03.21 09:27, Stefan Bader wrote:
>> On 22.03.21 16:47, Aaron Ma wrote:
>>> BugLink: https://bugs.launchpad.net/bugs/1920777
>>>
>>> [Impact]
>>> Some external monitors got black screen via HDMI on laptops with Intel
>>> GPU.
>>>
>>> [Fix]
>>> Reading more of the port caps and dealing with various clock/bpc
>>> limitations.
>>> Patchset:
>>> https://patchwork.freedesktop.org/series/72928/
>>>
>>> [Test Case]
>>> Verified on the target platform and other 2 laptops include workstation,
>>> Tested on LG/ThinkVision 4k monitors and Dell 1080p monitor, include
>>> dock station.
>>> All good.
>>>
>>> [Where problems could occur]
>>> Intel GPU may lose or mess the output.
>>>
>>> These patches are most backported from 5.10-rc1 and one from 5.11-rc5.
>>> Hirsute/Unstable already got them.
>>>
>>> Ville Syrjälä (18):
>>> drm/i915/lspcon: Do not send infoframes to non-HDMI sinks
>>> drm/dp: Define protocol converter DPCD registers
>>> drm/dp: Define more downstream facing port caps
>>> drm/i915: Reworkd DFP max bpc handling
>>> drm/dp: Add helpers to identify downstream facing port types
>>> drm/dp: Pimp drm_dp_downstream_max_bpc()
>>> drm/dp: Redo drm_dp_downstream_max_clock() as
>>> drm_dp_downstream_max_dotclock()
>>> drm/i915: Reworkd DP DFP clock handling
>>> drm/dp: Add drm_dp_downstream_{min,max}_tmds_clock()
>>> drm/i915: Deal with TMDS DFP clock limits
>>> drm/i915: Configure DP 1.3+ protocol converted HDMI mode
>>> drm/dp: Add drm_dp_downstream_mode()
>>> drm/i915: Handle downstream facing ports w/o EDID
>>> drm/i915: Extract intel_hdmi_has_audio()
>>> drm/i915: DP->HDMI TMDS clock limits vs. deep color
>>> drm/dp: Add helpers for DFP YCbCr 4:2:0 handling
>>> drm/i915: Do YCbCr 444->420 conversion via DP protocol converters
>>> drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting
>>> YCbCr 4:4:4
>>>
>>> drivers/gpu/drm/drm_dp_helper.c | 381 ++++++++++++++++--
>>> drivers/gpu/drm/drm_edid.c | 28 ++
>>> drivers/gpu/drm/i915/display/intel_ddi.c | 11 +-
>>> .../drm/i915/display/intel_display_debugfs.c | 3 +-
>>> .../drm/i915/display/intel_display_types.h | 9 +
>>> drivers/gpu/drm/i915/display/intel_dp.c | 305 +++++++++++---
>>> drivers/gpu/drm/i915/display/intel_dp.h | 2 +
>>> drivers/gpu/drm/i915/display/intel_hdmi.c | 82 ++--
>>> drivers/gpu/drm/i915/display/intel_hdmi.h | 2 +
>>> include/drm/drm_dp_helper.h | 63 ++-
>>> include/drm/drm_edid.h | 4 +
>>> 11 files changed, 758 insertions(+), 132 deletions(-)
>>>
>> First why is this explicitly targeted to focal:linux-hwe-5.8 when also asked
>> to be applied to groovy:linux? Hwe kernels are and always have been backports
>> from the respective series primary kernel.
>> Second, is this really the minimal set required to fix the problems? This
>> looks more to be a partial rework and for that testing only on 3 machines
>> (which does not say anything about which generations of Intel graphics get
>> covered). For a change that huge I would rather expect to cover the whole
>> range of generations we still have around.
>> The patches seem to origin from 5.10..5.11 which means the broadest range of
>> testing would not happen before Hirsute does release. Before that I am rather
>> suspicious the bigger the change set becomes.
>>
>> -Stefan
>>
>>
> There has not been any update on this and this still is a rather extensive set.
> Bug fixes should try to be as small as possible because the bigger the change
> the greater the risk to cause some unforeseen problems.
> In some cases this maybe is not possible. But then this should be explained in
> more detail and also testing should be at a wider range. Especially with i915
> which has been breaking older generations of the GPU.
> In this case it seems the better option is to wait for the hirsute/5.11 kernel
> to replace the groovy/5.8 one as focal hwe kernel.
>
> -Stefan
>
>
PS: Generally, if a set really needs to consist of more than ~5 patches, it
would be preferable to have a pull request at least embedded in the cover email
(or just a pull request style submission overall).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20210408/edc237d4/attachment.sig>
More information about the kernel-team
mailing list