| Age | Commit message (Collapse) | Author |
|---|
|
Let's provide an helper to make it easier for bridge drivers to
power-cycle their bridge.
In order to avoid a circular dependency between that new helper and
drm_atomic_helper_reset_crtc(), this new helper will be in a
drm_bridge_helper.c file to follow the pattern we have for other
objects.
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Tested-by: Herve Codina <herve.codina@bootlin.com>
Co-developed-by: Simona Vetter <simona.vetter@intel.com>
Signed-off-by: Simona Vetter <simona.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-8-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
As suggested in [0], add a note indicating that
drm_atomic_helper_reset_crtc() can be a no-op in some cases.
[0]:https://lore.kernel.org/all/Z7XfnPGDYspwG42y@phenom.ffwll.local/
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20250220140406.593314-1-herve.codina@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
drm_atomic_helper_wait_for_flip_done()
drm_atomic_helper_wait_for_flip_done() will wait for pages flips on all
CRTCs affected by a given commit. It takes the drm_atomic_state being
committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-26-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_commit_cleanup_done()
drm_atomic_helper_wait_for_dependencies() is the final part of a commit
and signals it completion. It takes the drm_atomic_state being committed
as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-25-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_cleanup_planes() is one of the final part of a commit,
and will free up all plane resources used in the previous commit. It
takes the drm_atomic_state being committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-24-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_wait_for_vblanks() waits for vblank events on all the
CRTCs affected by a commit. It takes the drm_atomic_state being
committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-23-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_commit_hw_done() signals hardware completion of a
given commit. It takes the drm_atomic_state being committed as a
parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-22-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_fake_vblank() fake a vblank event if needed when a new
commit is being applied. It takes the drm_atomic_state being committed
as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-21-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_commit_writebacks()
drm_atomic_helper_commit_writebacks() updates all writeback connectors
affected by a new commit. It takes the drm_atomic_state being committed
as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-20-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_commit_modeset_enables()
drm_atomic_helper_commit_modeset_enables() enables all outputs affected
by a new commit. It takes the drm_atomic_state being committed as a
parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-17-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_commit_planes() updates all planes affected by a new
commit. It takes the drm_atomic_state being committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-16-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
crtc_set_mode() deals with calling the modeset related hooks for CRTC,
connectors and bridges if and when a new commit changes them. It takes
the drm_atomic_state being committed as a parameter.
However, that parameter name is called as old_state, which is pretty
confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-15-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_update_legacy_modeset_state()
drm_atomic_helper_update_legacy_modeset_state() updates all the legacy
modeset pointers a connector, encoder or CRTC might have with the ones
being setup by a given commit. It takes the drm_atomic_state being
committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-14-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
disable_outputs() disables all connectors and CRTCs affected by a
commit. It takes the drm_atomic_state being committed as a parameter.
However, that parameter name is called as old_state, which is pretty
confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-11-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_modeset_disables() disables all the outputs affected
by a commit. It takes the drm_atomic_state being committed as a
parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-10-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_commit_tail_rpm() is the final part of an atomic
commit, and is given the state being committed as a parameter.
However, that parameter is named old_state, but documented as the "new
modeset state" which is all super confusing.
Let's rename that parameter to state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-9-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_commit_tail() is the final part of an atomic commit,
and is given a parameter with the drm_atomic_state being committed.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-8-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
drm_atomic_helper_wait_for_dependencies()
drm_atomic_helper_wait_for_dependencies() waits for all the dependencies
a commit has before going forward with it. It takes the drm_atomic_state
being committed as a parameter.
However, that parameter name is called (and documented) as old_state,
which is pretty confusing. Let's rename that variable as state.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-7-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Even though the commit_tail () drm_atomic_state parameter is called
old_state, it's actually the state being committed which is confusing.
It's even more confusing since the atomic_commit_tail hook being called
by commit_tail() parameter is called state.
Let's rename the variable from old_state to state to make it less
confusing.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-6-e71598f49c8f@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Currently, DRM atomic uAPI allows only primary planes to be flipped
asynchronously. However, each driver might be able to perform async
flips in other different plane types. To enable drivers to set their own
restrictions on which type of plane they can or cannot flip, use the
existing atomic_async_check() from struct drm_plane_helper_funcs to
enhance this flexibility, thus allowing different plane types to be able
to do async flips as well.
Create a new parameter for the atomic_async_check(), `bool flip`. This
parameter is used to distinguish when this function is being called from
a plane update from a full page flip.
In order to prevent regressions and such, we keep the current policy: we
skip the driver check for the primary plane, because it is always
allowed to do async flips on it.
Signed-off-by: André Almeida <andrealmeid@igalia.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Christopher Snowhill <chris@kode54.net>
Tested-by: Christopher Snowhill <chris@kode54.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20250127-tonyk-async_flip-v12-1-0f7f8a8610d3@igalia.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
|
|
drm_atomic_helper_reset_crtc() allows to reset the CRTC active outputs.
This resets all active components available between the CRTC and
connectors.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250210132620.42263-3-herve.codina@bootlin.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
This message reports a mismatch between new_crtc_state->enable and
has_connectors, which should be either both true or both false. However it
does not mention which one is true and which is false, which can be useful
for debugging. Add the value of both avriables to the log message.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Louis Chauvet <louis.chauvet@bootlin.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250204-drm-small-improvements-v4-2-d6bbc92f12f1@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
The drm_atomic_helper_check() calls drm_atomic_helper_check_modeset()
insternally. Document that corresponding restrictions also apply to the
drivers that call the former function (as it's easy to miss the
documentation for the latter function).
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241222-drm-dirty-modeset-v1-1-0e76a53eceb9@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
|
|
Check that all encoders attached to a given CRTC are valid
possible_clones of each other.
Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241216-concurrent-wb-v4-3-fe220297a7f0@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
|
|
In certain use-cases, a CRTC could switch between two encoders
and because the mode being programmed on the CRTC remains
the same during this switch, the CRTC's mode_changed remains false.
In such cases, the encoder's mode_set also gets skipped.
Skipping mode_set on the encoder for such cases could cause an issue
because even though the same CRTC mode was being used, the encoder
type could have changed like the CRTC could have switched from a
real time encoder to a writeback encoder OR vice-versa.
Allow encoder's mode_set to happen even when connectors changed on a
CRTC and not just when the mode changed.
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241211-abhinavk-modeset-fix-v3-1-0de4bf3e7c32@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
|
|
It turns out that if you happen to have a kernel config where
CONFIG_DRM_PANIC is disabled and spinlock debugging is enabled, along with
KMS being enabled - we'll end up trying to acquire an uninitialized
spin_lock with drm_panic_lock() when we try to do a commit:
rvkms rvkms.0: [drm:drm_atomic_commit] committing 0000000068d2ade1
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 4 PID: 1347 Comm: modprobe Not tainted 6.10.0-rc1Lyude-Test+ #272
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20240524-3.fc40 05/24/2024
Call Trace:
<TASK>
dump_stack_lvl+0x77/0xa0
assign_lock_key+0x114/0x120
register_lock_class+0xa8/0x2c0
__lock_acquire+0x7d/0x2bd0
? __vmap_pages_range_noflush+0x3a8/0x550
? drm_atomic_helper_swap_state+0x2ad/0x3a0
lock_acquire+0xec/0x290
? drm_atomic_helper_swap_state+0x2ad/0x3a0
? lock_release+0xee/0x310
_raw_spin_lock_irqsave+0x4e/0x70
? drm_atomic_helper_swap_state+0x2ad/0x3a0
drm_atomic_helper_swap_state+0x2ad/0x3a0
drm_atomic_helper_commit+0xb1/0x270
drm_atomic_commit+0xaf/0xe0
? __pfx___drm_printfn_info+0x10/0x10
drm_client_modeset_commit_atomic+0x1a1/0x250
drm_client_modeset_commit_locked+0x4b/0x180
drm_client_modeset_commit+0x27/0x50
__drm_fb_helper_restore_fbdev_mode_unlocked+0x76/0x90
drm_fb_helper_set_par+0x38/0x40
fbcon_init+0x3c4/0x690
visual_init+0xc0/0x120
do_bind_con_driver+0x409/0x4c0
do_take_over_console+0x233/0x280
do_fb_registered+0x11f/0x210
fbcon_fb_registered+0x2c/0x60
register_framebuffer+0x248/0x2a0
__drm_fb_helper_initial_config_and_unlock+0x58a/0x720
drm_fbdev_generic_client_hotplug+0x6e/0xb0
drm_client_register+0x76/0xc0
_RNvXs_CsHeezP08sTT_5rvkmsNtB4_5RvkmsNtNtCs1cdwasc6FUb_6kernel8platform6Driver5probe+0xed2/0x1060 [rvkms]
? _RNvMs_NtCs1cdwasc6FUb_6kernel8platformINtB4_7AdapterNtCsHeezP08sTT_5rvkms5RvkmsE14probe_callbackBQ_+0x2b/0x70 [rvkms]
? acpi_dev_pm_attach+0x25/0x110
? platform_probe+0x6a/0xa0
? really_probe+0x10b/0x400
? __driver_probe_device+0x7c/0x140
? driver_probe_device+0x22/0x1b0
? __device_attach_driver+0x13a/0x1c0
? __pfx___device_attach_driver+0x10/0x10
? bus_for_each_drv+0x114/0x170
? __device_attach+0xd6/0x1b0
? bus_probe_device+0x9e/0x120
? device_add+0x288/0x4b0
? platform_device_add+0x75/0x230
? platform_device_register_full+0x141/0x180
? rust_helper_platform_device_register_simple+0x85/0xb0
? _RNvMs2_NtCs1cdwasc6FUb_6kernel8platformNtB5_6Device13create_simple+0x1d/0x60
? _RNvXs0_CsHeezP08sTT_5rvkmsNtB5_5RvkmsNtCs1cdwasc6FUb_6kernel6Module4init+0x11e/0x160 [rvkms]
? 0xffffffffc083f000
? init_module+0x20/0x1000 [rvkms]
? kernfs_xattr_get+0x3e/0x80
? do_one_initcall+0x148/0x3f0
? __lock_acquire+0x5ef/0x2bd0
? __lock_acquire+0x5ef/0x2bd0
? __lock_acquire+0x5ef/0x2bd0
? put_cpu_partial+0x51/0x1d0
? lock_acquire+0xec/0x290
? put_cpu_partial+0x51/0x1d0
? lock_release+0xee/0x310
? put_cpu_partial+0x51/0x1d0
? fs_reclaim_acquire+0x69/0xf0
? lock_acquire+0xec/0x290
? fs_reclaim_acquire+0x69/0xf0
? kfree+0x22f/0x340
? lock_release+0xee/0x310
? kmalloc_trace_noprof+0x48/0x340
? do_init_module+0x22/0x240
? kmalloc_trace_noprof+0x155/0x340
? do_init_module+0x60/0x240
? __se_sys_finit_module+0x2e0/0x3f0
? do_syscall_64+0xa4/0x180
? syscall_exit_to_user_mode+0x108/0x140
? do_syscall_64+0xb0/0x180
? vma_end_read+0xd0/0xe0
? do_user_addr_fault+0x309/0x640
? clear_bhb_loop+0x45/0xa0
? clear_bhb_loop+0x45/0xa0
? clear_bhb_loop+0x45/0xa0
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Fix this by stubbing these macros out when this config option isn't
enabled, along with fixing the unused variable warning that introduces.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: e2a1cda3e0c7 ("drm/panic: Add drm panic locking")
Cc: <stable@vger.kernel.org> # v6.10+
Link: https://patchwork.freedesktop.org/patch/msgid/20240916230103.611490-1-lyude@redhat.com
|
|
The blank line between title "Returns:" and detail description is not
allowed, otherwise the title will goes under the description block in
generated .html file after running `make htmldocs`.
There are a few examples for current kerneldoc at [1][2][3].
v2:
- use Link tag with stable URLs
Signed-off-by: renjun wang <renjunw0@foxmail.com>
Link: https://www.kernel.org/doc/html/v6.10/gpu/drm-kms.html#c.drm_crtc_commit_wait # 1
Link: https://www.kernel.org/doc/html/v6.10/gpu/drm-kms.html#c.drm_atomic_get_crtc_state # 2
Link: https://www.kernel.org/doc/html/v6.10/gpu/i915.html#c.i915_vma_pin_fence # 3
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/tencent_37A873672B5CD20DECAF99DEDAC5E45C3106@qq.com
|
|
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
sections in code.
This also avoids the need that drivers must explicitly update the
panic handler state, which they might forget to do, or not do
consistently, and then we blow up in the worst possible times.
It is somewhat racy against a concurrent atomic update, and we might
write into a buffer which the hardware will never display. But there's
fundamentally no way to avoid that - if we do the panic state update
explicitly after writing to the hardware, we might instead write to an
old buffer that the user will barely ever see.
Note that an rcu protected deference of plane->state would give us the
the same guarantees, but it has the downside that we then need to
protect the plane state freeing functions with call_rcu too. Which
would very widely impact a lot of code and therefore doesn't seem
worth the complexity compared to a raw spinlock with very tiny
critical sections. Plus rcu cannot be used to protect access to
peek/poke registers anyway, so we'd still need it for those cases.
Peek/poke registers for vram access (or a gart pte reserved just for
panic code) are also the reason I've gone with a per-device and not
per-plane spinlock, since usually these things are global for the
entire display. Going with per-plane locks would mean drivers for such
hardware would need additional locks, which we don't want, since it
deviates from the per-console takeoverlocks design.
Longer term it might be useful if the panic notifiers grow a bit more
structure than just the absolute bare
EXPORT_SYMBOL(panic_notifier_list) - somewhat aside, why is that not
EXPORT_SYMBOL_GPL ... If panic notifiers would be more like console
drivers with proper register/unregister interfaces we could perhaps
reuse the very fancy console lock with all it's check and takeover
semantics that John Ogness is developing to fix the console_lock mess.
But for the initial cut of a drm panic printing support I don't think
we need that, because the critical sections are extremely small and
only happen once per display refresh. So generally just 60 tiny locked
sections per second, which is nothing compared to a serial console
running a 115kbaud doing really slow mmio writes for each byte. So for
now the raw spintrylock in drm panic notifier callback should be good
enough.
Another benefit of making panic notifiers more like full blown
consoles (that are used in panics only) would be that we get the two
stage design, where first all the safe outputs are used. And then the
dangerous takeover tricks are deployed (where for display drivers we
also might try to intercept any in-flight display buffer flips, which
if we race and misprogram fifos and watermarks can hang the memory
controller on some hw).
For context the actual implementation on the drm side is by Jocelyn
and this patch is meant to be combined with the overall approach in
v7 (v8 is a bit less flexible, which I think is the wrong direction):
https://lore.kernel.org/dri-devel/20240104160301.185915-1-jfalempe@redhat.com/
Note that the locking is very much not correct there, hence this
separate rfc.
Starting from v10, I (Jocelyn) have included this patch in the drm_panic
series, and done the corresponding changes.
v2:
- fix authorship, this was all my typing
- some typo oopsies
- link to the drm panic work by Jocelyn for context
v10:
- Use spinlock_irqsave/restore (John Ogness)
v11:
- Use macro instead of inline functions for drm_panic_lock/unlock (John Ogness)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
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: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409163432.352518-2-jfalempe@redhat.com
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for $kernel-version:
UAPI Changes:
Cross-subsystem Changes:
- A few fixes for usb/typec
Core Changes:
- ci: Updates to the defconfig, igt version, etc.
- writeback: Move the atomic_check helper from the encoder to connector
Driver Changes:
- rockchip: Add support for rk3588
- xe: Update the TODO list
- panel:
- nv3052c: Register documentation, init sequence improvements and
support for the Fascontek FS035VG158
- st7701: Add support for the Anbernic RG-ARC
- new driver: Synaptics R63353 panel controller, Ilitek ILI9805 panel
controller
- new panel: AUO G156HAN04.0
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/aqpn5miejmkks7pbcfex7b6u63uwsruywxsnr3x5ljs45qatin@nbkkej2elk46
|
|
Linux 6.7-rc5
Alex requested this for some amdkfd work relying on the symbols exports.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The drm_atomic_helper_check_wb_encoder_state() function doesn't use
encoder for anything other than getting the drm_device instance. The
function's description talks about checking the writeback connector
state, not the encoder state. Moreover, there is no such thing as an
encoder state, encoders generally do not have a state on their own.
Rename the function to drm_atomic_helper_check_wb_connector_state()
and change arguments to drm_writeback_connector and drm_atomic_state.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231208010314.3395904-2-dmitry.baryshkov@linaro.org
|
|
Invoke drm_plane_helper_funcs.end_fb_access before
drm_atomic_helper_commit_hw_done(). The latter function hands over
ownership of the plane state to the following commit, which might
free it. Releasing resources in end_fb_access then operates on undefined
state. This bug has been observed with non-blocking commits when they
are being queued up quickly.
Here is an example stack trace from the bug report. The plane state has
been free'd already, so the pages for drm_gem_fb_vunmap() are gone.
Unable to handle kernel paging request at virtual address 0000000100000049
[...]
drm_gem_fb_vunmap+0x18/0x74
drm_gem_end_shadow_fb_access+0x1c/0x2c
drm_atomic_helper_cleanup_planes+0x58/0xd8
drm_atomic_helper_commit_tail+0x90/0xa0
commit_tail+0x15c/0x188
commit_work+0x14/0x20
Fix this by running end_fb_access immediately after updating all planes
in drm_atomic_helper_commit_planes(). The existing clean-up helper
drm_atomic_helper_cleanup_planes() now only handles cleanup_fb.
For aborted commits, roll back from drm_atomic_helper_prepare_planes()
in the new helper drm_atomic_helper_unprepare_planes(). This case is
different from regular cleanup, as we have to release the new state;
regular cleanup releases the old state. The new helper also invokes
cleanup_fb for all planes.
The changes mostly involve DRM's atomic helpers. Only two drivers, i915
and nouveau, implement their own commit function. Update them to invoke
drm_atomic_helper_unprepare_planes(). Drivers with custom commit_tail
function do not require changes.
v4:
* fix documentation (kernel test robot)
v3:
* add drm_atomic_helper_unprepare_planes() for rolling back
* use correct state for end_fb_access
v2:
* fix test in drm_atomic_helper_cleanup_planes()
Reported-by: Alyssa Ross <hi@alyssa.is>
Closes: https://lore.kernel.org/dri-devel/87leazm0ya.fsf@alyssa.is/
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Fixes: 94d879eaf7fb ("drm/atomic-helper: Add {begin,end}_fb_access to plane helpers")
Tested-by: Alyssa Ross <hi@alyssa.is>
Reviewed-by: Alyssa Ross <hi@alyssa.is>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: <stable@vger.kernel.org> # v6.2+
Link: https://patchwork.freedesktop.org/patch/msgid/20231204083247.22006-1-tzimmermann@suse.de
|
|
This reverts commit f1e75da5364e780905d9cd6043f9c74cdcf84073.
Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.
Acked-by: Simon Ser <contact@emersion.fr>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231204131455.19023-2-dmitry.baryshkov@linaro.org
|
|
Loosen the requirements for atomic and legacy commit so that, in cases
where pixel_source != FB, the commit can still go through.
This includes adding framebuffer NULL checks in other areas to account for
FB being NULL when non-FB pixel sources are enabled.
To disable a plane, the pixel_source must be NONE or the FB must be NULL
if pixel_source == FB.
Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231027-solid-fill-v7-7-780188bfa7b2@quicinc.com
|
|
Let's kickstart the v6.8 release cycle.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
There is a typo in the kernel documentation for function
drm_atomic_helper_wait_for_dependencies. Fix it.
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231027024459.12793-1-chentao@kylinos.cn
|
|
This is needed to add the msm pr which is based on a higher base.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The driver might pull connectors which weren't submitted by
user-space into the atomic state. For instance,
intel_dp_mst_atomic_master_trans_check() pulls in connectors
sharing the same DP-MST stream. However, if the connector is
unregistered, this later fails with:
[ 559.425658] i915 0000:00:02.0: [drm:drm_atomic_helper_check_modeset] [CONNECTOR:378:DP-7] is not registered
Skip the unregistered connector check to allow user-space to turn
off connectors one-by-one.
See this wlroots issue:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407
Previous discussion:
https://lore.kernel.org/intel-gfx/Y6GX7z17WmDSKwta@ideak-desk.fi.intel.com/
Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231005131623.114379-1-contact@emersion.fr
|
|
As with other places in the Linux kernel--kfree(NULL) being the most
famous example--it's convenient to treat being passed a NULL argument
as a noop in cleanup functions. Let's make
drm_atomic_helper_shutdown() work like this.
This is convenient for DRM devices that use the "component" model. On
these devices we want shutdown to be a noop if the bind() call of the
component hasn't been called yet. As long as drivers are careful to
make sure the drvdata is NULL whenever the driver is not bound then we
can just do a simple call to drm_atomic_helper_shutdown() with the
drvdata at shutdown time.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.1.I906acd535bece03b6671d97c2826c6f0444f4728@changeid
|
|
drm_crtc_force_disable_all() was renamed to
drm_helper_force_disable_all(), but one reference was not updated.
Fixes: c2d88e06bcb9 ("drm: Move the legacy kms disable_all helper to crtc helpers")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b8c9c1a8a05dbf0be8e8be98cfdeafa9cecd8cef.1690535002.git.geert+renesas@glider.be
|
|
Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230517041602.3225325-1-suijingfeng@loongson.cn
|
|
The self-refresh helper framework overloads "disable" to sometimes mean
"go into self-refresh mode," and this mode activates automatically
(e.g., after some period of unchanging display output). In such cases,
the display pipe is still considered "on", and user-space is not aware
that we went into self-refresh mode. Thus, users may expect that
vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work
properly.
However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave
vblank enabled.
Add a different expectation: that CRTCs *should* leave vblank enabled
when going into self-refresh.
This patch is preparation for another patch -- "drm/rockchip: vop: Leave
vblank enabled in self-refresh" -- which resolves conflicts between the
above self-refresh behavior and the API tests in IGT's kms_vblank test
module.
== Some alternatives discussed: ==
It's likely that on many display controllers, vblank interrupts will
turn off when the CRTC is disabled, and so in some cases, self-refresh
may not support vblank. To support such cases, we might consider
additions to the generic helpers such that we fire vblank events based
on a timer.
However, there is currently only one driver using the common
self-refresh helpers (i.e., rockchip), and at least as of commit
bed030a49f3e ("drm/rockchip: Don't fully disable vop on self refresh"),
the CRTC hardware is powered enough to continue to generate vblank
interrupts.
So we chose the simpler option of leaving vblank interrupts enabled. We
can reevaluate this decision and perhaps augment the helpers if/when we
gain a second driver that has different requirements.
v3:
* include discussion summary
v2:
* add 'ret != 0' warning case for self-refresh
* describe failing test case and relation to drm/rockchip patch better
Cc: <stable@vger.kernel.org> # dependency for "drm/rockchip: vop: Leave
# vblank enabled in self-refresh"
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230109171809.v3.1.I3904f697863649eb1be540ecca147a66e42bfad7@changeid
|
|
If the crtc is being switched on or off then the semantics of
computing the timestampe of the next vblank is somewhat ill-defined.
And indeed, the code splats with a warning in the timestamp
computation code. Specifically it hits the check to make sure that
atomic drivers have full set up the timing constants in the drm_vblank
structure, and that's just not the case before the crtc is actually
on.
For robustness it seems best to just not set deadlines for modesets.
v2: Also skip on inactive crtc (Ville)
Link: https://lore.kernel.org/dri-devel/dfc21f18-7e1e-48f0-c05a-d659b9c90b91@linaro.org/
Fixes: d39e48ca80c0 ("drm/atomic-helper: Set fence deadline for vblank")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # test patch only
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230405133105.947834-1-daniel.vetter@ffwll.ch
|
|
into drm-next
This series adds a deadline hint to fences, so realtime deadlines
such as vblank can be communicated to the fence signaller for power/
frequency management decisions.
This is partially inspired by a trick i915 does, but implemented
via dma-fence for a couple of reasons:
1) To continue to be able to use the atomic helpers
2) To support cases where display and gpu are different drivers
See https://patchwork.freedesktop.org/series/93035/
This does not yet add any UAPI, although this will be needed in
a number of cases:
1) Workloads "ping-ponging" between CPU and GPU, where we don't
want the GPU freq governor to interpret time stalled waiting
for GPU as "idle" time
2) Cases where the compositor is waiting for fences to be signaled
before issuing the atomic ioctl, for example to maintain 60fps
cursor updates even when the GPU is not able to maintain that
framerate.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGt5nDQpa6J86V1oFKPA30YcJzPhAVpmF7N1K1g2N3c=Zg@mail.gmail.com
|
|
For an atomic commit updating a single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that deadline.
v2: Comment typo fix (danvet)
v3: If there are multiple CRTCs, consider the time of the soonest vblank
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Add atomic_enable to struct drm_plane_helper_funcs. It enables a
plane independently from updating the plane's content. As such, it is
the inverse of the atomic_disable plane helper. Useful for hardware
where plane enable state is independent from plane content.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209154107.30680-2-tzimmermann@suse.de
|
|
Add {begin,end}_fb_access helpers to run at the beginning and end of
an atomic commit. The begin_fb_access helper acquires resources that
are necessary to perform the atomic commit. It it similar to prepare_fb,
except that the resources are to be released at the end of the commit.
Resources acquired by prepare_fb are held until after the next pageflip.
The end_fb_access helper performs the corresponding resource cleanup.
Atomic helpers call it with the new plane state. This is different from
cleanup_fb, which releases resources of the old plane state.
v2:
* fix typos in commit message (Javier)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221025101737.8874-2-tzimmermann@suse.de
|
|
Rename the atomic helper function drm_atomic_helper_check_crtc_state()
to drm_atomic_helper_check_crtc_primary_plane() and only check for an
attached primary plane. Adapt callers.
Instead of having one big function to check for various CRTC state
conditions, we rather want smaller functions that drivers can pick
individually.
v5:
* rebase on top of udl changes
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221007124338.24152-3-tzimmermann@suse.de
|
|
In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the plane during the atomic-commit
step.
For the test in drm_atomic_helper_check_crtc_state() to succeed, it
is important that the CRTC has an enabled primary plane after the
commit. Simply testing the CRTC state's plane_mask for a primary plane
is sufficient.
Note that the helper still only tests for an attached primary plane.
Drivers have to ensure that the plane contains valid pixel information.
v5:
* fix commit description (Javier)
v3:
* test for a primary plane in plane_mask (Ville)
v2:
* remove unnecessary test for plane->crtc (Ville)
* inline drm_atomic_get_next_plane_state() (Ville)
* acquire plane lock before accessing plane->state (Ville)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Fixes: d6b9af1097fe ("drm/atomic-helper: Add helper drm_atomic_helper_check_crtc_state()")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20221007124338.24152-2-tzimmermann@suse.de
|
|
drivers/gpu/drm/drm_atomic_helper.c:802: warning: expecting prototype for drm_atomic_helper_check_wb_connector_state(). Prototype was for drm_atomic_helper_check_wb_encoder_state() instead.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2216
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220919103058.25561-1-jiapeng.chong@linux.alibaba.com
|
