Re: [PATCH 1/2] drm/i915/guc: Add error-capture init warnings when needed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > Also commit message you can aim to wrap at 75 chars as per submitting-patches.rst.
> > > 
> > > > +		return -ENODATA;
> > > 
> > > Is this a new exit condition or the thing would exit on the !num_regs check below anyway? Just wondering if the series is only about logging changes or there is more to it.
> > Its no different from previous behavior - and yes its about logging the missing reg lists for hw that needs it as we are
> > missing this for DG2 we we didn't notice (we did a previous revert to remove these warnings but that time the warnings
> > was too verbose - even complaining for the intentional empty lists and for VF cases that isnt supported).
> 
> Okay think I get it, thanks. If the "positive match" logging of empty 
> list is more future proof than "negative - don't log these" you will 
> know better.

NOTE: John and I had an offline conversation and we are aware that there will still be a case where
we can miss new-platform updates for guc-error-capture without being alerted by a warning:
Let's take the example of the empty blitter's engine-class-register-list. We dont have such a thing on
today's hardware.. we only have blitter's engine-register-list ... i.e. HEAD, TAIL etc. But if a future
platform were to introduce a blitter engine-class-register-list, we wont get a warning since the empty
list is there to prevent unnecessary warning for today's hardware. But we know this is better than
having to explain unnecessary warnings (which was the reason why a more verbose version of this code
was removed in the past).

I believe we are good with this solution here for now.





[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux