Re: [PATCH v3 4/8] drm/i915/gt/selftests: Use drm_* prints in aggregated gt selftests

[Andi Shyti <andi.shyti@kernel.org>]

Hi Krzysztof,

On Tue, Sep 29, 2026 at 12:06:15PM +0000, Krzysztof Karas wrote:
> On 2026-09-09 at 23:25:55 +0200, Andi Shyti wrote:
> > On Thu, Sep 03, 2026 at 12:39:10PM +0000, Krzysztof Karas wrote:
> > > On 2026-08-28 at 18:18:35 +0200, Andi Shyti wrote:
> > > > On Fri, Aug 28, 2026 at 10:03:35AM +0000, Krzysztof Karas wrote:
> > > > > Move away from generic pr prints to device context aware drm
> > > > > versions.
> > > > > 
> > > > > Assisted-by: GitHub-Copilot:claude-opus-5
> > > > 
> > > > what a ride!
> > > > 
> > > > While reviewing everything I was thinking whether it would make
> > > > sense to add an i915_err() like xe and gt.
> > > The idea makes sense, the question is when to introduce this
> > > macro. I have the v4 pretty much ready to send, apart from a few
> > > minor issues I have to fix, but I am not against modifying it to
> > > accomodate i915_* family of prints.
> > > If we agreed on this, then we'd have this new macro ready when
> > > we'd be replacing pr_* prints in other parts of the driver.
> > > 
> > > I think it would be worth to keep the series in the oven for a
> > > few more days, especially when it is not that critical of a
> > > change. What do you think?
> > 
> > yes, i915_* can come later, of course, it's out of the scope of
> > this series.
> > 
> > Andi
> 
> I checked again and again these past two weeks for your reply
> and none came into my inbox, only for me to notice today that it
> was finally pulled by my mailer client recently. I posted
> another version of this series, because I was under the
> impression that silence meant I should introduce the i915_*
> prints. That version was met with disapproval from Jani as well,
> so please just ignore v4.
> Sorry for the spam.

it's also true that I haven't been very active in reviews lately.

Are you now preparing a v5?

Andi