Replace print_clock_levels with emit_clock_levels for aldebaran
* replace .print_clk_levels with .emit_clk_levels in aldebaran_ppt_funcs
* added extra parameter int *offset
* removed var size, uses arg *offset instead
* removed call to smu_cmn_get_sysfs_buf
* errors are returned to
aldebaran_get_clk_table cannot fail so convert to void function
aldebaran_freqs_in_same_level now returns bool
aldebaran_emit_clk_levels optimized:
split into two switch statements to gather vars, then use common output
removed impossible error messages for failure of get_clk_table
reduce
Optimized arcturus_emit_clk_levels
split into two switch statements to gather vars, then use common output
reduce size of string literals by creating static string var
removed impossible error messages for failure of get_clk_table
added clock_mhz to remove double divide by 1000
Replace print_clock_levels with emit_clock_levels for arcturus
* replace .print_clk_levels with .emit_clk_levels in arcturus_ppt_funcs
* added extra parameter int *offset
* removed var size, uses arg *offset instead
* removed call to smu_cmn_get_sysfs_buf
* errors are returned to caller
On 5/11/2022 1:50 PM, Jason Gunthorpe wrote:
On Thu, May 05, 2022 at 04:34:36PM -0500, Alex Sierra wrote:
diff --git a/mm/memory.c b/mm/memory.c
index 76e3af9639d9..892c4cc54dc2 100644
+++ b/mm/memory.c
@@ -621,6 +621,13 @@ struct page *vm_normal_page(struct vm_area_struct *vma,
unsigned
[AMD Official Use Only - General]
Thanks for mentioning, yes I'll add a reported-by for Dan on the commit.
Best,
Graham
> -Original Message-
> From: Alex Deucher
> Sent: Thursday, May 12, 2022 5:33 PM
> To: Sider, Graham
> Cc: amd-gfx list ; Joshi, Mukul
> ; Kuehling, Felix ; Dan
>
Would it be better to set the VM_ALWAYS_VALID flag to have a greater
guarantee that the best placement will be chosen?
See, the main feature is getting the best placement, not being discardable.
The best placement is a hw design requirement due to using memory for uses
that are expected to have
Am 2022-05-12 um 15:16 schrieb Graham Sider:
convert_to_mes_queue_type return can be negative, but
queue_input.queue_type is uint32_t. Put return in integer var and cast
to unsigned after negative check.
Signed-off-by: Graham Sider
Reviewed-by: Felix Kuehling
---
Applied. Thanks!
Alex
On Thu, May 12, 2022 at 4:45 PM Hans de Goede wrote:
>
> Lockdep complains about the smu->message_lock mutex being used before
> it is initialized through the following call path:
>
> amdgpu_device_init()
> amdgpu_dpm_mode2_reset()
> smu_mode2_reset()
>
On Thu, May 12, 2022 at 3:17 PM Graham Sider wrote:
>
> convert_to_mes_queue_type return can be negative, but
> queue_input.queue_type is uint32_t. Put return in integer var and cast
> to unsigned after negative check.
>
> Signed-off-by: Graham Sider
Add a reported-by for Dan's email?
Lockdep complains about the smu->message_lock mutex being used before
it is initialized through the following call path:
amdgpu_device_init()
amdgpu_dpm_mode2_reset()
smu_mode2_reset()
smu_v12_0_mode2_reset()
smu_cmn_send_smc_msg_with_param()
Move the mutex_init() call to
[AMD Official Use Only - General]
Made a spelling mistake in the amd-gfx email, sending again.
-Original Message-
From: Kim, Sung joon
Sent: Thursday, May 12, 2022 4:48 PM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Siqueira, Rodrigo ; Deucher,
Alexander ; Koenig, Christian
Cc:
convert_to_mes_queue_type return can be negative, but
queue_input.queue_type is uint32_t. Put return in integer var and cast
to unsigned after negative check.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 7 ---
1 file changed, 4 insertions(+), 3
On 5/11/2022 9:58 PM, Alistair Popple wrote:
Alex Sierra writes:
[...]
diff --git a/mm/rmap.c b/mm/rmap.c
index fedb82371efe..d57102cd4b43 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1995,7 +1995,8 @@ void try_to_migrate(struct folio *folio, enum ttu_flags
flags)
On Thu, May 12, 2022 at 09:47:29AM -0400, Alex Deucher wrote:
> Are those new? Maybe the card is not seated correctly? Can you try
> another slot?
I can't remember having seen these TLP error messages with older
kernels. 5.17 still works fine with this card.
I will try to put the card into
://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/pengfuyuan/drm-amd-display-Remove-macro-DC_DEFAULT_LOG_MASK/20220512-185320
base: git://anongit.freedesktop.org/drm/drm drm-next
config: powerpc64-randconfig-s032-20220512
(https://download.01.org/0day-ci
On Thu, 12 May 2022 at 19:22, Zhang, Dingchen (David)
wrote:
>
> [AMD Official Use Only - General]
>
> Hi Daniel
>
> Thanks for your comments and explanations. I replied in-line and look forward
> to more discussion.
>
> regards
> David
>
>
> From: Daniel Vetter
> Sent: Thursday, May 12, 2022
[AMD Official Use Only - General]
Hi Daniel
Thanks for your comments and explanations. I replied in-line and look forward
to more discussion.
regards
David
From: Daniel Vetter
Sent: Thursday, May 12, 2022 7:22 AM
To: Alex Deucher
Cc: Zhang, Dingchen (David) ; amd-gfx list
; Wang, Chao-kai
This is a note to let you know that I've just added the patch titled
drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version,
environment} types
to the 5.10-stable tree which can be found at:
This is a note to let you know that I've just added the patch titled
drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version,
environment} types
to the 5.4-stable tree which can be found at:
This is a note to let you know that I've just added the patch titled
drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version,
environment} types
to the 4.19-stable tree which can be found at:
On Thu, May 12, 2022 at 4:35 AM Jörg Rödel wrote:
>
> On Tue, May 10, 2022 at 04:41:57PM -0400, Alex Deucher wrote:
> > Does setting amdgpu.runpm=0 on the kernel command line in grub help?
> > If so, that should fixed with:
> >
Sure, I will investigate that. What about the ticket which LIjo raised
which was basically doing 8 resets instead of one ? Lijo - can this
ticket wait until I come up with this new design for amdgpu reset
function or u need a quick solution now in which case we can use the
already existing
Am 12.05.22 um 15:07 schrieb Andrey Grodzovsky:
On 2022-05-12 02:06, Christian König wrote:
Am 11.05.22 um 22:27 schrieb Andrey Grodzovsky:
On 2022-05-11 11:39, Christian König wrote:
Am 11.05.22 um 17:35 schrieb Andrey Grodzovsky:
On 2022-05-11 11:20, Lazar, Lijo wrote:
On 5/11/2022
On 2022-05-12 02:06, Christian König wrote:
Am 11.05.22 um 22:27 schrieb Andrey Grodzovsky:
On 2022-05-11 11:39, Christian König wrote:
Am 11.05.22 um 17:35 schrieb Andrey Grodzovsky:
On 2022-05-11 11:20, Lazar, Lijo wrote:
On 5/11/2022 7:28 PM, Christian König wrote:
Am 11.05.22 um
On 2022-05-12 02:03, Christian König wrote:
Am 11.05.22 um 17:57 schrieb Andrey Grodzovsky:
[SNIP]
How about we do it like this then:
struct amdgpu_reset_domain {
union {
struct {
struct work_item debugfs;
struct work_item ras;
[Why & How]
The DC_DEFAULT_LOG_MASK macro has not been used for a long time, so remove it.
Signed-off-by: pengfuyuan
---
.../drm/amd/display/include/logger_types.h| 34 ---
1 file changed, 34 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/include/logger_types.h
On Tue, May 10, 2022 at 04:41:57PM -0400, Alex Deucher wrote:
> Does setting amdgpu.runpm=0 on the kernel command line in grub help?
> If so, that should fixed with:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f95af4a9236695caed24fe6401256bb974e8f2a7
Eliminate the follow smatch warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9687
amdgpu_dm_atomic_commit_tail() warn: inconsistent indenting.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ---
1 file
On 5/12/2022 5:42 PM, Sundararaju, Sathishkumar wrote:
On 5/12/2022 4:37 PM, Lazar, Lijo wrote:
On 5/12/2022 4:26 PM, Sathishkumar S wrote:
create smartshift sysfs attributes from dGPU device even
on smartshift 1.0 platform to be consistent. Do not populate
the attributes on platforms
On 5/12/2022 4:37 PM, Lazar, Lijo wrote:
On 5/12/2022 4:26 PM, Sathishkumar S wrote:
create smartshift sysfs attributes from dGPU device even
on smartshift 1.0 platform to be consistent. Do not populate
the attributes on platforms that have APU only but not dGPU
or vice versa.
V2: avoid
On Wed, 11 May 2022 at 17:35, Alex Deucher wrote:
>
> On Tue, May 10, 2022 at 4:45 PM David Zhang wrote:
> >
> > changes in v2:
> > ---
> > - set vsc_packet_rev2 for PSR1 which is safer
> > - add exposure of AMD specific DPCD regs for PSR-SU-RC (rate-control)
> > - add DC/DM
On 5/12/2022 4:26 PM, Sathishkumar S wrote:
create smartshift sysfs attributes from dGPU device even
on smartshift 1.0 platform to be consistent. Do not populate
the attributes on platforms that have APU only but not dGPU
or vice versa.
V2: avoid checking for the number of VGA/DISPLAY
create smartshift sysfs attributes from dGPU device even
on smartshift 1.0 platform to be consistent. Do not populate
the attributes on platforms that have APU only but not dGPU
or vice versa.
V2: avoid checking for the number of VGA/DISPLAY devices (Lijo)
Suggested-by: Alex Deucher
On 5/12/2022 11:36 AM, Christian König wrote:
Am 11.05.22 um 22:27 schrieb Andrey Grodzovsky:
On 2022-05-11 11:39, Christian König wrote:
Am 11.05.22 um 17:35 schrieb Andrey Grodzovsky:
On 2022-05-11 11:20, Lazar, Lijo wrote:
On 5/11/2022 7:28 PM, Christian König wrote:
Am 11.05.22 um
On 5/12/2022 1:50 PM, Lazar, Lijo wrote:
On 5/11/2022 5:55 PM, Sathishkumar S wrote:
create smartshift sysfs attributes from dGPU device even
on smartshift 1.0 platform to be consistent. Do not populate
the attributes on platforms that have APU only but not dGPU
or vice versa.
On 5/11/2022 5:55 PM, Sathishkumar S wrote:
create smartshift sysfs attributes from dGPU device even
on smartshift 1.0 platform to be consistent. Do not populate
the attributes on platforms that have APU only but not dGPU
or vice versa.
Suggested-by: Alex Deucher
Signed-off-by: Sathishkumar
Am 12.05.22 um 00:06 schrieb Marek Olšák:
3rd question: Is it worth using this on APUs?
It makes memory management somewhat easier when we are really OOM.
E.g. it should also work for GTT allocations and when the core kernel
says "Hey please free something up or I will start the OOM-killer"
Hi
Am 11.05.22 um 20:19 schrieb Lyude Paul:
Many DRM drivers feature a 'modeset' argument, which can be used to
enable/disable the entire driver (as opposed to passing nomodeset to the
kernel, which would disable modesetting globally and make it difficult to
load amdgpu afterwards). Apparently
On 5/12/22 08:17, Christian König wrote:
> Am 11.05.22 um 20:36 schrieb Alex Deucher:
>> On Wed, May 11, 2022 at 2:20 PM Lyude Paul wrote:
>>> Many DRM drivers feature a 'modeset' argument, which can be used to
>>> enable/disable the entire driver (as opposed to passing nomodeset to the
>>>
Am 11.05.22 um 20:36 schrieb Alex Deucher:
On Wed, May 11, 2022 at 2:20 PM Lyude Paul wrote:
Many DRM drivers feature a 'modeset' argument, which can be used to
enable/disable the entire driver (as opposed to passing nomodeset to the
kernel, which would disable modesetting globally and make it
Am 11.05.22 um 22:27 schrieb Andrey Grodzovsky:
On 2022-05-11 11:39, Christian König wrote:
Am 11.05.22 um 17:35 schrieb Andrey Grodzovsky:
On 2022-05-11 11:20, Lazar, Lijo wrote:
On 5/11/2022 7:28 PM, Christian König wrote:
Am 11.05.22 um 15:43 schrieb Andrey Grodzovsky:
On 2022-05-11
Am 11.05.22 um 17:57 schrieb Andrey Grodzovsky:
[SNIP]
How about we do it like this then:
struct amdgpu_reset_domain {
union {
struct {
struct work_item debugfs;
struct work_item ras;
};
struct work_item
43 matches
Mail list logo
