On Mon, 2018-10-15 at 14:20 -0700, Rodrigo Vivi wrote: > On Mon, Oct 15, 2018 at 03:59:36PM -0400, Lyude Paul wrote: > > Poke: still wondering what we should do about the patch in these fixes > > that > > came up a little later which got Cc'd to stable, despite it apparently not > > being a patch we want in stable (mentioned this over IRC): > > > > https://patchwork.freedesktop.org/patch/255428/ and > > https://patchwork.freedesktop.org/series/50770/ > > Thanks for bringing this up. > > So, These 2 patches are merged on the tree, but we don't want > them propagated to stable tree anymore? Do we have a fix for those? > Or are we reverting them? I am in the process of making a fix and am just about finished; just had to clear some corner cases up with danvet. I think we should be fine if we do either one of two things: * Just cc the third patch (once I've got it on the ML today) to stable, since I did want the problem these were intended to fix to also be fixed downstream, and while messy it should take care of fixing the problems that were introduced. * Don't cc the two patches to stable, and I can just handle backporting the third and final fix to stable This is a new situation for me, so I'm honestly not sure which of those two would be the best approach. [more below] > > We probably want to raise this up to Greg so he doesn't pick > them when running his stable scripts. > > But also I was wondering another aspect of these patches I had here > on this dropped list. > > In the end most of patches that was here will be picked by Greg's > stable scripts anyways. > > Also other patches with cc:stable that were on that round > but got removed: > > commit 1e712535c51a ("drm/i915/dp: Link train Fallback on eDP only if > fallback link BW can fit panel's native mode") According to Manasi earlier in the thread: "I am okay with that w.r.t my patch ("drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode")" So I think waiting until v4.19 on that one should be fine. > commit 62358aa4ee86 ("drm/i915: Use the correct crtc when sanitizing plane > mapping") > commit 68bc30deac62 ("drm/i915: Restore vblank interrupts earlier") > Can't speak for these two though > Should I add back at least these patches this week? > Or we should really wait for 4.19 to be released? > > Thanks, > Rodrigo. > > > > > On Thu, 2018-10-11 at 09:17 +1000, David Airlie wrote: > > > On Thu, Oct 11, 2018 at 8:53 AM Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > wrote: > > > > > > > > Hi all, > > > > > > > > I need your help to decide what to do with this round of fixes. > > > > > > > > I have collected these patches this week: > > > > > > > > commit b43e8916172a ("drm/i915/dp: Link train Fallback on eDP only if > > > > fallback link BW can fit panel's native mode") > > > > commit 5abb01e541ed ("drm/i915: Fix intel_dp_mst_best_encoder()") > > > > commit 02713246296d ("drm/i915: Skip vcpi allocation for MSTB ports > > > > that > > > > are gone") > > > > commit cc6e027f5f50 ("drm/i915: Don't unset intel_connector- > > > > >mst_port") > > > > commit f5aec50ba21e ("drm/i915: Use the correct crtc when sanitizing > > > > plane > > > > mapping") > > > > commit 6547684bf50a ("drm/i915: Restore vblank interrupts earlier") > > > > > > > > CI_DIF_309 represents Greg's v4.19-rc7 and it is clean. > > > > > > > > However 2 following CI runs are kind of strange. > > > > > > > > There's few underruns here and there, but those looks flip-flops. > > > > > > > > My biggest concern is specially around: > > > > > > > > igt@kms_plane@pixel-format-pipe-a-planes: > > > > https://intel-gfx-ci.01.org/tree/drm-intel-fixes/shards.html > > > > > > > > > > > > https://intel-gfx-ci.01.org/tree/drm-intel-fixes/CI_DIF_311/shard-glk8/igt@kms_plane@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > Thoughts? > > > > > > > > I'm holding the pull request for now and will try to do some local > > > > tests > > > > here > > > > to see if I can identify a culprit. > > > > > > At this late in the game for rc8, unless these fix a major regression > > > in the current tree, I'd say drop them until -next. > > > > > > Dave. > > > > -- > > Cheers, > > Lyude Paul > > -- Cheers, Lyude Paul _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
