On Tue, Oct 04, 2022 at 06:46:10AM -0500, David Matthew Mattli wrote: > Thorsten Leemhuis writes: > > > On 03.10.22 19:48, Ville Syrjälä wrote: > >> On Mon, Oct 03, 2022 at 08:45:18PM +0300, Ville Syrjälä wrote: > >>> On Sat, Oct 01, 2022 at 12:07:39PM +0200, Thorsten Leemhuis wrote: > >>>> On 30.09.22 14:26, Jerry Ling wrote: > >>>>> > >>>>> looks like someone has done it: > >>>>> https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823 > >>>>> > >>>>> and the bisect points to: > >>>>> > >>>>> |# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] > >>>>> drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry > | > >>>> > >>>> FWIW, that's 3cf050762534 in mainline. Adding Ville, its author to the > >>>> list of recipients. > >>> > >>> I definitely had no plans to backport any of that stuff, > >>> but I guess the automagics did it anyway. > >>> > >>> Looks like stable is at least missing this pile of stuff: > >>> 50759c13735d drm/i915/pps: Keep VDD enabled during eDP probe > >>> 67090801489d drm/i915/pps: Reinit PPS delays after VBT has been fully > parsed > >>> 8e75e8f573e1 drm/i915/pps: Split PPS init+sanitize in two > >>> 586294c3c186 drm/i915/pps: Stash away original BIOS programmed PPS delays > >>> 89fcdf430599 drm/i915/pps: Don't apply quirks/etc. to the VBT PPS > >>> delays if they haven't been initialized > >>> 60b02a09598f drm/i915/pps: Introduce pps_delays_valid() > >>> > >>> But dunno if even that is enough. > > > > If you need testers: David (now CCed) apparently has a affected machine > > and offered to test patches in a different subthread of this thread. > > > > I cherry-picked the six commits Thorsten listed onto 5.19.12 and it > resolved the issue on my Framework laptop. Thanks for testing, but I'm just going to revert the offending commits as they probably shouldn't all be added to 5.19.y thanks, greg k-h
