[AMD Official Use Only - Internal Distribution Only]
That's because pr_warn/err/info are forbidden to use in power routines.
/*
* DO NOT use these for err/warn/info/debug messages.
* Use dev_err, dev_warn, dev_info and dev_dbg instead.
* They are more MGPU friendly.
*/
#undef pr_err
#undef pr
Add support for GWS in Arcturus, which needs MEC2 firmware #48
or above. Fix the MEC2 version check for Vega 10 GWS support,
since Vega 10 firmware adds 0x8000 to the actual firmware
revision. We were previously declaring support where it did not
exist.
Signed-off-by: Joseph Greathouse
Change-Id:
On 2020-06-26 1:04 p.m., Christian König wrote:
> Am 26.06.20 um 18:12 schrieb Alex Jivin:
>> Adding a delay between writing to UVD control register and reading from it.
>> This is to allow the HW to process the write command.
>>
>> Signed-off-by: Alex Jivin
>> Suggested-By: Luben Tukov
>> ---
>>
Am 2020-06-29 um 6:00 p.m. schrieb Joseph Greathouse:
> Update PROCESS_QUANTUM, the time the hardware scheduler allows
> processes to run before switching to other processes when it becomes
> over-subscribed. Increase this to 10ms, to allow processes to better
> amortize their task switch times.
>
Update PROCESS_QUANTUM, the time the hardware scheduler allows
processes to run before switching to other processes when it becomes
over-subscribed. Increase this to 10ms, to allow processes to better
amortize their task switch times.
Update HQD Quantum, the amount of time that an active queue sta
On Mon, Jun 29, 2020 at 4:49 PM Nicholas Kazlauskas
wrote:
>
> [Why]
> Changes that are fast don't require updating DLG parameters making
> this call unnecessary. Considering this is an expensive call it should
> not be done on every flip.
>
> DML touches clocks, p-state support, DLG params and a
[Why]
Changes that are fast don't require updating DLG parameters making
this call unnecessary. Considering this is an expensive call it should
not be done on every flip.
DML touches clocks, p-state support, DLG params and a few other DC
internal flags and these aren't expected during fast. A hang
On Sun, Jun 28, 2020 at 7:19 AM Evan Quan wrote:
>
> Fix the compile error below:
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function
> 'smu_v11_0_init_microcode':
> >> arch/arc/include/asm/bug.h:22:2: error: implicit declaration of function
> >> 'pr_warn'; did you mean 'pci_warn'
On Mon, Jun 29, 2020 at 12:13 PM Kazlauskas, Nicholas
wrote:
>
> On 2020-06-29 11:40 a.m., Kazlauskas, Nicholas wrote:
> > On 2020-06-29 11:36 a.m., Alex Deucher wrote:
> >> Seems to cause stability issues for some users.
> >>
> >> This reverts commit a24eaa5c51255b344d5a321f1eeb3205f2775498.
> >>
On 2020-06-29 11:40 a.m., Kazlauskas, Nicholas wrote:
On 2020-06-29 11:36 a.m., Alex Deucher wrote:
Seems to cause stability issues for some users.
This reverts commit a24eaa5c51255b344d5a321f1eeb3205f2775498.
Bug:
https://gitlab.freedesktop.org/drm/amd/-/issues/1191
Signed-off-by: Alex De
On 2020-06-29 11:36 a.m., Alex Deucher wrote:
Seems to cause stability issues for some users.
This reverts commit a24eaa5c51255b344d5a321f1eeb3205f2775498.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191
Signed-off-by: Alex Deucher
I don't see the error in their log. How do we know
Seems to cause stability issues for some users.
This reverts commit a24eaa5c51255b344d5a321f1eeb3205f2775498.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 6 --
1 file changed, 6 deletions(-)
diff --git
[AMD Public Use]
You might want to add a comment to the code here. It looks wrong to use the
OFFSET.
Alex
From: amd-gfx on behalf of Wenhui.Sheng
Sent: Monday, June 29, 2020 2:07 AM
To: amd-gfx@lists.freedesktop.org
Cc: Sheng, Wenhui ; Zhang, Hawking
Subje
We'd better not let the flush after sysfs creation otherwise there is chance
that user use sysfs to touch hardware before the IB test done and introduce
headache issues
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
[AMD Public Use]
And I appreciate it. There's always someone who will look at a patch critically
instead of just saying "eh, it's his code, he probably knows what he's doing"
and doing an automatic RB. Now for the caffeine to kick in 😊
Kent
> -Original Message-
> From: Koenig, Christi
No, problem. I don't know this code but the patch looked kind of fishy :)
And yes that happens to all of us, that's why we do this review.
Christian.
Am 29.06.20 um 14:35 schrieb Russell, Kent:
[AMD Public Use]
Thanks for making me look at it critically (something I should do more after retur
[AMD Public Use]
Thanks for making me look at it critically (something I should do more after
returning from 2 weeks vacation). Nirmoy fixed the issue by using a static
define in his " drm/amdgpu: label internally used symbols as static" patch and
I was just in autopilot trying to fix the Intel
Ok, then why does it fix a warning if we make it non-static?
If the function used it compiled under some #ifdef then we should
probably just compile this under #ifdef as well.
Christian.
Am 29.06.20 um 14:20 schrieb Russell, Kent:
[AMD Public Use]
It's used repeatedly in the amdgpu_fru_get_
[AMD Public Use]
It's used repeatedly in the amdgpu_fru_get_product_info function, but only in
that function which is in the amdgpu_fru_eeprom.c file. While it could be
theoretically be used elsewhere, it isn't currently and any other usage would
be best contained in the amdgpu_fru_eeprom.c fil
Am 29.06.20 um 14:13 schrieb Kent Russell:
This fixes the missing-prototypes warning for the amdgpu_fru_read_eeprom
function. Since we declare it in the header, we can make it un-static
Well is it used in different files? Otherwise we might just have unused
code in the module which can potenti
This fixes the missing-prototypes warning for the amdgpu_fru_read_eeprom
function. Since we declare it in the header, we can make it un-static
Signed-off-by: Kent Russell
Reported-by: kernel test robot
Change-Id: I2b9419365cb8b38bcfb6582df53b96c83861d6cf
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fr
Am 29.06.20 um 11:35 schrieb Monk Liu:
issue:
originally we kickoff IB test asynchronously with driver's
init, thus
the IB test may still running when the driver loading
done (modprobe amdgpu done).
if we shutdown VM immediately after amdgpu driver
loaded then GPU may
hang because the IB test is
issue:
originally we kickoff IB test asynchronously with driver's
init, thus
the IB test may still running when the driver loading
done (modprobe amdgpu done).
if we shutdown VM immediately after amdgpu driver
loaded then GPU may
hang because the IB test is still running
fix:
flush the delayed_ini
Sounds doable as well
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
Sent: Monday, June 29, 2020 5:10 PM
To: Liu, Monk ; Koenig, Christian ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: make IB tes
Am 29.06.20 um 11:03 schrieb Liu, Monk:
We explicitly added the asynchronously IB test for SRIOV to make driver load
faster. Why is that now a problem?
Well I didn't notice this change explicitly for SRIOV, at least from the code
it is quite a normal change
It's been a while, but if I rememb
>>> We explicitly added the asynchronously IB test for SRIOV to make driver
>>> load faster. Why is that now a problem?
Well I didn't notice this change explicitly for SRIOV, at least from the code
it is quite a normal change
>>> And why would it help when the VM shuts down? We cancel/flush th
Am 29.06.20 um 09:11 schrieb Monk Liu:
From: pengzhou
issue:
originally we kickoff IB test asynchronously with driver's init, thus
the IB test may still running when the driver loading done (modprobe amdgpu
done).
if we shutdown VM immediately after amdgpu driver loaded then GPU may
hang becau
From: pengzhou
issue:
originally we kickoff IB test asynchronously with driver's init, thus
the IB test may still running when the driver loading done (modprobe amdgpu
done).
if we shutdown VM immediately after amdgpu driver loaded then GPU may
hang because the IB test is still running
fix:
mak
28 matches
Mail list logo
