[Intel-gfx] [PATCH v2 2/2] drm/i915/mst: Continue state updates even if AUX writes fail.
Dhinakaran Pandiyan
dhinakaran.pandiyan at intel.com
Wed Jul 25 18:39:45 UTC 2018
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
More information about the Intel-gfx
mailing list