This patch reverses the DPM clocks levels output of pp_dpm_mclk
and pp_dpm_fclk for renoir.
On dGPUs and older APUs we expose the levels from lowest clocks
to highest clocks. But for some APUs, the clocks levels are
given the reversed orders by PMFW. Like the memory DPM clocks
that are exposed by
[AMD Official Use Only - General]
Hi Bjorn,
Can we merge the below change through amdgpu tree ? Thanks!
--Brs,
Morris Zhang
MLSE Linux ML SRDC
Ext. 25147
> -Original Message-
> From: amd-gfx On Behalf Of Shiwu
> Zhang
> Sent: Tuesday, May 23, 2023 12:03 PM
> To: amd-gfx@lists.freedes
v2: add the base class id for accelerator (lijo)
Signed-off-by: Shiwu Zhang
Acked-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +
include/linux/pci_ids.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/driv
On Sun, 21 May 2023 at 10:03, Dmitry Baryshkov
wrote:
>
> On 15/05/2023 17:30, Rob Clark wrote:
> > From: Rob Clark
> >
> > Similar motivation to other similar recent attempt[1]. But with an
> > attempt to have some shared code for this. As well as documentation.
> >
> > It is probably a bit UM
On Mon, 22 May 2023 15:50:32 +, Azeem Shaikh wrote:
> strlcpy() reads the entire source buffer first.
> This read may exceed the destination size limit.
> This is both inefficient and can lead to linear read
> overflows if a source string is not NUL-terminated [1].
> In an effort to remove strl
On Mon, 22 May 2023 15:52:45 +, Azeem Shaikh wrote:
> strlcpy() reads the entire source buffer first.
> This read may exceed the destination size limit.
> This is both inefficient and can lead to linear read
> overflows if a source string is not NUL-terminated [1].
> In an effort to remove strl
[Public]
> -Original Message-
> From: Kees Cook
> Sent: Monday, May 22, 2023 4:16 PM
> To: Azeem Shaikh
> Cc: Quan, Evan ; linux-harden...@vger.kernel.org;
> amd-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; Deucher,
> Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Ai
[Public]
> -Original Message-
> From: Kees Cook
> Sent: Monday, May 22, 2023 4:15 PM
> To: Azeem Shaikh
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; linux-
> harden...@vger.kernel.org; amd-gfx@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; David Airlie ; Daniel
On Mon, May 22, 2023 at 03:50:32PM +, Azeem Shaikh wrote:
> strlcpy() reads the entire source buffer first.
> This read may exceed the destination size limit.
> This is both inefficient and can lead to linear read
> overflows if a source string is not NUL-terminated [1].
> In an effort to remov
On Mon, May 22, 2023 at 03:52:45PM +, Azeem Shaikh wrote:
> strlcpy() reads the entire source buffer first.
> This read may exceed the destination size limit.
> This is both inefficient and can lead to linear read
> overflows if a source string is not NUL-terminated [1].
> In an effort to remov
Am 21.05.23 um 20:49 schrieb Chia-I Wu:
On Thu, May 18, 2023 at 1:12 PM Alex Deucher wrote:
On Wed, May 17, 2023 at 5:27 PM Chia-I Wu wrote:
On Tue, May 9, 2023 at 11:33 AM Chia-I Wu wrote:
Extend the address and size validations to AMDGPU_VA_OP_UNMAP and
AMDGPU_VA_OP_CLEAR by moving the va
Hi
Am 22.05.23 um 15:20 schrieb Dmitry Baryshkov:
On Mon, 22 May 2023 at 15:22, Thomas Zimmermann wrote:
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Fbdev-generic was the only caller of the
DRM helpers, so remove them from the helper module.
v2:
tree/branch: INFO setup_repo_specs:
/db/releases/20230522162832/lkp-src/repo/*/linux-next
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 9f258af06b6268be8e960f63c3f66e88bdbbbdb0 Add linux-next specific
files for 20230522
Warning reports:
https
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
No re
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
No re
On Mon, May 22, 2023 at 11:19 AM Alex Deucher wrote:
>
> On Mon, May 8, 2023 at 6:48 AM Srinivasan Shanmugam
> wrote:
> >
> > Assignments in if condition are less readable and error-prone.
> >
> > Fixes below error & warnings reported by checkpatch"
> >
> > ERROR: do not use assignment in if cond
On Mon, May 8, 2023 at 6:48 AM Srinivasan Shanmugam
wrote:
>
> Assignments in if condition are less readable and error-prone.
>
> Fixes below error & warnings reported by checkpatch"
>
> ERROR: do not use assignment in if condition
> + } else if ((src = adev->irq.client[client_id].sources[sr
Applied. Thanks!
Alex
On Mon, May 22, 2023 at 8:30 AM Tom Rix wrote:
>
> gcc with W=1 reports
> drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:2138:13: error: variable
> ‘num_xcc’ set but not used [-Werror=unused-but-set-variable]
> 2138 | int num_xcc;
> | ^~~
>
> This
Applied the series. Thanks!
Alex
On Mon, May 22, 2023 at 7:51 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Two newly introduced functions are in the global namespace but have no
> prototypes
> or callers outside of amdgpu_acpi.c, another function is static but only has
> a caller insid
Applied. Thanks!
On Mon, May 22, 2023 at 3:30 AM Harshit Mogalapalli
wrote:
>
> Smatch warns:
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:579:
> unsigned 'xcc_id' is never less than zero.
>
> gfx_v9_4_3_ih_to_xcc_inst() returns negative numbers as well.
> Fix this by changing type of
Applied. Thanks!
On Mon, May 22, 2023 at 5:02 AM Colin Ian King wrote:
>
> There are a couple of spelling mistakes, one in a dev_info message
> and the other in a dev_debug message. Fix them.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
> drivers/gp
Applied. Thanks!
On Mon, May 22, 2023 at 3:20 AM Jonatas Esteves wrote:
>
> Printing the other clock types should not be conditioned on being able
> to print OD_SCLK. Some GPUs currently have limited capability of only
> printing a subset of these.
>
> Since this condition was introduced in v5.1
Series is:
Acked-by: Alex Deucher
On Thu, May 18, 2023 at 3:04 AM Guchun Chen wrote:
>
> sched.ready is nothing with ring initialization, it needs to set
> to be true after ring/IB test in amdgpu_ring_test_helper to tell
> the ring is ready for submission.
>
> Signed-off-by: Guchun Chen
> ---
>
[AMD Official Use Only - General]
Thanks Alex.
Renoir didn't use the DFPstateTable but it needs to reverse the clocks levels
as well.
Will send out a new patch for Renoir.
Best Regards,
Tim
From: Alex Deucher
Sent: Monday, May 22, 2023 9:19 PM
To: Huang, Tim
On Sat, May 20, 2023 at 1:34 AM Zibin Liu wrote:
>
> Hi,
>
> I'm looking at the initialization sequences in gfxhub_v2_1.c. I'm confused on
> whether the GCVM_CONTEXT1_CNTL CNTL reg can be written before the
> corresponding GCVM_CONTEXT1_PAGE_TABLE_START_ADDR and
> GCVM_CONTEXT1_PAGE_TABLE_END_A
On Mon, 22 May 2023 at 15:22, Thomas Zimmermann wrote:
>
> Implement dedicated fbdev helpers for framebuffer I/O instead
> of using DRM's helpers. Fbdev-generic was the only caller of the
> DRM helpers, so remove them from the helper module.
>
> v2:
> * use FB_SYS_HELPERS_DEFERRED option
>
Reviewed-by: Alex Deucher
Does Renoir need a similar fix?
Alex
On Mon, May 22, 2023 at 6:10 AM Tim Huang wrote:
>
> This patch reverses the DPM clocks levels output of pp_dpm_mclk
> and pp_dpm_fclk.
>
> On dGPUs and older APUs we expose the levels from lowest clocks
> to highest clocks. But fo
From: Michel Dänzer
This reverts commit ce560ac40272a5c8b5b68a9d63a75edd9e66aed2.
It depends on its parent commit, which we want to revert.
Signed-off-by: Michel Dänzer
---
.../drm/amd/display/dc/dcn20/dcn20_hwseq.c| 3 ---
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 22 +++--
From: Michel Dänzer
This reverts commit 474f01015ffdb74e01c2eb3584a2822c64e7b2be.
Caused a regression:
Samsung Odyssey Neo G9, running at 5120x1440@240/VRR, connected to Navi
21 via DisplayPort, blanks and the GPU hangs while starting the Steam
game Assetto Corsa Competizione (via Proton 7.0).
Smatch warns:
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:579:
unsigned 'xcc_id' is never less than zero.
gfx_v9_4_3_ih_to_xcc_inst() returns negative numbers as well.
Fix this by changing type of xcc_id to int.
Fixes: faf96b9b602d ("drm/amdgpu: correct the vmhub index when page fault
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:2138:13: error: variable
‘num_xcc’ set but not used [-Werror=unused-but-set-variable]
2138 | int num_xcc;
| ^~~
This variable is not used so remove it.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/am
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c:760:23: error:
‘mmhub_v1_8_mmea_cgtt_clk_cntl_reg’ defined but not used
[-Werror=unused-const-variable=]
760 | static const uint32_t mmhub_v1_8_mmea_cgtt_clk_cntl_reg[] = {
| ^~
There are a couple of spelling mistakes, one in a dev_info message
and the other in a dev_debug message. Fix them.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
d
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Fbdev-generic was the only caller of the
DRM helpers, so remove them from the helper module.
v2:
* use FB_SYS_HELPERS_DEFERRED option
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. i915 was the only caller of the DRM
helpers, so remove them from the helper module.
v2:
* use FB_IO_HELPERS options
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Viv
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 entire
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 thems
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.
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 no
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 enti
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 entirely
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 entirel
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 entirel
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 Zimme
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 entirel
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 entirel
From: Arnd Bergmann
Two newly introduced functions are in the global namespace but have no
prototypes
or callers outside of amdgpu_acpi.c, another function is static but only has
a caller inside of an #ifdef:
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:902:13: error: no previous prototype
for 'am
From: Arnd Bergmann
DMA addresses can be shorter than u64, which results in a broken debug output:
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c: In function
'amdgpu_gart_table_ram_alloc':
drivers/gpu/drm/amd/amdgpu/amdgpu.h:41:22: error: format '%llx' expects
argument of type 'long long unsigned i
From: Arnd Bergmann
A few newly added global functions have no prototype, which causes warnings:
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c:169:5: error: no previous
prototype for 'aqua_vanjaram_select_scheds' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_in
From: Arnd Bergmann
The file was newly added and causes some -Wmissing-prototype warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c:57:5: error: no previous
prototype for 'kgd_gfx_v9_4_3_hqd_sdma_load' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c:1
From: Arnd Bergmann
Two newly added functions cause a warning because they lack a prototype:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:1328:5: error:
no previous prototype for 'smu_v13_0_6_set_irq_state'
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/s
This patch reverses the DPM clocks levels output of pp_dpm_mclk
and pp_dpm_fclk.
On dGPUs and older APUs we expose the levels from lowest clocks
to highest clocks. But for some APUs, the clocks levels that from
the DFPstateTable are given the reversed orders by PMFW. Like the
memory DPM clocks tha
This patch reverses the DPM clocks levels output of pp_dpm_mclk
and pp_dpm_fclk.
On dGPUs and older APUs we expose the levels from lowest clocks
to highest clocks. But for some APUs, the clocks levels that from
the DFPstateTable are given the reversed orders by PMFW. Like the
memory DPM clocks tha
This patch reverses the DPM clocks levels output of pp_dpm_mclk
and pp_dpm_fclk.
On dGPUs and older APUs we expose the levels from lowest clocks
to highest clocks. But for some APUs, the clocks levels that from
the DFPstateTable are given the reversed orders by PMFW. Like the
memory DPM clocks tha
This patch reverses the DPM clocks levels output of pp_dpm_mclk.
On dGPUs and older APUs we expose the levels from lowest clocks
to highest clocks. But for some APUs, the clocks levels that from
the DFPstateTable are given the reversed orders by PMFW. Like the
memory DPM clocks that are exposed by
On 19/05/2023 23:22, Alex Deucher wrote:
On Mon, Apr 24, 2023 at 1:39 PM Shashank Sharma wrote:
This patch adds new functions to map/unmap a usermode queue into
the FW, using the MES ring. As soon as this mapping is done, the
queue would be considered ready to accept the workload.
V1: Addre
On 19/05/2023 23:22, Alex Deucher wrote:
On Mon, Apr 24, 2023 at 1:39 PM Shashank Sharma wrote:
From: Arvind Yadav
This patch sets new parameters defined in v11_struct for
usermode queue with the respective allocated gpu context
space addresses.
V4: Split the patch into two parts, keep onl
On 19/05/2023 23:21, Alex Deucher wrote:
On Mon, Apr 24, 2023 at 1:39 PM Shashank Sharma wrote:
The FW expects us to allocate at least one page as context
space to process gang, process, GDS and FW related work.
This patch creates a joint object for the same, and calculates
GPU space offsets
On 19/05/2023 23:19, Alex Deucher wrote:
On Mon, Apr 24, 2023 at 1:39 PM Shashank Sharma wrote:
A Memory queue descriptor (MQD) of a userqueue defines it in
the hw's context. As MQD format can vary between different
graphics IPs, we need gfx GEN specific handlers to create MQDs.
This patch:
Hey Alex,
Thanks for the review comments, please find mine inline.
- Shashank
On 19/05/2023 23:03, Alex Deucher wrote:
On Mon, Apr 24, 2023 at 1:39 PM Shashank Sharma wrote:
From: Alex Deucher
This patch intorduces new UAPI/IOCTL for usermode graphics
queue. The userspace app will fill thi
On Wed, May 10, 2023 at 03:26:56PM +0700, Bagas Sanjaya wrote:
> Anyway, let me add this regression to regzbot:
>
> #regzbot introduced: v5.10..v5.11
> https://bugzilla.kernel.org/show_bug.cgi?id=212579
> #regzbot title: Booting kernel on AMD Ryzen 5 PRO stucks in loading initrd
Resolving...
#r
/me removes a few people from CC, as this thread already annoyed a few
people
On 11.05.23 10:06, Bagas Sanjaya wrote:
>
> I notice a regression report on bugzilla ([1]). As many developers
> don't keep an eye on it, I decide to forward it by email.
> [...]
> #regzbot introduced: v6.2..v6.3
> ht
Printing the other clock types should not be conditioned on being able
to print OD_SCLK. Some GPUs currently have limited capability of only
printing a subset of these.
Since this condition was introduced in v5.18-rc1, reading from
`pp_od_clk_voltage` has been returning empty on the Asus ROG Strix
I also crossposted here upon request:
https://gitlab.freedesktop.org/drm/amd/-/issues/2571
On Fri, May 19, 2023 at 6:36 PM Neil Sikka wrote:
>
> Hello, I just filed a bug for the Radeon driver crashing:
> https://bugzilla.kernel.org/show_bug.cgi?id=217464
>
> It looks similar to this bug
> (https
On 15/05/2023 17:30, Rob Clark wrote:
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well.
[Public]
Hi Jani,
Thanks for your time!
Comments inline.
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, May 16, 2023 6:34 PM
> To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> amd-gfx@lists.freedesktop.org
> Cc: ly...@redhat.com; ville.syrj...@linux.intel.com; imre.d...@int
66 matches
Mail list logo
