Max Zhen [Tue, 21 Apr 2026 18:15:02 +0000 (11:15 -0700)]
accel/amdxdna: Improve tracing for job lifecycle and mailbox RX worker
Add more trace coverage to amdxdna job handling and mailbox receive
processing to make driver execution easier to debug.
Extend the xdna_job trace event to record the command opcode in
addition to the job sequence number. Use the enhanced tracepoint in
the job run, sent-to-device, signaled-fence, and job-free paths so
that trace output can be correlated with the command being executed.
Also add debug-point tracing when a command is received through the
submit ioctl path, and add a trace event when the mailbox RX worker
runs.
These changes improve visibility into job lifetime transitions and
mailbox activity, which helps debug command flow and scheduler issues.
Jonathan Cavitt [Thu, 16 Apr 2026 21:00:47 +0000 (05:00 +0800)]
drm/auth: Only drm_drop_master if it exists
It is possible that both dev->master and file_priv->master are NULL when
passed to drm_master_release, which would result in dev being passed to
drm_drop_master (as NULL == NULL here). This would result in a NULL
pointer dereference when passing dev->master to drm_master_put in
drm_drop_master.
Only call drm_drop_master if dev->master exists. Also, make sure the
original calling requirement is maintained (dev->master ==
file_priv->master).
This fixes a static analysis issue.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Acked-by: Luben Tuikov <ltuikov89@gmail.com> Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Link: https://patch.msgid.link/20260416210047.3904106-1-jonathan.cavitt@intel.com
drm/mgag200: Enable DRM_FORMAT_XRGB1555 on the primary plane
The driver already sets the format for the depth value in the XMULCTRL
register. Add the format to the other switch statements, set the helpers
for gamma correction and export the XRGB1555 in the primary plane's
format array.
Replace the deprecated cpp field from struct drm_format_info with the
format's 4CC code when setting the hiprilvl field in CRTCEXT6.
Using a bpp of 32 for RGB888 is a bit dubious, but we keep it for now
to avoid changing behavior. Otherwise, bpp could also be retrieved by
calling drm_format_info_bpp().
The offset value sets the distance in bytes between two consecutive
scanlines. Reduce the calculation to the minimum.
According to the Matrox programming manual, Sec 4.6.5, the offset
is the scanline pitch in bits divided by 128. The field pitches[0] in
struct drm_framebuffer stores the scanline pitch in bytes, so we have
to divide by 16 only. Reducing the existing bpp-shift look-up and
offset calculations also returns exactly this for all formats.
Replace the deprecated cpp value from struct drm_format_info with the
format's 4CC code when setting the scale value in CRTCEXT3. While at it,
remove the scale variable and add a mask constant.
Replace the deprecated cpp value from struct drm_format_info with the
format's 4CC code when setting the depth value in the XMULCTRL register.
Split the 16-bit case into XRGB1555 and RGB565. The default branch cannot
be taken, so remove it.
drm/ast: Support DRM_FORMAT_XRGB1555 on the primary plane
Export DRM_FORMAT_XRGB1555 in the primary plane's format array and
handle the format in the color-format updates. With this, ast is now
feature complete wrt. color-format support.
Also update the comments in the gamma-LUT code to reflect the ast
manual's terminology.
drm/ast: Replace references to struct drm_format_info.cpp
Replace all uses of struct drm_format_info.cpp with the corresponding
4CC constant. Color-mode selection uses switch statements that branch
by cpp in several places. While at it, also name the involved variables
according to register names and replace magic values with constants.
Replace the use of *ModeIndex constants in ast_set_vbios_color_reg()
with correct register constants. The former are array indices and do
not belong into registers.
In ast_set_color_reg(), vgacra0 is independent from the color format,
so move it out from the switch statements.
There is also a flag for gamma correction in vgacra8, which currently
ast_set_color_reg() handles as part of the primary plane. The gamma LUT
and its programming is located in the CRTC. A future update should
consolidate gamma correction in the primary plane and implement the
functionality with DRM's colorop helpers.
drm/ast: Remove traces of DRM_FORMAT_RGB888 handling
There's some incomplete handling for DRM_FORMAT_RGB888 in the mode-
setting code. It was added by ast's original commit, which imported
the code from the user-space Xorg driver. But the hardware doesn't
support 24-bit pixel sizes. Hence remove the traces of RGB888 from
ast.
drm/bridge: waveshare-dsi: support DSI LCD kits with LVDS panels
Several Waveshare DSI LCD kits use LVDS panels and the ICN6202 DSI2LVDS
bridge. Support that setup by handling waveshare,dsi2lvds compatible.
The only difference with the existing waveshare,dsi2dpi is the bridge's
output type (LVDS vs DPI).
Several the Waveshare DSI LCD panel kits use DSI2LVDS ICN6202 bridge
together with the LVDS panels. Define new compatible for the on-kit
bridge setup (it is not itmized and it uses Waveshare prefix since the
rest of the integration details are not known).
Note: the ICN6202 / ICN6211 bridges are completely handled by the board
itself, they should not be programmed by the host (which otherwise might
override correct params), etc. As such, it doesn't make sense to use
those in the compat strings. I consider those to be an internal detail
of the setup.
Add devm_drm_panel_add(), devres-managed version of drm_panel_add().
It's not uncommon for the panel drivers to use devres functions for most
of the resources. Provide corresponding replacement for drm_panel_add().
drm/panel: jadard-jd9365da-h3: set prepare_prev_first
Sending DSI commands from the prepare() callback requires DSI link to be
up at that point. For DSI hosts is guaranteed only if the panel driver
sets the .prepare_prev_first flag. Set it to let these panels work with
the DSI hosts which don't power on the link in their .mode_set callback.
drm/panel: jadard-jd9365da-h3: support variable DSI configuration
Several panels support attachment either using 4 DSI lanes or just 2. In
some cases, this requires a different panel mode to fulfill clock
requirements. Extend the driver to handle such cases by letting the
panel description to omit lanes specification and parsing number of
lanes from the DT.
Sending DSI commands from the prepare() callback requires DSI link to be
up at that point. For DSI hosts is guaranteed only if the panel driver
sets the .prepare_prev_first flag. Set it to let these panels work with
the DSI hosts which don't power on the link in their .mode_set callback.
drm/panel: himax-hx83102: support Waveshare 12.3" DSI panel
Add support for the Waveshare 12.3" DSI TOUCH-A panel. According to the
vendor driver, it uses different mode_flags, so let the panel
descriptions override driver-wide defaults.
drm/of: add helper to count data-lanes on a remote endpoint
If the DSI panel supports versatile lanes configuration, its driver
might require determining the number of DSI data lanes, which is usually
specified on the DSI host side of the OF graph. Add new helper as a
pair to drm_of_get_data_lanes_count_ep() that lets callers determine
number of data-lanes on the remote side of the OF graph.
Max Zhen [Thu, 16 Apr 2026 20:11:06 +0000 (13:11 -0700)]
accel/amdxdna: Guard management mailbox channel cleanup against NULL pointer
The management mailbox channel cleanup helpers can be called from
error handling paths when mgmt_chann has already been destroyed.
Add NULL checks to xdna_mailbox_free_channel() and
xdna_mailbox_stop_channel() so the cleanup path safely returns instead
of dereferencing a NULL mailbox channel pointer.
Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260416201106.1046072-1-lizhi.hou@amd.com
Max Zhen [Thu, 16 Apr 2026 19:01:50 +0000 (12:01 -0700)]
accel/amdxdna: Get device revision to derive VBNV string
Add support for querying the device revision from firmware.
Use the returned revision to look up the VBNV string during device
initialization, and fall back to the default VBNV when the revision
query is not supported or no mapping is found.
This allows the driver to report the accurate VBNV for devices that
share the same vendor/device ID but differ by hardware revision.
Remove member no longer used by the scheduler core.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-20-tvrtko.ursulin@igalia.com
Remove member no longer used by the scheduler core.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-19-tvrtko.ursulin@igalia.com
drm/sched: Embed run queue singleton into the scheduler
Now that the run queue to scheduler relationship is always 1:1 we can
embed it (the run queue) directly in the scheduler struct and save on
some allocation error handling code and such.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-15-tvrtko.ursulin@igalia.com
drm/sched: Remove FIFO and RR and simplify to a single run queue
Since the new FAIR policy is in general better than FIFO and almost as
good as round-robin in interactive use cases, plus the latter has not been
the default policy in a long time, we can afford to remove both and leave
just FAIR.
By doing so we can simplify the scheduler code by making the scheduler to
run queue relationship always 1:1 and remove some code.
Also, now that the FIFO policy is gone the tree of entities is not a FIFO
tree any more so rename it to just the tree.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-14-tvrtko.ursulin@igalia.com
FAIR policy works better than FIFO for all known use cases and either
matches or gets close to RR. Lets make it a default to improve the user
experience especially with interactive workloads competing with heavy
clients.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-13-tvrtko.ursulin@igalia.com
GPUs do not always implement preemption and DRM scheduler definitely
does not support it at the front end scheduling level. This means
execution quanta can be quite long and is controlled by userspace,
consequence of which is picking the "wrong" entity to run can have a
larger negative effect than it would have with a virtual runtime based CPU
scheduler.
Another important consideration is that rendering clients often have
shallow submission queues, meaning they will be entering and exiting the
scheduler's runnable queue often.
Relevant scenario here is what happens when an entity re-joins the
runnable queue with other entities already present. One cornerstone of the
virtual runtime algorithm is to let it re-join at the head and rely on the
virtual runtime accounting and timeslicing to sort it out.
However, as explained above, this may not work perfectly in the GPU world.
Entity could always get to overtake the existing entities, or not,
depending on the submission order and rbtree equal key insertion
behaviour.
Allow interactive jobs to overtake entities already queued up for the
limited case when interactive entity is re-joining the queue after
being idle.
This gives more opportunity for the compositors to have their rendering
executed before the GPU hogs even if they have been configured with the
same scheduling priority.
To classify a client as interactive we look at its average job duration
versus the average for the whole scheduler. We can track this easily by
plugging into the existing job runtime tracking and applying the
exponential moving average window on the past submissions. Then, all other
things being equal, we let the more interactive jobs go first.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-12-tvrtko.ursulin@igalia.com
The FAIR scheduling policy is built upon the same concepts as the well
known CFS CPU scheduler - entity run queue is sorted by the virtual GPU
time consumed by entities in a way that the entity with least vruntime
runs first.
It is able to avoid total priority starvation, which is one of the
problems with FIFO, and it also does not need for per priority run queues.
As it scales the actual GPU runtime by an exponential factor as the
priority decreases, the virtual runtime for low priority entities grows
faster than for normal priority, pushing them further down the runqueue
order for the same real GPU time spent.
Apart from this fundamental fairness, fair policy is especially strong in
oversubscription workloads where it is able to give more GPU time to short
and bursty workloads when they are running in parallel with GPU heavy
clients submitting deep job queues.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-11-tvrtko.ursulin@igalia.com
There is no need to keep entities with no jobs in the tree so lets remove
it once the last job is consumed. This keeps the tree smaller which is
nicer and more efficient as entities are removed and re-added on every
popped job.
Apart from that, the upcoming fair scheduling algorithm will rely on the
tree only containing runnable entities.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-10-tvrtko.ursulin@igalia.com
To implement fair scheduling we need a view into the GPU time consumed by
entities. Problem we have is that jobs and entities objects have decoupled
lifetimes, where at the point we have a view into accurate GPU time, we
cannot link back to the entity any longer.
Solve this by adding a light weight entity stats object which is reference
counted by both entity and the job and hence can safely be used from
either side.
With that, the only other thing we need is to add a helper for adding the
job's GPU time into the respective entity stats object, and call it once
the accurate GPU time has been calculated.
The most convenient place to do that is the free job worker for several
reasons. Doing the accounting from the job completion callback would mean
a few locks would need to become irq safe and we would also need to worry
about out of order completions (via dma_fence_is_signaled calls which we
cannot control). In-order completions are critical for GPU time accuracy
which is currently adjusted per fence in the free worker and requires
looking at the next job in the scheduler pending list. We would also need
to add a new lock to protect the scheduler average stats update.
In contrast to those complications, having the accounting done from the
free worker is serialized by definition and all the above complications
are avoided. Downside is there is potential for a time lag between job
completions and GPU time being accounted against the entity. Since that is
partly alleviated by batch processing the completed job queue, and the
scheduling algorithm does not attempt to be completely fair, which would
even be rather impossible to achieve in the GPU world with the current
DRM scheduler design and hardware with no or poor preemption support,
this downside is not considered critical. Plus, in practice the scheduler
is also affected by worker scheduling delays from other angles too. Not
least being able to promptly feed the GPU with new work.
We therefore choose the simple option and can later consider improving
upon it if the need arises.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-9-tvrtko.ursulin@igalia.com
To implement fair scheduling we will need as accurate as possible view
into per entity GPU time utilisation. Because sched fence execution time
are only adjusted for accuracy in the free worker we need to process
completed jobs as soon as possible so the metric is most up to date when
view from the submission side of things.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-8-tvrtko.ursulin@igalia.com
Round-robin being the non-default policy and unclear how much it is used,
we can notice that it can be implemented using the FIFO data structures if
we only invent a fake submit timestamp which is monotonically increasing
inside drm_sched_rq instances.
So instead of remembering which was the last entity the scheduler worker
picked we can simply bump the picked one to the bottom of the tree, which
ensures round-robin behaviour between all active queued jobs.
If the picked job was the last from a given entity, we remember the
assigned fake timestamp and use it to re-insert the job once it re-joins
the queue. This ensures the job neither overtakes all already queued jobs,
neither it goes last. Instead it keeps the position after the currently
queued jobs and before the ones which haven't yet been queued at the point
the entity left the queue.
Advantage is that we can consolidate to a single code path and remove a
bunch of code. Downside is round-robin mode now needs to lock on the job
pop path but that should not have a measurable performance impact.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-7-tvrtko.ursulin@igalia.com
Every 100ms for the duration of the test it logs how many jobs each
client had completed, prefixed by minimum, average and maximum numbers.
When finished overall average delta between max and min is output as a
rough indicator to scheduling fairness.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-6-tvrtko.ursulin@igalia.com
To make evaluating different scheduling policies easier (no need for
external benchmarks) and perfectly repeatable, lets add some synthetic
workloads built upon mock scheduler unit test infrastructure.
Focus is on two parallel clients (two threads) submitting different job
patterns and logging their progress and some overall metrics. This is
repeated for both scheduler credit limit 1 and 2.
There we have two clients represented in the two respective columns, with
their progress logged roughly every 100 milliseconds. The metrics are:
- pct - Percentage progress of the job submit part
- cps - Cycles per second
- qd - Queue depth - number of submitted unfinished jobs
The cycles per second metric is inherent to the fact that workload
patterns are a data driven cycling sequence of:
- Submit 1..N jobs
- Wait for Nth job to finish (optional)
- Sleep (optional)
- Repeat from start
In this particular example we have a normal priority and a low priority
client both spamming the scheduler with 8ms jobs with no sync and no
sleeping. Hence they build very deep queues and we can see how the low
priority client is completely starved until the normal finishes.
Note that the PCT and CPS metrics are irrelevant for "unsync" clients
since they manage to complete all of their cycles instantaneously.
In this case client one is submitting 3x 2.5ms jobs, waiting for the 3rd
and then sleeping for 2.5ms (in effect causing 75% GPU load, minus the
overheads). Second client is submitting 1ms jobs, waiting for each to
finish and sleeping for 9ms (effective 10% GPU load). Here we can see
the PCT and CPS reflecting real progress.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-5-tvrtko.ursulin@igalia.com
drm/sched: Move run queue related code into a separate file
Lets move all the code dealing with struct drm_sched_rq into a separate
compilation unit. Advantage being sched_main.c is left with a clearer set
of responsibilities.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> # v1 Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-4-tvrtko.ursulin@igalia.com
drm/sched: Disallow initializing entities with no schedulers
Since we have removed the case where amdgpu was initializing entitites
with either no schedulers on the list, or with a single NULL scheduler,
and there appears no other drivers which rely on this, we can simplify the
scheduler by explicitly rejecting that early.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Philipp Stanner <phasta@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-2-tvrtko.ursulin@igalia.com
Philipp Stanner [Wed, 15 Apr 2026 14:49:56 +0000 (16:49 +0200)]
drm/sched: Make drm_sched_entity_kill() a public function
Some drivers do not care on teardown whether the last jobs pending in an
entity are actually executed before teardown completed. For such
scenarios, drm_sched_entity_flush() is not the ideal function since it's
intended to wait for jobs to complete.
Make drm_sched_entity_kill() public for that use-case and update the
documentation.
Jonathan Cavitt [Mon, 2 Feb 2026 21:47:10 +0000 (21:47 +0000)]
drm/colorop: Check if getting curve_1d_type default succeeds
Static analysis issue:
In all other uses of the function drm_object_property_get_default_value,
the return value of the function is checked before the output is saved to
the relevant object parameter. Though likely unnecessary given the
execution path involved, keep the behavior consistent across uses and only
set colorop_state->curve_1d_type in __drm_colorop_state_reset if
drm_object_property_get_default_value succeeds.
Jonathan Cavitt [Fri, 30 Jan 2026 19:19:54 +0000 (19:19 +0000)]
drm/gpuvm: Do not prepare NULL objects
Statis analysis issue:
drm_gpuvm_prepare_range issues an exec_object_prepare call to all
drm_gem_objects mapped between addr and addr + range. However, it is
possible (albeit very unlikely) that the objects found through
drm_gpuvm_for_each_va_range (as connected to va->gem) are NULL, as seen
in other functions such as drm_gpuva_link and drm_gpuva_unlink_defer.
Do not prepare NULL objects.
Fixes: 50c1a36f594b ("drm/gpuvm: track/lock/validate external/evicted objects") Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patch.msgid.link/20260130191953.61718-2-jonathan.cavitt@intel.com
Felix Gu [Thu, 16 Apr 2026 13:37:23 +0000 (21:37 +0800)]
accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()
In amdxdna_iommu_alloc(), if iommu_map() fails after successfully
allocating both iova and cpu_addr, the code jumps to free_iova
which only frees the iova, leaking the allocated pages.
Max Zhen [Wed, 15 Apr 2026 17:11:39 +0000 (10:11 -0700)]
accel/amdxdna: Add hardware scheduler time quantum support
Add support for configuring the hardware scheduler time quantum to
improve fairness across concurrent contexts.
The scheduler enforces a fixed time slice per context, preventing
long-running workloads from monopolizing the device and allowing
other contexts to make forward progress.
The default time quantum is 30ms and can be configured via the
time_quantum_ms module parameter.
Jason Gunthorpe [Sun, 1 Mar 2026 18:57:54 +0000 (14:57 -0400)]
dma-buf: Change st-dma-fence.c to use kunit
Modernize the open coded test framework by using kunit.
Add a num_online_cpus() check to test_race_signal_callback() as the
default kunit.py runs the VM with a single CPU and this test depends on
two truly parallel kthreads. Skip it instead of hanging.
Jason Gunthorpe [Sun, 1 Mar 2026 18:57:53 +0000 (14:57 -0400)]
dma-buf: Change st-dma-resv.c to use kunit
Modernize the open coded test framework by using kunit.
The kunit tool can be used to build a kernel and run it in a VM with:
$ tools/testing/kunit/kunit.py run --build_dir build_kunit_x86_64 --arch x86_64 --kunitconfig ./drivers/dma-buf/.kunitconfig
Along with the other ways to run kunits.
To make the kunit tool work like this the DMABUF_KUNIT_TEST kconfig must
select DMA_SHARED_BUFFER to get it turned on without building a driver
using it.
drm: rcar-du: encoder: convert to of_drm_find_and_get_bridge()
of_drm_find_bridge() is deprecated. Move to its replacement
of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it
is put when done.
We need to handle the two cases: when a panel_bridge is added and when it
isn't. So:
* in the 'else' case a panel_bridge is not added and bridge is found: use
of_drm_find_and_get_bridge() to get a reference to the found bridge
* in the 'then' case a panel_bridge is found using a devm function which
already takes a refcount and will put it on removal, but we need to take
another so the following code in this function always get exactly one
reference that it needs to put
In order to put the reference, add the needed drm_bridge_put() calls in the
existing cleanup function.
drm: renesas: rz-du: rzg2l_du_encoder: convert to of_drm_find_and_get_bridge()
of_drm_find_bridge() is deprecated. Move to its replacement
of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it
is put when done.
This is made somewhat simpler by the fact that 'bridge' is a local
variable.
However we need to handle both branches of the main if().
In the 'else' case, just switch to of_drm_find_and_get_bridge() to ensure
the bridge is not freed while in use in the function tail
(drm_bridge_attach() mainly).
In the 'then' case, devm_drm_panel_bridge_add_typed() already increments
the refcount using devres which ties the bridge allocation lifetime to the
device lifetime, so we would not need to do anything. However to have the
same behaviour in both branches take an additional reference here, so that
the bridge needs to be put whichever branch is taken without more
complicated logic.
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260409-drm-bridge-alloc-getput-drm_of_find_bridge-4-v5-1-d7381c07788a@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Luca Ceresoli [Tue, 24 Mar 2026 08:58:14 +0000 (09:58 +0100)]
drm/bridge: prevent encoder chain changes in pre_enable/post_disable
Take the encoder chain mutex while iterating over the encoder chain in
drm_atomic_bridge_chain_pre_enable() and
drm_atomic_bridge_chain_post_disable() to ensure the lists won't change
while being inspected.
These functions have nested list_for_each_*() loops, which makes them
complicated. list_for_each_entry_from() loops could be replaced by
drm_for_each_bridge_in_chain_from(), but it would not work in a nested way
in its current implementation. Besides, there is no "_reverse" variant of
drm_for_each_bridge_in_chain_from().
Keep code simple and readable by explicitly locking around the outer
loop. Thankfully there are no break or return points inside the loops, so
the change is trivial and readable.
Luca Ceresoli [Tue, 24 Mar 2026 08:58:13 +0000 (09:58 +0100)]
drm/bridge: prevent encoder chain changes while iterating with list_for_each_entry_reverse()
These loops in drm_bridge.c iterate over the encoder chain using
list_for_each_entry_reverse(), which does not prevent changes to the bridge
chain while iterating over it.
Take the encoder chain mutex while iterating to avoid chain changes while
iterating.
All the "simple" loops are converted. drm_atomic_bridge_chain_pre_enable()
and drm_atomic_bridge_chain_post_disable() are handled by a separate
commit.
Luca Ceresoli [Tue, 24 Mar 2026 08:58:12 +0000 (09:58 +0100)]
drm/bridge: prevent encoder chain changes while iterating with list_for_each_entry_from()
These loops in drm_bridge.c iterate over the encoder chain using
list_for_each_entry_from(), which does not prevent changes to the bridge
chain while iterating over it.
Convert most of those loops to instead use
drm_for_each_bridge_in_chain_from(), which locks the chain.
This also simplifies code.
All the "simple" loops are converted here. The only ones not touched are
those in drm_atomic_bridge_chain_pre_enable() and
drm_atomic_bridge_chain_post_disable(), because they have nested loops
which are not well handled by drm_for_each_bridge_in_chain_from(). Those
two functions are handled by a separate commit.
Luca Ceresoli [Tue, 24 Mar 2026 08:58:11 +0000 (09:58 +0100)]
drm/bridge: lock the encoder chain in scoped for_each loops
drm_for_each_bridge_in_chain_scoped() and
drm_for_each_bridge_in_chain_from() currently get/put the bridge at each
iteration. But they don't protect the encoder chain, so it could change
(bridges added/removed) while some code is iterating over the list
itself. Such code can then derail on incorrect pointers.
To make iterations safe, augment these for_each macros to lock the encoder
chain mutex at the beginning and unlock it at the end of the loop (be it at
the end of the list, or earlier due to a 'break' or 'return' statement).
This change requires more operations when starting and ending the loop. To
avoid making the macros even more complex, move these operations to helper
functions. Also remname some of the existing helper functions for
consistency.
Luca Ceresoli [Tue, 24 Mar 2026 08:58:10 +0000 (09:58 +0100)]
drm/bridge: drm_bridge_attach: lock the encoder chain mutex during insertion
drm_bridge_attach() modifies the encoder bridge chain, so take a mutex
around such operations to allow users of the chain to protect themselves
from chain modifications while iterating.
Luca Ceresoli [Tue, 24 Mar 2026 08:58:09 +0000 (09:58 +0100)]
drm/encoder: drm_encoder_cleanup: lock the encoder chain mutex during removal
drm_encoder_cleanup() modifies the encoder chain by removing bridges via
drm_bridge_detach(). Protect this whole operation by taking the mutex, so
that:
* any users iterating over the chain will not access it during the change
* other code willing to modify the list (drm_bridge_attach()) will wait
until drm_encoder_cleanup() is done
Note that the _safe macro in use here is providing a different and
orthogonal kind of protection than the mutex:
1. list_for_each_entry_safe() allows removing the current entry from the
list it is iterating on, synchronously; the non-safe version would be
unable to find the next entry after the current entry has been removed
2. the mutex being added allows to ensure that the list is not used
asynchronously by other code while it is being modified; this prevents
such other concurrent code to derail because it is iterating over an
element while it is removed
The _safe macro, which works by taking the "next" pointer in addition to
the "current" one, does not even try to provide the protection at item 2
above. This is visible e.g. when the "next" element is removed by other
concurrent code. This is what would happen without the added mutex:
1. start loop: list_for_each_entry_safe(pos, n, ...) sets:
pos = list_first_entry() = (bridge 1)
n = list_next_entry(pos) = (bridge 2)
2. enter the loop 1st time, do something with *pos (bridge 1)
3. in the meanwhile bridge 2 is hot-unplugged
-> another thread removes bridge 2
-> drm_bridge_detach()
-> list_del() sets (bridge 2)->next = LIST_POISON1
4. loop iteration 1 finishes, list_for_each_entry_safe() sets:
pos = n (previously set to bridge 2)
n = (bridge 2)->next = LIST_POISON1
5. enter the loop 2nd time, do something with *pos (bridge 2)
6. loop iteration 2 finishes, list_for_each_entry_safe() sets:
pos = n = LIST_POISON1 ==> bug!
However, simply adding mutex_[un]lock(&encoder->bridge_chain_mutex)
before/after the list_for_each_entry_safe() seems a simple and good
solution, but it is introducing a possible ABBA deadlock (found by
PROVE_LOCKING). The two code paths involved are:
* drm_encoder_cleanup():
- takes the bridge_chain_mutex (A)
- calls drm_bridge_detach -> drm_atomic_private_obj_fini ->
DRM_MODESET_LOCK_ALL_BEGIN() which takes all locks in the
acquisition context (B)
* drm_mode_getconnector() (and other code paths):
- calls drm_helper_probe_single_connector_modes() which:
- takes a drm_modeset_lock in the acquisition context (B)
- calls __drm_helper_update_and_validate ->
drm_bridge_chain_mode_valid -> drm_for_each_bridge_in_chain_from()
which takes the bridge_chain_mutex (A)
To avoid this potential ABBA deadlock, move all list items to a temporary
list while holding the bridge_chain_mutex, then detach all elements from
the temporary list without the mutex.
Luca Ceresoli [Tue, 24 Mar 2026 08:58:08 +0000 (09:58 +0100)]
drm/encoder: add mutex to protect the bridge chain
The per-encoder bridge chain is currently assumed to be static once it is
fully initialized. Work is in progress to add hot-pluggable bridges,
breaking that assumption.
With bridge removal, the encoder chain can change without notice, removing
tail bridges. This can be problematic while iterating over the chain.
Add a mutex to be taken whenever looping or changing the encoder chain.
Biju Das [Mon, 30 Mar 2026 10:44:46 +0000 (11:44 +0100)]
drm: renesas: rzg2l_mipi_dsi: Fix deassert/assert of CMN_RSTB signal
The RZ/G2L hardware manual (Rev. 1.50, May 2025), Section 34.4.2.1,
requires deasserting the CMN_RSTB signal after setting the Link registers.
Move the reset_control_deassert() call from rzg2l_mipi_dsi_dphy_init() to
rzg2l_mipi_dsi_startup(), placing it after the Link register writes. This
reset signal is optional for RZ/V2H SoCs, so add a NULL check. Drop the
unused ret variable from rzg2l_mipi_dsi_dphy_init().
The CMN_RSTB signal is not required for reading PHY registers in the
probe. Move reset_control_assert() from rzg2l_mipi_dsi_dphy_exit() to
rzg2l_mipi_dsi_stop(), placing it before the dphy_exit() call. Since this
reset signal is optional for RZ/V2H, the call is a no-op on that SoC.
The RZ/G2L hardware manual (Rev. 1.50, May 2025), Section 34.4.2.1,
requires waiting at least 1 msec after deasserting the CMN_RSTB signal
before the DSI-Tx module is ready. Increase the delay from 1 usec to
1 msec by replacing udelay(1) with fsleep(1000) for RZ/G2L SoCs.
The RZ/G2L hardware manual (Rev. 1.50, May 2025), Section 34.4.2.1,
requires display timings to be set after the HS clock is started. Move
rzg2l_mipi_dsi_set_display_timing() from
rzg2l_mipi_dsi_atomic_pre_enable() to rzg2l_mipi_dsi_atomic_enable(),
placing it after rzg2l_mipi_dsi_start_hs_clock(). Drop the unused ret
variable from rzg2l_mipi_dsi_atomic_pre_enable().
Max Zhen [Tue, 14 Apr 2026 16:56:24 +0000 (09:56 -0700)]
accel/amdxdna: Fix fatal_error_info layout in firmware interface
Adjust struct fatal_error_info to match the expected driver/firmware
interface layout.
The structure is used to retrieve debug information from firmware when
a command becomes stuck on the device. The reserved field currently
uses 128 u32 entries, which makes the structure larger than intended
and causes the layout to no longer match the firmware definition.
Reduce the reserved array size from 128 to 127 entries so the
structure matches the expected interface format.
Fixes: 25854131c04a ("accel/amdxdna: Support retrieving hardware context debug information") Signed-off-by: Max Zhen <max.zhen@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260414165625.788853-1-lizhi.hou@amd.com
Trace_dma_fence_signaled, trace_dma_fence_wait_end and
trace_dma_fence_destroy can all currently dereference a null fence->ops
pointer after it has been reset on fence signalling.
Lets use the safe string getters for most tracepoints to avoid this class
of a problem, while for the signal tracepoint we move it to before ops are
cleared to avoid losing the driver and timeline name information. Apart
from moving it we also need to add a new tracepoint class to bypass the
safe name getters since the signaled bit is already set.
For dma_fence_init we also need to use the new tracepoint class since the
rcu read lock is not held there, and we can do the same for the enable
signaling since there we are certain the fence cannot be signaled while
we are holding the lock and have even validated the fence->ops.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Cc: Christian König <christian.koenig@amd.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260415083207.40513-2-tvrtko.ursulin@igalia.com
accel/amdxdna: Fix order of canceled mailbox messages
Mailbox message IDs are allocated cyclically. When destroying a mailbox
channel, pending messages are canceled starting from message ID 0. This
results in an incorrect cancellation order when the ID of the last posted
message wraps around and is smaller than the ID of the first posted
message.
Fix this by canceling pending messages starting from the next available
message ID, ensuring the correct ordering across wraparound.
drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
Convert this driver to DRM_BRIDGE_ATTACH_NO_CONNECTOR and to the
drm_bridge_connector framework which is the current DRM bridge best
practice.
Based on the in-tree dts[i] files this introduces no regression. Based on
the kernel doc of drm_bridge_connector.c:
* To make use of this helper, all bridges in the chain shall report bridge
* operation flags (&drm_bridge->ops) and bridge output type
* (&drm_bridge->type), as well as the DRM_BRIDGE_ATTACH_NO_CONNECTOR attach
* flag (none of the bridges shall create a DRM connector directly).
and each of the 3 LCDIF blocks in the i.MX8MP, all of them comply with the
above requirement:
* fsl,imx8mp-hdmi-pvi has ops = 0 (it doesn't set it) because it
implements none the optional features mentioned by those flags, and it
honors the DRM_BRIDGE_ATTACH_NO_CONNECTOR by propagating it
* fsl,imx8mp-hdmi-tx is implemented based on dw-hdmi, which sets ops as
appropriate and also propagates the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
* display-connector (enabled via the DT overlay if needed) sets ops and
makes DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory
* The LCDIF2 involves the panel-bridge, display-connector and lvds-decoder
(even though only the pane-bridge is currently supported), and all these
three also set ops as needed and propagate
DRM_BRIDGE_ATTACH_NO_CONNECTOR or make it mandatory.
* The LCDIF1 is used with the adv7511, tc358767 and the panel bridge
drivers which also comply with the requirements.
Tested-by: Martyn Welch <martyn.welch@collabora.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260407-drm-lcdif-dbanc-v4-11-247a16e61ef9@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
drm/bridge: imx8mp-hdmi-tx: switch to DRM_BRIDGE_ATTACH_NO_CONNECTOR
The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
can operate in two different modes, depending on the platform data as set
by the driver:
A. hdmi->plat_data->output_port = 0:
the HDMI output (port@1) in device tree is not used [0]
B. hdmi->plat_data->output_port = 1:
the HDMI output (port@1) is parsed to find the next bridge
The imx8mp-hdmi-tx driver falls in case A. Switching to case B, which is
the current best practice, requires that the HDMI connector is always
described in the live device tree, and a previous commit ensured this is
always the case by adding an overlay in case the device tree does not
comply.
So now we can simply switch to the new mode and support
DRM_BRIDGE_ATTACH_NO_CONNECTOR.
drm/bridge: imx8mp-hdmi-tx-connector-fixup: show a warning when adding the overlay
Describing the HDMI connector in device tree is recommended. While the
overlay insertion is a workaround to avoid breaking existing devices, every
dts should be improved by adding a connector description.
Add a warning to make users aware as far as possible.
As a warning line cannot hold all the relevant info, add a detailed comment
in the code so it easy to find when the warning is seen.
drm/bridge: imx8mp-hdmi-tx-connector-fixup: add an hdmi-connector when missing using a DT overlay at boot time
The imx8mp-hdmi-tx is one of many drivers based on dw-hdmi. dw-hdmi in turn
can operate in two different modes, depending on the platform data as set
by the driver:
A. hdmi->plat_data->output_port = 0:
the HDMI output (port@1) in device tree is not used [0]
B. hdmi->plat_data->output_port = 1:
the HDMI output (port@1) is parsed to find the next bridge
The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
in that case it adds an HDMI Type A connector programmatically at bridge
attach time.
Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
case B. However switching to base B requires that port@1 is connected to a
"next bridge" DT node, typically the HDMI connector, because dw-hdmi won't
add the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Many dts files for imx8mp-based boards in the kernel have such a connector
described and linked to port@1, so the pipeline will be fully attached up
to a display-connector and a drm_connector added by the
bridge-connector. Sadly some of those dts files don't have the connector
described. Adding it would solve the problem easily, but this would break
existing devices which do not update the dtb when upgrading to a newer
kernel.
In preparation for switching to case B while preserving backward
compatibility for such devices, introduce a module adding the
hdmi-connector node to the live device tree at init time. This will allow
the dw-hdmi code to find the next bridge (the one wrapping the
hdmi-connector) and let the pipeline work as before.
The module is inserted only if there is no endpoint in port@1. So boards
whose device tree describe the connector will not have the device tre
modified, and will start isntantiating the correct HDMI connector type as
described in the device tree.
For boards lacking a connector description in DT the overlay will be added,
abd the HDMI connector will be Type A, which is a reasonable fallback and
is what the driver is currently doing.
drm/bridge: dw-hdmi: move next_bridge lookup to attach time
This driver looks up the next_bridge at probe time and stores it in
hdmi->bridge.next_bridge, but only uses the stored value when attaching,
and only in the DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
This will be problematic with an upcoming change, adding an hdmi-connector
using a device tree overlay when not present. That change is in turn
necessary to migrate the i.MX LCDIF driver to the bridge-connector.
The problem is that, adding the hdmi-connector via an overlay, devlink
considers hdmi-connector a consumer of the dw-hdmi device, generating a
chicken-egg problem:
* hdmi-connector probe won't be tried until dw-hdmi is probed (devlink)
* dw-hdmi probe will defer until it finds the next_bridge (the
hdmi-connector wrapper bridge)
In preparation for those changes, move the next_bridge lookup from probe to
attach, when it is actually used. This allows dw-hdmi to probe, so that the
hdmi-connector can probe as well.
Also avoid storing the pointer in hdmi->bridge.next_bridge: the value is
computed when needed, thus a local variable is enough.
Finally, this also allows to slightly improve the code by not doing any DT
lookup in the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
drm/bridge: dw-hdmi: warn on unsupported attach combination
dw-hdmi can operate in two different modes, depending on the platform data
as set by the driver:
A. hdmi->plat_data->output_port = 0:
the HDMI output (port@1) in device tree is not used
B. hdmi->plat_data->output_port = 1:
the HDMI output (port@1) is parsed to find the next bridge
Only case B is supported when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is
passed to the attach callback. Emit a warning when this is violated. Also
return -EINVAL which would be returned by drm_bridge_attach() right after
anyway.
projects / thirdparty / linux.git / log
