Yeah, that's a good point.
If build_bug_on() doesn't works for some reason then we at least need to
lower this to a WARN_ON.
A BUG_ON() is only justified if we prevent strong data corruption with
it or note a NULL pointer earlier on or similar.
Regards,
Christian.
Am 10.09.21 um 06:36 schr
Am 10.09.21 um 02:38 schrieb xinhui pan:
alloc extra msg from direct IB pool.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 99 +++--
1 file changed, 45 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/dr
Am 10.09.21 um 02:38 schrieb xinhui pan:
alloc extra msg from direct IB pool.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
b/drivers/gpu/d
Am 10.09.21 um 02:38 schrieb xinhui pan:
move BO allocation in sw_init.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 75 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h | 1 +
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 8 +--
drivers/gpu/drm/am
Am 10.09.21 um 02:38 schrieb xinhui pan:
Direct IB pool is used for vce/vcn IB extra msg too. Increase its size
to AMDGPU_IB_POOL_SIZE.
Signed-off-by: xinhui pan
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 8 ++--
1 file changed, 2 insertions(+), 6 dele
[Public]
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Friday, September 10, 2021 11:18 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Lazar, Lijo
; Quan, Evan ; Pelloux-prayer,
Pierre-eric
Subject: [PATCH] drm/
[Public]
Move PCIe atomic detection from kgf2kfd_probe into kgf2kfd_device_init because
the MEC firmware is not loaded yet at the probe stage
A spelling typo, s/kgf2kfd_device_init/ kgd2kfd_device_init
With above fixed, the patch is: Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Mes
Am 2021-09-08 um 6:48 p.m. schrieb Felix Kuehling:
> On some GPUs the PCIe atomic requirement for KFD depends on the MEC
> firmware version. Add a firmware version check for this. The minimum
> firmware version that works without atomics can be updated in the
> device_info structure for each GPU ty
On 9/10/2021 8:47 AM, Evan Quan wrote:
Current RUNPM mechanism relies on PMFW to master the timing for BACO
in/exit. And that needs cooperation from sound driver for dstate
change notification for function 1(audio). Otherwise(on sound driver
missing), BACO cannot be kicked in correctly and han
[AMD Official Use Only]
looks good to me.
But maybe build_bug_on works too and more reasonable to detect such wrong usage.
From: Chen, Guchun
Sent: Friday, September 10, 2021 12:30:14 PM
To: amd-gfx@lists.freedesktop.org ;
dri-de...@lists.freedesktop.org ; Koenig
Vendor will define their own memory types on top of TTM_PL_PRIV,
but call ttm_set_driver_manager directly without checking mem_type
value when setting up memory manager. So add such check to aware
the case when array bounds.
Signed-off-by: Leslie Shi
Signed-off-by: Guchun Chen
---
include/drm/t
With the shadow buffer support from generic framebuffer emulation, it's
possible now to have runpm kicked when no update for console.
Change-Id: I285472c9100ee6f649d3f3f3548f402b9cd34eaf
Signed-off-by: Evan Quan
Acked-by: Christian König
--
v1->v2:
- rename amdgpu_align_pitch as amdgpu_gem_ali
Current RUNPM mechanism relies on PMFW to master the timing for BACO
in/exit. And that needs cooperation from sound driver for dstate
change notification for function 1(audio). Otherwise(on sound driver
missing), BACO cannot be kicked in correctly and hang will be observed
on RUNPM exit.
By switch
alloc extra msg from direct IB pool.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 99 +++--
1 file changed, 45 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 5612
alloc extra msg from direct IB pool.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index e9fdf49d69e8
move BO allocation in sw_init.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 75 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h | 1 +
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 8 +--
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 8 +--
4 files changed
Direct IB pool is used for vce/vcn IB extra msg too. Increase its size
to AMDGPU_IB_POOL_SIZE.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/drivers/gpu/dr
On Wed, Sep 08, 2021 at 09:00:19PM -0400, Harry Wentland wrote:
> With the '-Werror' enablement patch the amdgpu build was failing
> on clang builds because a bunch of functions were blowing past
> the 1024 byte stack frame default. Due to this we also noticed
> that a lot of functions were passing
On 2021-09-07 9:41 p.m., Mike Lothian wrote:
> Hi
>
> I've just tested this out against Linus's tree and it seems to fix things
>
Thanks.
> Out of interest does Tonga have GPU reset when things go wrong?
>
Not sure. Alex might know.
Harry
> Thanks
>
> Mike
>
> On Tue, 7 Sept 2021 at 15
Reviewed-by: Lyude Paul
On Thu, 2021-09-09 at 18:56 +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> This was unusual; normally, inline functions are declared static as
> well, and defined in a header file if used by multiple compilation
> units. The latter would be more involved in this c
On 2021-09-09 12:55 p.m., Anson Jacob wrote:
> Assert only when FPU is not enabled.
>
> Fixes: e549f77c1965 ("drm/amd/display: Add DC_FP helper to check FPU state")
> Signed-off-by: Anson Jacob
> Cc: Christian König
> Cc: Hersen Wu
> Cc: Harry Wentland
> Cc: Rodrigo Siqueira
Reviewed-by: Har
[AMD Official Use Only]
Thanks for the review . I accepted your comments and will sent another
change list for review once your change is in.
Regards
Shaoyun.liu
-Original Message-
From: Kuehling, Felix
Sent: Thursday, September 9, 2021 12:18 PM
To: Liu, Shaoyun ; amd-gfx@lists.
Apologies, I messed up the recipients in this patch, please follow up to the
fixed version I just sent.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
From: Michel Dänzer
This was unusual; normally, inline functions are declared static as
well, and defined in a header file if used by multiple compilation
units. The latter would be more involved in this case, so just drop
the inline declaration for now.
Fixes compile failure building for ppc64l
Assert only when FPU is not enabled.
Fixes: e549f77c1965 ("drm/amd/display: Add DC_FP helper to check FPU state")
Signed-off-by: Anson Jacob
Cc: Christian König
Cc: Hersen Wu
Cc: Harry Wentland
Cc: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 2 +-
1 file changed, 1
From: Michel Dänzer
This was unusual; normally, inline functions are declared static as
well, and defined in a header file if used by multiple compilation
units. The latter would be more involved in this case, so just drop
the inline declaration for now.
Fixes compile failure building for ppc64l
On 2021-09-07 6:20 p.m., Felix Kuehling wrote:
Am 2021-09-07 um 4:30 p.m. schrieb James Zhu:
On 2021-09-07 1:53 p.m., Felix Kuehling wrote:
Am 2021-09-07 um 1:51 p.m. schrieb Felix Kuehling:
Am 2021-09-07 um 1:22 p.m. schrieb James Zhu:
On 2021-09-07 12:48 p.m., Felix Kuehling wrote:
Am 2
Am 2021-09-09 um 11:59 a.m. schrieb shaoyunl:
> The AtomicOp Requester Enable bit is reserved in VFs and the PF value applies
> to all
> associated VFs. so guest driver can not directly enable the atomicOps for VF,
> it
> depends on PF to enable it. In current design, amdgpu driver will get the
The AtomicOp Requester Enable bit is reserved in VFs and the PF value applies
to all
associated VFs. so guest driver can not directly enable the atomicOps for VF, it
depends on PF to enable it. In current design, amdgpu driver will get the
enabled
atomicOps bits through private pf2vf data
Signe
On 9/9/21 12:30 AM, Christian König wrote:
Am 09.09.21 um 08:07 schrieb Guenter Roeck:
On 9/8/21 10:58 PM, Christoph Hellwig wrote:
On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
It'd be good to avoid. It has helped uncover build issues with KASAN in
the past. Or at least make it
On 9/8/21 10:58 PM, Tom Lendacky wrote:
Introduce a powerpc version of the cc_platform_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
attribute.
Cc: Michael Ellerman
Cc: B
On 09.09.21 00:58, Tom Lendacky wrote:
This patch series provides a generic helper function, cc_platform_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new confidential computing technologies are
added to the kernel
On 9/8/21 10:58 PM, Tom Lendacky wrote:
diff --git a/arch/powerpc/include/asm/mem_encrypt.h
b/arch/powerpc/include/asm/mem_encrypt.h
index ba9dab07c1be..2f26b8fc8d29 100644
--- a/arch/powerpc/include/asm/mem_encrypt.h
+++ b/arch/powerpc/include/asm/mem_encrypt.h
@@ -10,11 +10,6 @@
#incl
On 9/8/21 10:58 PM, Tom Lendacky wrote:
In prep for other confidential computing technologies, introduce a generic
helper function, cc_platform_has(), that can be used to check for specific
I have little problem with that naming.
For me CC has always meant Compiler Collection.
active conf
On 9/9/21 2:25 AM, Christophe Leroy wrote:
On 9/8/21 10:58 PM, Tom Lendacky wrote:
diff --git a/arch/powerpc/include/asm/mem_encrypt.h
b/arch/powerpc/include/asm/mem_encrypt.h
index ba9dab07c1be..2f26b8fc8d29 100644
--- a/arch/powerpc/include/asm/mem_encrypt.h
+++ b/arch/powerpc/include/asm
On 9/9/21 2:32 AM, Christian Borntraeger wrote:
On 09.09.21 00:58, Tom Lendacky wrote:
This patch series provides a generic helper function, cc_platform_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new confidentia
On Thu, Sep 9, 2021 at 1:43 PM Marco Elver wrote:
> On Thu, 9 Sept 2021 at 13:00, Arnd Bergmann wrote:
> > On Thu, Sep 9, 2021 at 12:54 PM Marco Elver wrote:
> > > On Thu, 9 Sept 2021 at 07:59, Christoph Hellwig
> > > wrote:
> > > > On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
From: Tuo Li
[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
From: Tuo Li
[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
From: Tuo Li
[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
[AMD Official Use Only]
Submitting patch to update RAS trigger error to support additional blocks
0002-drm-amdgpu-Update-RAS-trigger-error-block-support.patch
Description: 0002-drm-amdgpu-Update-RAS-trigger-error-block-support.patch
From: Tuo Li
[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
From: Anson Jacob
[ Upstream commit 1a394b3c3de2577f200cb623c52a5c2b82805cec ]
link_rate is updated via debugfs using hex values, set it to output
in hex as well.
eg: Resolution: 1920x1080@144Hz
cat /sys/kernel/debug/dri/0/DP-1/link_settings
Current: 4 0x14 0 Verified: 4 0x1e 0 Reported
From: Sean Keely
[ Upstream commit 1ec06c2dee679e9f089e78ed20cb74ee90155f61 ]
On systems with multiple SH per SE compute_static_thread_mgmt_se#
is split into independent masks, one for each SH, in the upper and
lower 16 bits. We need to detect this and apply cu masking to each
SH. The cu mask
From: Tuo Li
[ Upstream commit 554594567b1fa3da74f88ec7b2dc83d000c58e98 ]
The variable dc->clk_mgr is checked in:
if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock)
This indicates dc->clk_mgr can be NULL.
However, it is dereferenced in:
if (!dc->clk_mgr->funcs->get_clock)
To fix this null
From: Tuo Li
[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
From: Anson Jacob
[ Upstream commit 1a394b3c3de2577f200cb623c52a5c2b82805cec ]
link_rate is updated via debugfs using hex values, set it to output
in hex as well.
eg: Resolution: 1920x1080@144Hz
cat /sys/kernel/debug/dri/0/DP-1/link_settings
Current: 4 0x14 0 Verified: 4 0x1e 0 Reported
From: Oliver Logush
[ Upstream commit 23e55639b87fb16a9f0f66032ecb57060df6c46c ]
[why]
The units of the time_per_pixel variable were incorrect, this had to be
changed for the code to properly function.
[how]
The change was very straightforward, only required one line of code to
be changed where
From: Luben Tuikov
[ Upstream commit dce4400e6516d18313d23de45b5be8a18980b00e ]
No need to account for the 2 bytes of EEPROM
address--this is now well abstracted away by
the fixes the the lower layers.
Cc: Andrey Grodzovsky
Cc: Alexander Deucher
Signed-off-by: Luben Tuikov
Acked-by: Alexande
From: Sean Keely
[ Upstream commit 1ec06c2dee679e9f089e78ed20cb74ee90155f61 ]
On systems with multiple SH per SE compute_static_thread_mgmt_se#
is split into independent masks, one for each SH, in the upper and
lower 16 bits. We need to detect this and apply cu masking to each
SH. The cu mask
From: Tuo Li
[ Upstream commit 554594567b1fa3da74f88ec7b2dc83d000c58e98 ]
The variable dc->clk_mgr is checked in:
if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock)
This indicates dc->clk_mgr can be NULL.
However, it is dereferenced in:
if (!dc->clk_mgr->funcs->get_clock)
To fix this null
From: Tuo Li
[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
From: Roy Chan
[ Upstream commit 781e1e23131cce56fb557e6ec2260480a6bd08cc ]
[How]
the programming sequeune was for old asic.
the correct programming sequeunce should be similar to the one
used in mpc. the fix is copied from the mpc programming sequeunce.
Reviewed-by: Anthony Koo
Acked-by: Anso
From: Roy Chan
[ Upstream commit 82367e7f22d085092728f45fd5fbb15e3fb997c0 ]
[Why]
If the plane has been removed, the writeback disablement logic
doesn't run
[How]
fix the logic order
Acked-by: Anson Jacob
Signed-off-by: Roy Chan
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-
From: Anson Jacob
[ Upstream commit 1a394b3c3de2577f200cb623c52a5c2b82805cec ]
link_rate is updated via debugfs using hex values, set it to output
in hex as well.
eg: Resolution: 1920x1080@144Hz
cat /sys/kernel/debug/dri/0/DP-1/link_settings
Current: 4 0x14 0 Verified: 4 0x1e 0 Reported
From: Oak Zeng
[ Upstream commit 95f71f12aa45d65b7f2ccab95569795edffd379a ]
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN fi
From: Oliver Logush
[ Upstream commit 23e55639b87fb16a9f0f66032ecb57060df6c46c ]
[why]
The units of the time_per_pixel variable were incorrect, this had to be
changed for the code to properly function.
[how]
The change was very straightforward, only required one line of code to
be changed where
From: Luben Tuikov
[ Upstream commit dce4400e6516d18313d23de45b5be8a18980b00e ]
No need to account for the 2 bytes of EEPROM
address--this is now well abstracted away by
the fixes the the lower layers.
Cc: Andrey Grodzovsky
Cc: Alexander Deucher
Signed-off-by: Luben Tuikov
Acked-by: Alexande
From: Sean Keely
[ Upstream commit 1ec06c2dee679e9f089e78ed20cb74ee90155f61 ]
On systems with multiple SH per SE compute_static_thread_mgmt_se#
is split into independent masks, one for each SH, in the upper and
lower 16 bits. We need to detect this and apply cu masking to each
SH. The cu mask
From: Tuo Li
[ Upstream commit 554594567b1fa3da74f88ec7b2dc83d000c58e98 ]
The variable dc->clk_mgr is checked in:
if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock)
This indicates dc->clk_mgr can be NULL.
However, it is dereferenced in:
if (!dc->clk_mgr->funcs->get_clock)
To fix this null
From: Tuo Li
[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
From: Roy Chan
[ Upstream commit 781e1e23131cce56fb557e6ec2260480a6bd08cc ]
[How]
the programming sequeune was for old asic.
the correct programming sequeunce should be similar to the one
used in mpc. the fix is copied from the mpc programming sequeunce.
Reviewed-by: Anthony Koo
Acked-by: Anso
From: Roy Chan
[ Upstream commit 82367e7f22d085092728f45fd5fbb15e3fb997c0 ]
[Why]
If the plane has been removed, the writeback disablement logic
doesn't run
[How]
fix the logic order
Acked-by: Anson Jacob
Signed-off-by: Roy Chan
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-
From: Anson Jacob
[ Upstream commit 1a394b3c3de2577f200cb623c52a5c2b82805cec ]
link_rate is updated via debugfs using hex values, set it to output
in hex as well.
eg: Resolution: 1920x1080@144Hz
cat /sys/kernel/debug/dri/0/DP-1/link_settings
Current: 4 0x14 0 Verified: 4 0x1e 0 Reported
From: Oak Zeng
[ Upstream commit 95f71f12aa45d65b7f2ccab95569795edffd379a ]
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN fi
From: Oliver Logush
[ Upstream commit 23e55639b87fb16a9f0f66032ecb57060df6c46c ]
[why]
The units of the time_per_pixel variable were incorrect, this had to be
changed for the code to properly function.
[how]
The change was very straightforward, only required one line of code to
be changed where
From: Luben Tuikov
[ Upstream commit dce4400e6516d18313d23de45b5be8a18980b00e ]
No need to account for the 2 bytes of EEPROM
address--this is now well abstracted away by
the fixes the the lower layers.
Cc: Andrey Grodzovsky
Cc: Alexander Deucher
Signed-off-by: Luben Tuikov
Acked-by: Alexande
From: Sean Keely
[ Upstream commit 1ec06c2dee679e9f089e78ed20cb74ee90155f61 ]
On systems with multiple SH per SE compute_static_thread_mgmt_se#
is split into independent masks, one for each SH, in the upper and
lower 16 bits. We need to detect this and apply cu masking to each
SH. The cu mask
From: Tuo Li
[ Upstream commit 554594567b1fa3da74f88ec7b2dc83d000c58e98 ]
The variable dc->clk_mgr is checked in:
if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock)
This indicates dc->clk_mgr can be NULL.
However, it is dereferenced in:
if (!dc->clk_mgr->funcs->get_clock)
To fix this null
From: Tuo Li
[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
From: Roy Chan
[ Upstream commit 781e1e23131cce56fb557e6ec2260480a6bd08cc ]
[How]
the programming sequeune was for old asic.
the correct programming sequeunce should be similar to the one
used in mpc. the fix is copied from the mpc programming sequeunce.
Reviewed-by: Anthony Koo
Acked-by: Anso
From: Roy Chan
[ Upstream commit 82367e7f22d085092728f45fd5fbb15e3fb997c0 ]
[Why]
If the plane has been removed, the writeback disablement logic
doesn't run
[How]
fix the logic order
Acked-by: Anson Jacob
Signed-off-by: Roy Chan
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-
From: Mikita Lipski
[ Upstream commit af1f2b19fd7d404d299355cc95930efee5b3ed8b ]
[why]
For dual eDP when setting the new settings we need to set
command version to DMUB_CMD_PSR_CONTROL_VERSION_1, otherwise
DMUB will not read panel_inst parameter.
[how]
Instead of PSR_VERSION_1 pass DMUB_CMD_PSR_
From: Anson Jacob
[ Upstream commit 1a394b3c3de2577f200cb623c52a5c2b82805cec ]
link_rate is updated via debugfs using hex values, set it to output
in hex as well.
eg: Resolution: 1920x1080@144Hz
cat /sys/kernel/debug/dri/0/DP-1/link_settings
Current: 4 0x14 0 Verified: 4 0x1e 0 Reported
From: Oak Zeng
[ Upstream commit 95f71f12aa45d65b7f2ccab95569795edffd379a ]
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN fi
From: Jake Wang
[ Upstream commit 3addbde269f21ffc735f6d3d0c2237664923824e ]
[Why]
During headless boot, DIG may be on which causes HW/SW discrepancies.
To avoid this we power down hardware on boot if DIG is turned on. With
introduction of multiple eDP, hardware power down is being bypassed
unde
From: Oliver Logush
[ Upstream commit 23e55639b87fb16a9f0f66032ecb57060df6c46c ]
[why]
The units of the time_per_pixel variable were incorrect, this had to be
changed for the code to properly function.
[how]
The change was very straightforward, only required one line of code to
be changed where
From: Luben Tuikov
[ Upstream commit 1d9d2ca85b32605ac9c74c8fa42d0c1cfbe019d4 ]
Debugfs RAS EEPROM files are available when
the ASIC supports RAS, and when the debugfs is
enabled, an also when "ras_enable" module
parameter is set to 0. However in this case,
we get a kernel oops when accessing so
From: Luben Tuikov
[ Upstream commit dce4400e6516d18313d23de45b5be8a18980b00e ]
No need to account for the 2 bytes of EEPROM
address--this is now well abstracted away by
the fixes the the lower layers.
Cc: Andrey Grodzovsky
Cc: Alexander Deucher
Signed-off-by: Luben Tuikov
Acked-by: Alexande
On Thu, Sep 09, 2021 at 04:00:05PM +0800, Yu, Lang wrote:
> sysfs_emit and sysfs_emit_at requrie a page boundary
> aligned buf address. Make them happy!
>
> v2: use an inline function
>
> Warning Log:
> [ 492.545174] invalid sysfs_emit_at: buf:f19bdfde at:0
> [ 492.546416] WARNING: CPU:
On Thu, Sep 9, 2021 at 12:54 PM Marco Elver wrote:
> On Thu, 9 Sept 2021 at 07:59, Christoph Hellwig wrote:
> > On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
> > > It'd be good to avoid. It has helped uncover build issues with KASAN in
> > > the past. Or at least make it dependent
Am 09.09.21 um 10:36 schrieb Lazar, Lijo:
On 9/9/2021 1:31 PM, Christian König wrote:
Am 09.09.21 um 05:28 schrieb Lazar, Lijo:
On 9/9/2021 8:13 AM, Yu, Lang wrote:
[AMD Official Use Only]
So the final decision is rollback to scnprintf().
If we can define our own helper functions like
sysfs
On 9/9/2021 1:31 PM, Christian König wrote:
Am 09.09.21 um 05:28 schrieb Lazar, Lijo:
On 9/9/2021 8:13 AM, Yu, Lang wrote:
[AMD Official Use Only]
So the final decision is rollback to scnprintf().
If we can define our own helper functions like sysfs_emit/sysfs_emit_at
but without page bou
Yes, correct but the key point is I want the same handling for old and
new UVD blocks to be the same.
This makes it more likely that the code keeps working on all hardware
generations when we change something.
See those old hardware is rare to get these days and I don't want to
risk any bug
[AMD Official Use Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
From: Clements, John
Sent: Thursday, September 9, 2021 15:59
To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ; Li,
Candice
Subject: Subject: [PATCH 1/1] drm/amdgpu: Update RAS trigger error block support
[AMD Official Use
Ok, good to know. That's probably the reason why we didn't push that
stuff into the IB in the first place.
And yes, using fixed 256kiB sounds like a plan to me then, but please
also double check the AMDGPU_IB_POOL_SIZE define.
I also won't mind if you just open code the two initialization sin
[AMD Official Use Only]
well, If IB test fails because we use gtt domain or
the above 256MB vram. Then the failure is expected.
Doesn't IB test exist to detect such issue?
发件人: Koenig, Christian
发送时间: 2021年9月9日星期四 15:16
收件人: Pan, Xinhui; amd-gfx@lists.freedesktop
[AMD Official Use Only]
Please change the coding style for the bracket.
+ if (ras_cmd->ras_status)
+ {
Other than that, the patch is
Reviewed-by: Hawking Zhang
Regards,
Hawking
From: Clements, John
Sent: Thursday, September 9, 2021 16:00
To: amd-gfx@lists.freedesktop.
It's nice to see at least some of them addressed, feel free to add an
Acked-by: Christian König
Regards,
Christian.
Am 09.09.21 um 03:00 schrieb Harry Wentland:
With the '-Werror' enablement patch the amdgpu build was failing
on clang builds because a bunch of functions were blowing past
the
Am 09.09.21 um 05:28 schrieb Lazar, Lijo:
On 9/9/2021 8:13 AM, Yu, Lang wrote:
[AMD Official Use Only]
So the final decision is rollback to scnprintf().
If we can define our own helper functions like sysfs_emit/sysfs_emit_at
but without page boundary aligned limitation to make life easier?
[AMD Official Use Only]
Submitting patch to remove parser for RAS status response codes and just print
RAS status value on non-zero value
0001-drm-amdgpu-Update-RAS-status-print.patch
Description: 0001-drm-amdgpu-Update-RAS-status-print.patch
sysfs_emit and sysfs_emit_at requrie a page boundary
aligned buf address. Make them happy!
v2: use an inline function
Warning Log:
[ 492.545174] invalid sysfs_emit_at: buf:f19bdfde at:0
[ 492.546416] WARNING: CPU: 7 PID: 1304 at fs/sysfs/file.c:765
sysfs_emit_at+0x4a/0xa0
[ 492.654805
[AMD Official Use Only]
yep, vcn need 128kb extra memory. I will make the pool size constant as 256kb.
From: Koenig, Christian
Sent: Thursday, September 9, 2021 3:14:15 PM
To: Pan, Xinhui ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PAT
[AMD Official Use Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Gao, Likun
Sent: Thursday, September 9, 2021 15:15
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Gao, Likun
Subject: [PATCH] drm/amdgpu: refactor function to init no-psp fw
From: Lik
Am 09.09.21 um 08:07 schrieb Guenter Roeck:
On 9/8/21 10:58 PM, Christoph Hellwig wrote:
On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
It'd be good to avoid. It has helped uncover build issues with KASAN in
the past. Or at least make it dependent on the problematic
architecture.
On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
> It'd be good to avoid. It has helped uncover build issues with KASAN in
> the past. Or at least make it dependent on the problematic architecture.
> For example if arm is a problem, something like this:
I'm also seeing quite a few stac
On 9/8/21 10:58 PM, Christoph Hellwig wrote:
On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
It'd be good to avoid. It has helped uncover build issues with KASAN in
the past. Or at least make it dependent on the problematic architecture.
For example if arm is a problem, something li
The memory leak issue may take place in an error handling path. When
p->xnack_enabled is NULL, the function simply returns with -EFAULT and
forgets to decrement the reference count of a kfd_process object bumped
by kfd_lookup_process_by_pasid, which may incur memory leaks.
Fix it by jumping to lab
Am 09.09.21 um 07:55 schrieb Pan, Xinhui:
[AMD Official Use Only]
There is one dedicated IB pool for IB test. So lets use it for extra msg
too.
For UVD on older HW, use one reserved BO at specific range.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 173 +++
From: Likun Gao
Refactor the code of amdgpu_ucode_init_single_fw to make it more
readable as too many ucode need to handle on this function currently.
Signed-off-by: Likun Gao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 160 ++
1 file changed, 75 insertions(+), 85 delet
1 - 100 of 102 matches
Mail list logo
