[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aGKH8HUtiqID1mbe@pollux>
Date: Mon, 30 Jun 2025 14:49:52 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Philipp Stanner <phasta@...nel.org>
Cc: Matthew Brost <matthew.brost@...el.com>,
Christian König <ckoenig.leichtzumerken@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Tvrtko Ursulin <tvrtko.ursulin@...lia.com>,
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@....com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/sched/tests: Make timedout_job callback a better
role model
On Thu, Jun 05, 2025 at 03:41:55PM +0200, Philipp Stanner wrote:
> Since the drm_mock_scheduler does not have real users in userspace, nor
> does it have real hardware or firmware rings, it's not necessary to
> signal timedout fences nor free jobs - from a functional standpoint.
>
> The unit tests, however, serve as a reference implementation and a first
> example for new scheduler users. Therefore, they should approximate the
> canonical usage as much as possible.
>
> Make sure timed out hardware fences get signaled with the appropriate
> error code.
>
> Signed-off-by: Philipp Stanner <phasta@...nel.org>
Given the discussion on this patch we agree that, unit test should remain to be
unit tests, but at the same time (as far as possible) represent the intended
usage of the scheduler's APIs.
Given that, "reference implementation" might be slightly overstated and we
should just say something along the lines of "make them represent the intended
usage of the scheduler's APIs".
Also, since this patch is a prerequisite of your teardown series, please mention
that in the commit message.
With that:
Acked-by: Danilo Krummrich <dakr@...nel.org>
Fine for me if you fix up those two nits when applying the patch.
- Danilo
Powered by blists - more mailing lists