On Wed, 2018-07-25 at 11:39 -0700, Dhinakaran Pandiyan wrote: > On Thu, 2018-07-19 at 16:37 -0700, Rodrigo Vivi wrote: > > > > On Thu, Jul 19, 2018 at 11:51:40AM -0700, Dhinakaran Pandiyan > > wrote: > > > > > > > > > On Wed, 2018-07-18 at 22:43 -0700, Rodrigo Vivi wrote: > > > > > > > > > > > > On Wed, Jul 18, 2018 at 10:19:43AM -0700, Dhinakaran Pandiyan > > > > wrote: > > > > > > > > > > > > > > > > > > > > We are too late in the enabling sequence to back out cleanly, > > > > > not > > > > > updating > > > > > state tracking variables, like intel_dp->active_mst_links in > > > > > this > > > > > instance, results in incorrect behaviour further along. > > > > I agree with you, although I'm not fully convinced that we need > > > > to > > > > call the > > > > update payload if vcpi allocation failed... > > > But there is more payload update code in intel_mst_enable_dp(), > > oh... the part2 indeed... > > > > > > > > > > > that > > > would get executed regardless of this diff below. We'll have to > > > rewrite > > > pre_enable, enable, disable and post_disable if the idea is avoid > > > sink > > > transactions after the first failure. It does make sense to do > > > all > > > of > > > that as it avoids printing error messages in dmesg when we very > > > well > > > know the branch device is disconnected, but this should be a > > > separate > > > change. > > fair enough... > > > > > > > > > > > My idea was to bring pre_enable/enable in line with > > > disable/post_disable. > > makes sense... I just saw it is similar on payload update failure. > > > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > Thanks for the review, I will push this with > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107281 Pushed after checking the logs of failures - none of them were related to the patch series. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
