Before, initialization of smu ip block would be skipped
for sriov ASICs. But if there's only one VF being used,
guest driver should be able to dump some HW info such as
clks, temperature,etc.
To solve this, now after onevf mode is enabled, host
driver will notify guest. If it's onevf mode, guest w
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Kenneth Feng
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Thursday, January 2, 2020 9:54 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: add smu11_driver_if_arctu
Acked-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Jack
> Zhang
> Sent: Thursday, January 2, 2020 1:51 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Jack (Jian)
> Subject: [PATCH 2/2] amd/amdgpu/sriov tdr enablement with pp_onevf_mode
>
> Under sriov and pp_one
> -Original Message-
> From: amd-gfx On Behalf Of Jack
> Zhang
> Sent: Thursday, January 2, 2020 1:50 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Jack (Jian)
> Subject: [PATCH 1/2] amd/amdgpu/sriov enable onevf mode for ARCTURUS VF
>
> Before, initialization of smu ip block wo
Under sriov and pp_onevf mode,
1.take resume instead of hw_init for smc recover to avoid
potential memory leak.
2.add return condition inside smc resume function for
sriov_pp_onevf_mode and pm_enabled param.
Signed-off-by: Jack Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
dr
Before, initialization of smu ip block would be skipped
for sriov ASICs. But if there's only one VF being used,
guest driver should be able to dump some HW info such as
clks, temperature,etc.
To solve this, now after onevf mode is enabled, host
driver will notify guest. If it's onevf mode, guest w
> -Original Message-
> From: Deucher, Alexander
> Sent: Sunday, December 29, 2019 2:43 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 1/2] drm/amdgpu: handle mp1 state properly on suspend
> or device removal
>
> [AMD Public Use]
>
> > -Original Message--
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Tao Zhou
From: amd-gfx On Behalf Of Clements,
John
Sent: 2019年12月31日 10:30
To: amd-gfx@lists.freedesktop.org; Zhang, Hawking
Subject: [PATCH] drm/amdgpu: update UMC 6.1 RAS error counter register access
path
[AMD Official Us
By this, we can avoid to pass in the VRAM address on every table
transferring. That puts extra unnecessary traffics on SMU on
some cases(e.g. polling the amdgpu_pm_info sysfs interface).
V2: document what the driver table is for and how it works
Change-Id: Ifb74d9cd89790b301e88d472b29cdb9b0365b65
> -Original Message-
> From: Alex Deucher
> Sent: Wednesday, January 1, 2020 10:19 PM
> To: Quan, Evan
> Cc: amd-gfx list ; Deucher, Alexander
>
> Subject: Re: [PATCH 2/2] drm/amd/powerplay: unified VRAM address for driver
> table interaction with SMU
>
> On Mon, Dec 30, 2019 at 9:49
This is to fit the latest SMC firmware and it's backward compatible.
Change-Id: Ic561f83fa5d9d15a226b9f134da7e7ae90d9c6f9
Signed-off-by: Evan Quan
---
.../gpu/drm/amd/powerplay/inc/smu11_driver_if_arcturus.h | 8 +++-
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +-
2 files
Hi Dave, Daniel,
Happy New Year! Fixes for 5.5.
The following changes since commit e31d941c7dd797df37ea94958638a88723325c30:
Merge tag 'drm-intel-fixes-2019-12-23' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-12-27 13:13:30
+1000)
are available in the Git repository
On Mon, Dec 30, 2019 at 9:49 PM Evan Quan wrote:
>
> So that we do not need to allocate a piece of VRAM for it. This
> is a preparation for coming change which unifies the VRAM address
> for all driver tables interaction with SMU.
>
> Change-Id: I967f960a10a19957ea7301aa40a8ced0c036ad68
> Signed-o
On Mon, Dec 30, 2019 at 9:49 PM Evan Quan wrote:
>
> By this, we can avoid to pass in the VRAM address on every table
> transferring. That puts extra unnecessary traffics on SMU on
> some cases(e.g. polling the amdgpu_pm_info sysfs interface).
>
> Change-Id: Ifb74d9cd89790b301e88d472b29cdb9b0365b6
Am 19.12.19 um 13:01 schrieb Nirmoy:
Reviewed-by: Nirmoy Das
On 12/19/19 12:42 PM, Le Ma wrote:
This workaround does not affect other asics because amdgpu only need
expose
one gfx sched to user for now.
Change-Id: Ica92b8565a89899aebe0eba7b2b5a25159b411d3
Signed-off-by: Le Ma
---
drivers/
Hi Evan,
But still what I care more(which is also the easiest way to me) is the correct
return value of the API.
Well exactly that's the point ther return value is not correct for the API.
For example when the GPU reset function would return -EFAULT your
program which reads the debugfs file
Hi,
Not sure if this is reported before, but amdgpu is initialized for an
external GPU (thunderbolt 3), which is not accessible at boot, only
after boltctl initialized the tb3 subsystem.
Then amdgpu will report an timeout, and failed to really initialize the GPU.
At this stage, one my of monitors
17 matches
Mail list logo