[Intel-gfx] [PATCH v2 2/2] drm/i915/mst: Continue state updates even if AUX writes fail.

[Dhinakaran Pandiyan]

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 at intel.com>
> 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.