linux-toradex.git/drivers/gpu/drm/etnaviv, branch v6.8-rc2

drm/etnaviv: Convert to platform remove callback returning void

2023-11-21T08:17:54+00:00

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert the etnaviv drm driver from always returning zero in
the remove callback to the void returning variant.

Reviewed-by: Thomas Zimmermann 
Reviewed-by: Jyri Sarha 
Signed-off-by: Uwe Kleine-König 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20231102165640.3307820-25-u.kleine-koenig@pengutronix.de

drm/sched: implement dynamic job-flow control

2023-11-10T01:54:29+00:00

Currently, job flow control is implemented simply by limiting the number
of jobs in flight. Therefore, a scheduler is initialized with a credit
limit that corresponds to the number of jobs which can be sent to the
hardware.

This implies that for each job, drivers need to account for the maximum
job size possible in order to not overflow the ring buffer.

However, there are drivers, such as Nouveau, where the job size has a
rather large range. For such drivers it can easily happen that job
submissions not even filling the ring by 1% can block subsequent
submissions, which, in the worst case, can lead to the ring run dry.

In order to overcome this issue, allow for tracking the actual job size
instead of the number of jobs. Therefore, add a field to track a job's
credit count, which represents the number of credits a job contributes
to the scheduler's credit limit.

Signed-off-by: Danilo Krummrich 
Reviewed-by: Luben Tuikov 
Link: https://patchwork.freedesktop.org/patch/msgid/20231110001638.71750-1-dakr@redhat.com

drm/sched: Convert drm scheduler to use a work queue rather than kthread

2023-11-01T21:29:21+00:00

In Xe, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.

1. In Xe the submission order from multiple drm_sched_entity is not
guaranteed to be the same completion even if targeting the same hardware
engine. This is because in Xe we have a firmware scheduler, the GuC,
which allowed to reorder, timeslice, and preempt submissions. If a using
shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls
apart as the TDR expects submission order == completion order. Using a
dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.

2. In Xe submissions are done via programming a ring buffer (circular
buffer), a drm_gpu_scheduler provides a limit on number of jobs, if the
limit of number jobs is set to RING_SIZE / MAX_SIZE_PER_JOB we get flow
control on the ring for free.

A problem with this design is currently a drm_gpu_scheduler uses a
kthread for submission / job cleanup. This doesn't scale if a large
number of drm_gpu_scheduler are used. To work around the scaling issue,
use a worker rather than kthread for submission / job cleanup.

v2:
  - (Rob Clark) Fix msm build
  - Pass in run work queue
v3:
  - (Boris) don't have loop in worker
v4:
  - (Tvrtko) break out submit ready, stop, start helpers into own patch
v5:
  - (Boris) default to ordered work queue
v6:
  - (Luben / checkpatch) fix alignment in msm_ringbuffer.c
  - (Luben) s/drm_sched_submit_queue/drm_sched_wqueue_enqueue
  - (Luben) Update comment for drm_sched_wqueue_enqueue
  - (Luben) Positive check for submit_wq in drm_sched_init
  - (Luben) s/alloc_submit_wq/own_submit_wq
v7:
  - (Luben) s/drm_sched_wqueue_enqueue/drm_sched_run_job_queue
v8:
  - (Luben) Adjust var names / comments

Signed-off-by: Matthew Brost 
Reviewed-by: Luben Tuikov 
Link: https://lore.kernel.org/r/20231031032439.1558703-3-matthew.brost@intel.com
Signed-off-by: Luben Tuikov

drm/sched: Convert the GPU scheduler to variable number of run-queues

2023-10-26T16:03:47+00:00

The GPU scheduler has now a variable number of run-queues, which are set up at
drm_sched_init() time. This way, each driver announces how many run-queues it
requires (supports) per each GPU scheduler it creates. Note, that run-queues
correspond to scheduler "priorities", thus if the number of run-queues is set
to 1 at drm_sched_init(), then that scheduler supports a single run-queue,
i.e. single "priority". If a driver further sets a single entity per
run-queue, then this creates a 1-to-1 correspondence between a scheduler and
a scheduled entity.

Cc: Lucas Stach 
Cc: Russell King 
Cc: Qiang Yu 
Cc: Rob Clark 
Cc: Abhinav Kumar 
Cc: Dmitry Baryshkov 
Cc: Danilo Krummrich 
Cc: Matthew Brost 
Cc: Boris Brezillon 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Emma Anholt 
Cc: etnaviv@lists.freedesktop.org
Cc: lima@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov 
Acked-by: Christian König 
Link: https://lore.kernel.org/r/20231023032251.164775-1-luben.tuikov@amd.com

Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next

2023-08-17T20:42:12+00:00

This time mostly cleanups around the runtime power management handling
and slightly improved GPU hang handling. Also some additions to the
HWDB to get the driver working properly on more NXP i.MX8MP IP cores.

Signed-off-by: Dave Airlie 
From: Lucas Stach 
Link: https://patchwork.freedesktop.org/patch/msgid/f40c65f7ecfde2e61f1a6d7fd463f6f739bc0dd1.camel@pengutronix.de

drm: Explicitly include correct DT includes

2023-07-21T07:12:43+00:00

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring 
Acked-by: Sam Ravnborg 
Reviewed-by: Steven Price 
Acked-by: Liviu Dudau 
Reviewed-by: Kieran Bingham 
Acked-by: Robert Foss 
Signed-off-by: Thierry Reding 
Link: https://patchwork.freedesktop.org/patch/msgid/20230714174545.4056287-1-robh@kernel.org

drm/etnaviv: fix error code in event_alloc()

2023-07-19T10:36:25+00:00

There are two "ret" variables declared in this function so setting
"ret = -EBUSY;" sets the wrong one.  The function ends up returning an
uninitialized variable.

Fixes: f098f9b8042a ("drm/etnaviv: move runtime PM handling to events")
Signed-off-by: Dan Carpenter 
Signed-off-by: Lucas Stach

drm/etnaviv: expedited MMU fault handling

2023-07-17T09:32:34+00:00

The GPU is halted when it hits a MMU exception, so there is no point in
waiting for the job timeout to expire or try to work out if the GPU is
still making progress in the timeout handler, as we know that the GPU
won't make any more progress.

Signed-off-by: Lucas Stach 
Reviewed-by: Christian Gmeiner

drm/etnaviv: drop GPU initialized property

2023-07-17T09:32:31+00:00

Now that it is only used to track the driver internal state of
the MMU global and cmdbuf objects, we can get rid of this property
by making the free/finit functions of those objects safe to call
on an uninitialized object.

Signed-off-by: Lucas Stach 
Reviewed-by: Christian Gmeiner

drm/etnaviv: better track GPU state

2023-07-17T09:32:27+00:00

Instead of only tracking if the FE is running, use a enum to better
describe the various states the GPU can be in. This allows some
additional validation to make sure that functions that expect a
certain GPU state are only called when the GPU is actually in that
state.

Signed-off-by: Lucas Stach 
Reviewed-by: Christian Gmeiner