| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[why]
When querying DML for a vlevel after pipes have been split or merged the
ODM policy would revert to a default policy, which could cause the query
to use the incorrect ODM status. In this case ODM 2to1 was validated,
but the last DML query would assume no ODM and return the incorrect
vlevel.
[how]
Added ODM check to apply the correct ODM policy before querying DML.
Tested-by: Daniel Wheeler <[email protected]>
Reviewed-by: Alvin Lee <[email protected]>
Acked-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Relja Vojvodic <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Fix issue when override level bigger than default. Levels 5, 6, and 7
had zero stutter latency, this is because override level being
initialized after stutter latency inits.
Tested-by: Daniel Wheeler <[email protected]>
Reviewed-by: Syed Hassan <[email protected]>
Reviewed-by: Allen Pan <[email protected]>
Acked-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Charlene Liu <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Optimize fast validation cases to only validate the highest voltage
level. This works because during fast validation we only care if the
mode can be supported or not (at any vlevel).
Tested-by: Daniel Wheeler <[email protected]>
Reviewed-by: Aric Cyr <[email protected]>
Acked-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Alvin Lee <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
- Move VCN4's fw_shared initialization to a separated function.
This way, the function can be reused at different locations.
Signed-off-by: Bokun Zhang <[email protected]>
Reviewed-by: Emily Deng <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Disable MCBP(mid command buffer preemption) by default as old Mesa
hangs with it. We shall not enable the feature that breaks old usermode
driver.
Fixes: 50a7c8765ca6 ("drm/amdgpu: enable mcbp by default on gfx9")
Signed-off-by: Jiadong Zhu <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
The i2c_master_send/recv() functions return negative error codes or
they return "len" on success. So the error handling here can be written
as just normal checks for "if (ret < 0) return ret;". No need to
complicate things.
Btw, in this code the "len" parameter can never be zero, but even if
it were, then I feel like this would still be the best way to write it.
Fixes: 914437992876 ("drm/bridge: nxp-ptn3460: fix i2c_master_send() error checking")
Suggested-by: Neil Armstrong <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Robert Foss <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This function is only used when debugfs is enabled, and otherwise
causes a build warning:
drivers/gpu/drm/imagination/pvr_fw_trace.c:135:1: error: 'update_logtype' defined but not used [-Werror=unused-function]
Move the #ifdef check to include this function as well.
Fixes: cb56cd610866 ("drm/imagination: Add firmware trace to debugfs")
Acked-by: Frank Binns <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Fixing the warning below due to an unused file level vtable. Removing
only this causes additional warnings for the now unused functions, so
I've removed those too.
>> drivers/gpu/drm/imagination/pvr_fw_trace.c:205:37: warning: 'pvr_fw_trace_group_mask_fops' defined but not used [-Wunused-const-variable=]
205 | static const struct file_operations pvr_fw_trace_group_mask_fops = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Changes since v1:
- Corrected hash in Fixes tag.
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Fixes: cb56cd610866 ("drm/imagination: Add firmware trace to debugfs")
Signed-off-by: Donald Robson <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
Closes: https://lore.kernel.org/dri-devel/[email protected]/
Suggested-by: Daniel Vetter <[email protected]>
Fixes: 94d879eaf7fb ("drm/atomic-helper: Add {begin,end}_fb_access to plane helpers")
Tested-by: Alyssa Ross <[email protected]>
Reviewed-by: Alyssa Ross <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: <[email protected]> # v6.2+
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Sui Jingfeng <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Sui Jingfeng <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Sui Jingfeng <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Tested-by: Sui Jingfeng <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The udl driver is the only caller of drm_plane_helper_atomic_check().
Move the function into the driver. No functional changes.
v2:
* fix documenation (Sui)
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Acked-by: Sui Jingfeng <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
On sc7280 there are two clk bits for WB2: vbif_cli and clk_ctrl. While
programming the VBIF params of WB, the driver should be toggling the
former bit, while the sc7180_mdp, sc7280_mdp and sm8250_mdp structs
list the latter one.
Correct that to ensure proper programming sequence for WB2 on these
platforms.
Fixes: 255f056181ac ("drm/msm/dpu: sc7180: add missing WB2 clock control")
Fixes: 3ce166380567 ("drm/msm/dpu: add writeback support for sc7280")
Fixes: 53324b99bd7b ("drm/msm/dpu: add writeback blocks to the sm8250 DPU catalog")
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Tested-by: Paloma Arellano <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570185/
Link: https://lore.kernel.org/r/[email protected]
|
|
Remove CONFIG_DRM_LEGACY from Kconfig. Nothing depends on the option.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove all remaining source code for non-KMS drivers. These drivers
have been removed in v6.3 and won't comeback.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Modern DRM drivers acquire ioctl locks by themselves. Legacy ioctls
for user-space mode setting used to acquire drm_global_mutex. After
removing the ioctl entry points, also remove the locking code. The only
legacy ioctl without global locking was VBLANK_WAIT, which has been
removed as well. Hence remove the related DRM_UNLOCKED flag.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove all hooks and calls into code for user-space mode setting from
the DRM core. Without the drivers and ioctl entry points, none of this
is required any longer.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
DRM drivers with user-space mode setting have been removed in Linux
v6.3. [1] Now remove the ioctl entry points for these drivers. Invoking
any of the ioctl ops will unconditionally return -EINVAL to user space.
Invoking DRM_IOCTL_MODESET_CTL is different from the other legacy
ioctl ops as it returns 0 even without CONFIG_DRM_LEGACY set. From the
original commit 29935554b384 ("drm: Disallow DRM_IOCTL_MODESET_CTL for
KMS drivers") it is not apparent how or why the operation differs from
the others. It is likely just an oversight in commit 61ae227032e7
("drm: allow removal of legacy codepaths (v4.1)"), which allowed
disabling leagacy ioctls in the first place. Still keep this removal
separate from the other ioctls to allow an easy revert, if necessary.
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/series/111602/ # [1]
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
DRM drivers with user-space mode setting have been removed in Linux
v6.3. [1] Now remove the ioctl entry points for these drivers. Invoking
any of the ioctl ops will unconditionally return -EINVAL to user space.
This has already been the behavior for kernels without CONFIG_DRM_LEGACY
set.
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/series/111602/ # [1]
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Including <drm/drm_legacy.h> is not required by radeon.
Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: "Christian König" <[email protected]>
Cc: "Pan, Xinhui" <[email protected]>
Cc: [email protected]
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Include <drm/drm_device.h> in drm_ioc32.c. Resolves a depenency
on <drm/drm_legacy.h>, which will be removed.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
One of the source files includes <drm/drm_auth.h> via <drm/drm_legacy.h>,
which will be removed. Include drm_auth.h directly.
Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: [email protected]
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
One of the source files includes <drm/drm_auth.h> via <drm/drm_legacy.h>,
which will be removed. Include drm_auth.h directly.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: David Airlie <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
It is incorrect to use devm-managed memory allocations for DRM data
structures exposed to userspace. They should use drmm_ allocations.
Change struct dpu_encoder allocation to use drmm_encoder_alloc(). This
removes the need to perform any actions on encoder destruction.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570053/
Link: https://lore.kernel.org/r/[email protected]
|
|
Drop the dpu_encoder_phys_ops' destroy() callback. No phys backend
implements it anymore, so it is useless.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570058/
Link: https://lore.kernel.org/r/[email protected]
|
|
Change struct allocation of encoder's phys backend data to use
drmm_kzalloc(). This removes the need to perform any actions on encoder
destruction.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570051/
Link: https://lore.kernel.org/r/[email protected]
|
|
Change struct dpu_crtc allocation to use drmm_crtc_alloc_with_planes().
This removes the need to perform any actions on CRTC destruction.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570054/
Link: https://lore.kernel.org/r/[email protected]
|
|
Change struct dpu_plane allocation to use drmm_universal_plane_alloc().
This removes the need to perform any actions on plane destruction.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570042/
Link: https://lore.kernel.org/r/[email protected]
|
|
There is little point in disabling QoS on plane destruction: it happens
during DPU device destruction process, after which there will be no
running planes.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570049/
Link: https://lore.kernel.org/r/[email protected]
|
|
The field dpu_plane::lock was never used for protecting any kind of
data. Drop it now.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570043/
Link: https://lore.kernel.org/r/[email protected]
|
|
Use devm_kzalloc to create HW block structure. This allows us to remove
corresponding kfree and drop all dpu_hw_*_destroy() functions as well as
dpu_rm_destroy(), which becomes empty afterwards.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570041/
Link: https://lore.kernel.org/r/[email protected]
|
|
Use devm_kzalloc to create MDP TOP structure. This allows us to remove
corresponding kfree and drop dpu_hw_mdp_destroy() function.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570047/
Link: https://lore.kernel.org/r/[email protected]
|
|
Use devm_kzalloc to create VBIF data structure. This allows us to
remove corresponding kfree and drop dpu_hw_vbif_destroy() function.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570040/
Link: https://lore.kernel.org/r/[email protected]
|
|
Use devm_kzalloc to create interrupts data structure. This allows us to
remove corresponding kfree and drop dpu_hw_intr_destroy() function.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570038/
Link: https://lore.kernel.org/r/[email protected]
|
|
Using IS_ERR_OR_NULL() together with PTR_ERR() is a typical mistake. If
the value is NULL, then the function will return 0 instead of a proper
return code. Replace IS_ERR_OR_NULL() with IS_ERR() in the
dpu_hw_intr_init() error check.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570036/
Link: https://lore.kernel.org/r/[email protected]
|
|
It was noticed that dpu_kms_hw_init()'s error path contains several
labels which point to the same code path. Replace all of them with a
single label.
Suggested-by: Konrad Dybcio <[email protected]>
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/570035/
Link: https://lore.kernel.org/r/[email protected]
|
|
Move the order of CMN 0x14e5 to make the list sorted.
Signed-off-by: Pin-yen Lin <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add support for the SDC ATNA45AF01 panel.
Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
the original
plane_view_scanout_stride() currently assumes that we had to pad the
mapping stride with dummy pages in order to align it. But that is not
the case if the original fb stride exceeds the aligned stride used
to populate the remapped view, which is calculated from the user
specified framebuffer width rather than the user specified framebuffer
stride.
Ignore the original fb stride in this case and just stick to the POT
aligned stride. Getting this wrong will cause the plane to fetch the
wrong data, and can lead to fault errors if the page tables at the
bogus location aren't even populated.
TODO: figure out if this is OK for CCS, or if we should instead increase
the width of the view to cover the entire user specified fb stride
instead...
Cc: Imre Deak <[email protected]>
Cc: Juha-Pekka Heikkila <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Imre Deak <[email protected]>
Reviewed-by: Juha-Pekka Heikkila <[email protected]>
|
|
The drm_atomic_print_new_state() already prints private object state via
drm_atomic_private_obj_print_state(). Add private object state dumping
to __drm_state_dump(), so that it is also included into drm_state_dump()
output and into debugfs/dri/N/state file.
Reviewed-by: Rob Clark <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Some users need to release resources attached to the vm_bo object when
it's destroyed. In Panthor's case, we need to release the pin ref so
BO pages can be returned to the system when all GPU mappings are gone.
This could be done through a custom drm_gpuvm::vm_bo_free() hook, but
this has all sort of locking implications that would force us to expose
a drm_gem_shmem_unpin_locked() helper, not to mention the fact that
having a ::vm_bo_free() implementation without a ::vm_bo_alloc() one
seems odd. So let's keep things simple, and extend drm_gpuvm_bo_put()
to report when the object is destroyed.
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Danilo Krummrich <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
To make sure that we don't unintentionally perform any unclocked and/or
unpowered R/W operation on GPU registers, before turning off clocks and
regulators we must make sure that no GPU, JOB or MMU ISR execution is
pending: doing that requires to add a mechanism to synchronize the
interrupts on suspend.
Add functions panfrost_{gpu,job,mmu}_suspend_irq() which will perform
interrupts masking and ISR execution synchronization, and then call
those in the panfrost_device_runtime_suspend() handler in the exact
sequence of job (may require mmu!) -> mmu -> gpu.
As a side note, JOB and MMU suspend_irq functions needed some special
treatment: as their interrupt handlers will unmask interrupts, it was
necessary to add an `is_suspended` bitmap which is used to address the
possible corner case of unintentional IRQ unmasking because of ISR
execution after a call to synchronize_irq().
At resume, clear each is_suspended bit in the reset path of JOB/MMU
to allow unmasking the interrupts.
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In preparation for adding a IRQ synchronization mechanism for PM suspend,
add gpu_irq and mmu_irq variables to struct panfrost_device and change
functions panfrost_gpu_init() and panfrost_mmu_init() to use those.
Reviewed-by: Boris Brezillon <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
is partial, as this driver currently supports using only one
core group and that's reflected on all parts of it, including
the power on (and power off, previously to this patch) function.
The issue with this is that even though executing the soft reset
operation should power off all cores unconditionally, on at least
one platform we're seeing a crash that seems to be happening due
to an interrupt firing which may be because we are calling power
transition only on the first core group, leaving the second one
unchanged, or because ISR execution was pending before entering
the panfrost_gpu_power_off() function and executed after powering
off the GPU cores, or all of the above.
Finally, solve this by:
- Avoid to enable the power transition interrupt on reset; and
- Ignoring the core_mask and ask the GPU to poweroff both core groups
Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()")
Reviewed-by: Boris Brezillon <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Current, the dewake_scanline variable is defined as unsigned int,
an unsigned int variable that is always greater than or equal to 0.
when _intel_dsb_commit function is called by intel_dsb_commit function,
the dewake_scanline variable may have an int value.
So the dewake_scanline variable is necessary to defined as an int.
Fixes: f83b94d23770 ("drm/i915/dsb: Use DEwake to combat PkgC latency")
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Cc: Ville Syrjälä <[email protected]>
Cc: Uma Shankar <[email protected]>
Signed-off-by: heminhong <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit ef32c3cc9c62252986f09e06b4e525742cd91529)
Signed-off-by: Jani Nikula <[email protected]>
|