[AMD Official Use Only - General]
Acked-by: Feifei Xu
-Original Message-
From: Horatio Zhang
Sent: Tuesday, May 30, 2023 2:53 AM
To: amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Yao, Longlong ;
Zhang, Horatio ; Pan, Xinhui
Subject: [PATCH] drm/amdgpu: fix Null pointer dereference
Remove redundant assignment code for ttm->caching as it's overwritten
just a few lines later.
v2:
- Update the commit message.
Signed-off-by: Ma Jun
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
Fixes the following gcc with W=1:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1904:
warning: Function parameter or member 'dc' not described in
'delay_cursor_until_vupdate'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1904:
warning: Function
This quirk of for_each_inst has caused problems more than once. Why not
use for_each_set_bit to implement it? That one doesn't have side effects.
Regards,
Felix
Am 2023-05-29 um 09:58 schrieb Lijo Lazar:
for_each_inst modifies xcc_mask and therefore the loop doesn't
initialize properly
From: Nicholas Kazlauskas
[Why]
Hardware implements root clock gating by utilizing the DPP DTO registers
with a special case of DTO enabled, phase = 0, modulo = 1. This
conflicts with our policy to always update the DPPDTO for cases where
it's expected to be disabled.
The pipes unexpectedly
From: Daniel Miess
[Why and How]
Add back debug bits enabling RCO for dcn314 as underflow
associated with this change has been resolved
Acked-by: Stylon Wang
Signed-off-by: Daniel Miess
Reviewed-by: Jun Lei
---
.../drm/amd/display/dc/dcn314/dcn314_resource.c | 16
1 file
From: Austin Zheng
Why:
Limit maximum clock speeds to DC mode limits for DC mode systems
How:
Store DC mode limits when individual clocks are initialized and
cap the values when building the clock table
Acked-by: Stylon Wang
Signed-off-by: Austin Zheng
Reviewed-by: Alvin Lee
---
From: Sridevi
[Why]
Programming register delta for DSC sub-block
[How]
Change DSC, resource files for programming register delta.
Acked-by: Stylon Wang
Signed-off-by: Sridevi
Reviewed-by: Chris Park
---
.../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 29 +++
From: Leo Ma
Revert commit 9caa026e4e65 ("drm/amd/display: cache trace buffer size")
to fix regression found in tests.
Acked-by: Stylon Wang
Signed-off-by: Leo Ma
Reviewed-by: Josip Pavic
---
drivers/gpu/drm/amd/display/dmub/dmub_srv.h | 1 -
From: Charlene Liu
[why]
check dmub_Srv exist or not before accessing dmub.
Acked-by: Stylon Wang
Signed-off-by: Charlene Liu
Reviewed-by: Zhan Liu
---
drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Aurabindo Pillai
Revert commit d54f66bc9c37 ("Revert drm/amd/display: Enable Freesync Video Mode
by default")
Enables freesync video by default, since the hang and corruption issue
on eDP panels are now fixed.
Acked-by: Stylon Wang
Signed-off-by: Aurabindo Pillai
Reviewed-by: Rodrigo
From: Alvin Lee
[Description]
Reduce expected SDP bandwidth due to poor QoS and
arbitration issues on high bandwidth configs
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Acked-by: Stylon Wang
Signed-off-by: Alvin Lee
Reviewed-by: Nevenko Stupar
---
From: Max Tseng
Add control flag to dc_stream_state to skip eDP BL off/link off.
Acked-by: Stylon Wang
Signed-off-by: Max Tseng
Reviewed-by: Anthony Koo
---
drivers/gpu/drm/amd/display/dc/dc_stream.h | 1 +
.../gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c| 3 ++-
From: Alvin Lee
[Description]
- Refactor HW sequencer to use a build / execute sequence
- Also move gamma updates to become fast
Acked-by: Stylon Wang
Signed-off-by: Alvin Lee
Reviewed-by: Jun Lei
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 271 --
From: Saaem Rizvi
[Why and How]
Type mismatch in index and pipe count might cause an infinite loop. code
Change should resolve this issue.
Acked-by: Stylon Wang
Signed-off-by: Saaem Rizvi
Reviewed-by: Josip Pavic
---
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c | 2 +-
From: Dmytro Laktyushkin
Change to improve avoiding asymetric crb calculations for single stream
scenarios.
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Acked-by: Stylon Wang
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Charlene Liu
---
From: Samson Tam
[Why]
When going from ODM 2:1 single display case to max displays, second
odm pipe needs to be repurposed for one of the new single displays.
However, acquire_first_split_pipe() only handles MPC case and not
ODM case
[How]
Add ODM conditions in acquire_first_split_pipe()
Add
From: Dmytro Laktyushkin
Add missing programming and function pointers
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Acked-by: Stylon Wang
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Charlene Liu
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 11
This DC patchset brings improvements in multiple areas. In summary, we have:
* Clock optimiation for DCN 3.1.4
* Performance improvements
* Improvements on power saving
* Fix screen flash in high resolution displays
* Enable Freesync video mode by default
* Bug fixed on hang or crashes in various
uvd ring in uvd_v7_0_sw_init only initializes ring in bare metal case,
so when executing amdgpu_uvd_resume to restore fence seq in SRIOV,
a null pointer dereference will occur. This patch correct this.
Fixes: 043f2271e2d0a ("drm/amdgpu: mark force completed fences with -ECANCELED")
BUG: kernel
Fixes the following gcc with W=1:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1904:
warning: Function parameter or member 'dc' not described in
'delay_cursor_until_vupdate'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1904:
warning: Function
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_resource_helpers.c:97:
warning: Cannot understand *
**
[Why]
The sequence for collecting down_reply from source perspective should
be:
Request_n->repeat (get partial reply of Request_n->clear message ready
flag to ack DPRX that the message is received) till all partial
replies for Request_n are received->new Request_n+1.
Now there is chance that
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_hubbub.c:45: warning:
Cannot understand * @DCN32_CRB_SEGMENT_SIZE_KB: Maximum Configurable Return
Buffer size for
on line 45 - I thought it was a doc line
Cc: Hamza Mahfooz
Cc: Rodrigo
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_resource.c:128:29:
warning: ‘DCN_BASE’ defined but not used [-Wunused-const-variable=]
128 | static const struct IP_BASE DCN_BASE = { { { { 0x0012, 0x00C0,
0x34C0, 0x9000,
On 5/30/2023 4:59 PM, Christian König wrote:
> Am 29.05.23 um 11:28 schrieb Ma Jun:
>> Remove redundant assignment code for ttm->caching
>
> The explanation is missing why this is redundant, e.g. something like
> "this is overwritten just a few lines later"..
>
Thanks for review. Will
[Public]
Reviewed-by: Guchun Chen
Regards,
Guchun
> -Original Message-
> From: Bob Zhou
> Sent: Tuesday, May 30, 2023 5:52 PM
> To: amd-gfx@lists.freedesktop.org; Zhu, James
> Cc: Cui, Flora ; Chen, Guchun
> ; Shi, Leslie ; Ma, Jun
> ; Song, Asher ; Zhou, Bob
>
> Subject: [PATCH]
Users have reported that s2idle wasn't working on OEM Phoenix systems,
but it was root caused to be because `CONFIG_AMD_PMC` wasn't set in
the distribution kernel config.
To make this more apparent, raise the messaging to err instead of warn.
Link:
commit cf488dcd0ab7 ("drm/amd: Allow s0ix without BIOS support") showed
improvements to power consumption over suspend when s0ix wasn't enabled in
BIOS and the system didn't support S3.
This patch however was misguided because the reason the system didn't
support S3 was because SMT was disabled
On 5/30/2023 4:34 PM, Alex Deucher wrote:
On Tue, May 30, 2023 at 2:19 PM Limonciello, Mario
wrote:
[AMD Official Use Only - General]
-Original Message-
From: Alex Deucher
Sent: Tuesday, May 30, 2023 1:16 PM
To: Limonciello, Mario
Cc: amd-gfx@lists.freedesktop.org; Rafael Ávila
On Tue, May 30, 2023 at 2:19 PM Limonciello, Mario
wrote:
>
> [AMD Official Use Only - General]
>
> > -Original Message-
> > From: Alex Deucher
> > Sent: Tuesday, May 30, 2023 1:16 PM
> > To: Limonciello, Mario
> > Cc: amd-gfx@lists.freedesktop.org; Rafael Ávila de Espíndola
> >
> >
Fix the following W=1 kernel build warning:
display/dc/dcn10/dcn10_hw_sequencer_debug.c: In function ‘snprintf_count’:
display/dc/dcn10/dcn10_hw_sequencer_debug.c:56:2: warning: function
‘snprintf_count’ might be a candidate for ‘gnu_printf’ format attribute
[-Wsuggest-attribute=format]
Use
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Similar to queue snapshot, return an array of device information using
an entry_size check and return.
Unlike queue snapshots, the debugger needs to pass to correct number of
devices that exist. If it fails to do so, the KFD will return the
number of
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Allow the debugger to set single memory and single ALU operations.
Some exceptions are imprecise (memory violations, address watch) in the
sense that a trap occurs only when the exception interrupt occurs and
not at the non-halting faulty
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Shader read, write and atomic memory operations can be alerted to the
debugger as an address watch exception.
Allow the debugger to pass in a watch point to a particular memory
address per device.
Note that there exists only 4 watch points per
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
In order to inspect waves from the saved context at any point during a
debug session, the debugger must be able to preempt queues to trigger
context save by suspending them.
On queue suspend, the KFD will copy the context save header information
so
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Allow the debugger to set wave behaviour on to either normally operate,
halt at launch, trap on every instruction, terminate immediately or
stall on allocation.
v2: fixup with new kfd_node struct reference for mes check
Signed-off-by: Jonathan Kim
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
This operation allows the debugger to override the enabled HW
exceptions on the device.
On debug devices that only support the debugging of a single process,
the HW exceptions are global and set through the SPI_GDBG_TRAP_MASK
register.
Because they
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
The debugger must be notified by any debugger subscribed exception
that comes from hardware interrupts.
If a debugger session exits, any exceptions it subscribed to may still
have interrupts in the interrupt ring buffer or KGD/KFD pipeline.
To
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
The debugger can attach to a process prior to HSA enablement (i.e.
inferior is spawned by the debugger and attached to immediately before
target process has been enabled for HSA dispatches) or it
can attach to a running target that is already HSA
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Exception events can be generated from interrupts or queue activitity.
The raise event function will save exception status of a queue, device
or process then notify the debugger of the status change by writing to
a debugger polled file descriptor
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
To enable HW debug mode per process, all devices must be debug enabled
successfully. If a failure occures, rewind the enablement of debug mode
on the enabled devices.
A power management scenario that needs to be considered is HW
debug mode setting
[Public]
> -Original Message-
> From: Kuehling, Felix
> Sent: Tuesday, May 30, 2023 3:56 PM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Huang, JinHuiEric
> Subject: Re: [PATCH 14/33] drm/amdgpu: prepare map process for multi-
> process
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Unlike single process debug devices, multi-process debug devices allow
debug mode setting per-VMID (non-device-global).
Because the HWS manages PASID-VMID mapping, the new MAP_PROCESS API allows
the KFD to forward the required SPI debug register
Hi Evan,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on kvalo-ath/ath-next wireless-next/main wireless/main]
[cannot apply to linus/master v6.4-rc4 next-20230530]
[If your patch is applied to the wrong git tree
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Older HW only supports debugging on a single process because the
SPI debug mode setting registers are device global.
The HWS has supplied a single pinned VMID (0xf) for MAP_PROCESS
for debug purposes. To pin the VMID, the KFD will remove the VMID
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
|diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c
b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c index
faf4772ed317..a0cfd57ea84a 100644 ---
a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c +++
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Add missing debug trap registers references and initialize all debug
registers on boot by clearing the hardware exception overrides and the
wave allocation ID index.
The debugger requires that TTMPs 6 & 7 save the dispatch ID to map
waves onto
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Expose debug capabilities in the KFD topology node's HSA capabilities and
debug properties flags.
Ensure correct capabilities are exposed based on firmware support.
Flag definitions can be referenced in uapi/linux/kfd_sysfs.h.
v2: rebase topology
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Introduce the GPU debug operations interface.
For ROCm-GDB to extend the GNU Debugger's ability to inspect the AMD GPU
instruction set, provide the necessary interface to allow the debugger
to HW debug-mode set and query exceptions per HSA queue,
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_vba.c:936: warning:
Cannot understand *
*
Cc: Aurabindo Pillai
Signed-off-by: Srinivasan Shanmugam
---
[AMD Official Use Only - General]
> -Original Message-
> From: Limonciello, Mario
> Sent: Tuesday, May 30, 2023 1:38 PM
> To: Rafael Ávila de Espíndola ; Alex Deucher
>
> Cc: amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 1/2] drm/amd: Disallow s0ix without BIOS support again
>
> >
Fix this warning by adding 'ring' arguments to kdoc.
gcc with W=1
drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c:1128: warning: Function parameter or
member 'ring' not described in 'sdma_v6_0_ring_pad_ib'
Cc: Felix Kuehling
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Srinivasan Shanmugam
[AMD Official Use Only - General]
> As far as I know the "no S3 if SMT off" is just an oddity of the
> particular BIOS I got on the "B550I AORUS PRO AX".
In that case, maybe the message should be downgraded to INFO, and
only shown in the case that s3 is not supported on APUs. This will
narrow
[Public]
> -Original Message-
> From: Christoph Hellwig
> Sent: Friday, May 26, 2023 2:55 AM
> To: Deucher, Alexander
> Cc: Christoph Hellwig ; Alex Deucher
> ; bhelg...@google.com; amd-
> g...@lists.freedesktop.org; Zhang, Morris ; linux-
> p...@vger.kernel.org
> Subject: Re: [PATCH]
[AMD Official Use Only - General]
> -Original Message-
> From: Alex Deucher
> Sent: Tuesday, May 30, 2023 1:16 PM
> To: Limonciello, Mario
> Cc: amd-gfx@lists.freedesktop.org; Rafael Ávila de Espíndola
>
> Subject: Re: [PATCH 1/2] drm/amd: Disallow s0ix without BIOS support again
>
>
On Tue, May 30, 2023 at 1:53 PM Mario Limonciello
wrote:
>
> commit cf488dcd0ab7 ("drm/amd: Allow s0ix without BIOS support") showed
> improvements to power consumption over suspend when s0ix wasn't enabled in
> BIOS and the system didn't support S3.
>
> This patch however was misguided because
Am 19.05.23 um 03:09 schrieb Chen, Xiaogang:
On 5/17/2023 5:10 PM, Felix Kuehling wrote:
Caution: This message originated from an External Source. Use proper
caution when opening attachments, clicking links, or responding.
On 2023-05-17 17:40, Mukul Joshi wrote:
Add a low priority DRM
Am 17.05.23 um 23:01 schrieb Alex Deucher:
On Wed, May 17, 2023 at 11:02 AM Alex Deucher wrote:
+ dri-devel for scheduler
On Tue, May 9, 2023 at 6:23 AM ZhenGuo Yin wrote:
[Why]
drm_sched_entity_add_dependency_cb ignores the scheduled fence and return false.
If entity's dependency is a
Users have reported that s2idle wasn't working on OEM Phoenix systems,
but it was root caused to be because `CONFIG_AMD_PMC` wasn't set in
the distribution kernel config.
To make this more apparent, raise the messaging to err instead of warn.
Link:
commit cf488dcd0ab7 ("drm/amd: Allow s0ix without BIOS support") showed
improvements to power consumption over suspend when s0ix wasn't enabled in
BIOS and the system didn't support S3.
This patch however was misguided because the reason the system didn't
support S3 was because SMT was disabled
Am 2023-05-29 um 10:56 schrieb Srinivasan Shanmugam:
Fix these warnings by adding 'xcp_id' argument.
gcc with W=1
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:160: warning: Function
parameter or member 'xcp_id' not described in 'amdgpu_amdkfd_reserve_mem_limit'
Cc: Christian König
Cc:
[Public]
Reviewed-by: Kenny Ho
On 5/30/23 11:50, Ho, Kenny wrote:
[Public]
On 5/30/23 11:24, Hamza Mahfooz wrote:
I am able to get clean builds with this enabled on GCC 11-13 and Clang
15, at least as of commit e786aef0869c ("drm/amd/display: remove unused
definition") on amd-staging-drm-next.
Did you try intentionally
Am 2023-05-30 um 00:54 schrieb Srinivasan Shanmugam:
Fix these warnings by adding & deleting the deviant arguments.
gcc with W=1
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:671: warning: Function
parameter or member 'node' not described in 'svm_migrate_vma_to_ram'
[Public]
On 5/30/23 11:24, Hamza Mahfooz wrote:
> I am able to get clean builds with this enabled on GCC 11-13 and Clang
> 15, at least as of commit e786aef0869c ("drm/amd/display: remove unused
> definition") on amd-staging-drm-next.
Did you try intentionally introducing a warning to see if the
Hi Thomas,
> > > - if (helper->funcs->fb_dirty) {
> > > - drm_fb_helper_memory_range_to_clip(info, pos, ret,
> > > _area);
> > > - drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
> > > - drm_rect_width(_area),
> > > -
On 5/30/2023 1:22 AM, Felix Fietkau wrote:
On 30.05.23 04:42, Evan Quan wrote:
Due to electrical and mechanical constraints in certain platform
designs there may
be likely interference of relatively high-powered harmonics of the
(G-)DDR memory
clocks with local radio module frequency bands
On Mon, May 29, 2023 at 10:56 AM Srinivasan Shanmugam
wrote:
>
> Fix these warnings by adding 'xcp_id' argument.
>
> gcc with W=1
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:160: warning: Function
> parameter or member 'xcp_id' not described in
> 'amdgpu_amdkfd_reserve_mem_limit'
>
> Cc:
On Mon, May 29, 2023 at 10:10 AM Srinivasan Shanmugam
wrote:
>
> Fix these warnings by adding 'xcc_id' arguments.
>
> gcc with W=1
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:1557: warning: Function parameter or
> member 'xcc_id' not described in 'gfx_v7_0_select_se_sh'
>
On 5/25/23 12:38, Hamza Mahfooz wrote:
We want to do -Werror builds on our CI. However, non-amdgpu breakages
have prevented us from doing so thus far. Also, there are a number of
additional checks that we should enable, that the community cares about
and are hidden behind -Wextra. So, define
On Tue, May 30, 2023 at 5:17 AM Srinivasan Shanmugam
wrote:
>
> Fix these warnings by adding 'inst' arguments to kdocs.
>
> gcc with W=1
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:428: warning: Function parameter or
> member 'inst' not described in 'gmc_v7_0_flush_gpu_tlb_pasid'
>
Series is:
Acked-by: Alex Deucher
On Thu, May 25, 2023 at 9:19 PM wrote:
>
> From: Jiadong Zhu
>
> Patch the packages including CONTEXT_CONTROL and WRITE_DATA for gfx9
> during the resubmission scenario.
>
> Signed-off-by: Jiadong Zhu
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 80
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_()
and fb_sys_() helpers. The DRM functions don't provide any additional
functionality for most DRM drivers. So remove them and call the fbdev
I/O helpers directly.
The DRM fbdev I/O wrappers were originally added because
does
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
v3:
* fix select statement (Jingfeng)
Signed-off-by: Thomas
Am 2023-05-30 um 08:48 schrieb Srinivasan Shanmugam:
Fix these warnings by adding 'inst' arguments to kdocs.
gcc with W=1
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:692: warning: Function
parameter or member 'inst' not described in 'get_wave_count'
Acked-by: Alex Deucher
On Tue, May 30, 2023 at 5:52 AM Bob Zhou wrote:
>
> After drm conduct amdgpu Makefile, amdgpu.ko has been created
> and "amdgpu-y +=" in amdxcp Makefile isn't used.
> So modify amdgpu-y to amdxcp-y and build amdxcp module.
>
> Signed-off-by: Bob Zhou
> ---
>
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
v3:
* fix select statement (Jingfeng)
Signed-off-by: Thomas
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
1 - 100 of 124 matches
Mail list logo
